Barrierefreiheit/Webseiten auf Barrierefreiheit testen

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

Das Barrierefreiheitsstärkungsgesetz ist seit 2021 beschlossen, ab 28.06.2025 Pflicht für alle Webseiten! Allerdings sollte es auch so selbstverständlich sein, Webseiten und ihre Inhalte für alle Menschen nutzbar zu machen!

Dieses Tutorial zeigt, auf welche Stellschrauben man achten soll und wie Online-Tools beim Testen helfen können.

Erste Schritte

Spezifikationen

Neben dem HTML Living Standard gibt es weitere Dokumente, die Regeln für barrierefreie Webseiten festlegen:

Online-Tools

Mittlerweile gibt es viele Online-Tools, die für Webseiten Fehlerlisten erstellen. Solche Tests sind ein erster Schritt, Schwachstellen zu finden und zu beseitigen.

  1. Der W3C-Validator , bzw. NU-Validator des W3C sind Validatoren, die das HTML auf Gültigkeit überprüfen.
    • Fehlende Alternativtexte und fehlerhaftes Markup werden bemängelt.
    • Andererseits werden obsoletes Tabellenlayout und Div-Suppe als formal korrekt erkannt - die Semantik bleibt hier leider außen vor :-(
  2. WAVE WebAIM (WAVE Web Accessibility Evaluation Tools)[3]
    • ermittelt Auszeichnungsfehler im Markup
    • ermittelt den Kontrast zwischen Text- und Hintergrundfarbe
    • untersucht den Inhalt und versucht die Semantik der Elemente zu vergleichen
  3. Google Lighthouse ist ein Plugin für Chrome, das Webseiten auf Performance, Accessibility, Best practices und SEO testet.
    Dabei können sowohl Dektop- als auch mobile Geräte simuliert werden.
    Als Ergebnis wird eine Punktezahl ausgegeben.
  4. Axe Core von deque.com (2 Wochen frei, später 45$ mtl / 500$ jährlich) scannt Webseiten auf Fehler, erlaubt aber z.B. auch Benutzerflow-Analysen

Tests der Barrierefreiheit lassen sich nur schwer automatisieren. Die Ergebnisse automatisierter Prüftools liefern daher lange Listen von alerts (Warnungen) – darunter viele false positives[4], die dann manuell überprüft werden müssen.

So kann beispielsweise ein automatisierter Test zwar feststellen, ob ein alt-Attribut für ein Bild vorhanden ist, jedoch nicht ob der Alternativtext den Bildinhalt vermittelt oder überhaupt ein Alternativtext benötigt wird. Das macht die Prüfung größerer Sites sehr aufwändig.

Manuelles Fine-Tuning

Es gibt aber eine Reihe von kleinen Tests, die jeder durchführen kann. Diese Liste richtet sich nach den Tipps des Easy Checks – A First Review of Web Accessibility des W3C [5]

HTML

Alternativtext

Symbolbild mit Tag für Alternativtext

Kein Luxus, sondern Notwendigkeit – auch, wenn es immer wieder erwähnt werden muss!

→ Alternativtext

Sprachangabe

""

Mit dem lang-Attribut solltest du die verwendete Sprache angeben. So kann ein Screenreader die Sprache richtig wiedergeben.

→ Internationalisierung

Titel

""

Seitentitel werden in der Titelleiste des Fensters oder der Registerkarte in Browsern angezeigt. Sie werden von Screenreadern als erstes gelesen und helfen den Nutzern zu wissen, wo sie sich befinden.

→ HTML/Tutorials/Grundgerüst

Skip-Links

""

Personen, die Tastaturen, Screenreader und andere unterstützende Technologien verwenden, können mit Hilfe von Sprunglinks schnell und einfach den Hauptinhalt der Seite erreichen.

→ Skip-Link

Überschriften

""

Überschriften vermitteln die Organisation des Inhalts auf der Seite, ähnlich wie ein Inhaltsverzeichnis. Benutzer von Screenreadern verwenden die Überschriften häufig zur Navigation auf einer Webseite.

→ HTML/Tutorials/Seitenstrukturierung
Überschriften

CSS

  • Ist die Seite auch bei deaktiviertem CSS verständlich?

Druck

Printer-Icon.svg

Kann ich die Seite mit allen relevanten Informationen gut lesbar ausdrucken?

→ Print-CSS

Kontrast

""

Ein zu geringer Farbkontrast behindert das Leseverständnis der Inhalte. Dabei geht es nicht nur um „normalen“ Fließtext, sondern auch um interaktive Elemente wie Eingabefelder und Diagramme.

→ Farbe/Farben und Kontraste

Zoom

""

Kann ich das Anzeigefenster verkleinern und die Schrift zoomen, ohne dass die Bedienbarkeit leidet?

→ Responsiv(es Webdesign)

→ CSS/Tutorials/Einstieg/Webseiten responsiv umbauen

Formulare

Fokus

""

Kann ich mit der TAB-Taste(↹ ) alle Links und Eingabe-Elemente erreichen? Ist deren Reihenfolge schlüssig? Werden die angetabbten Elemente deutlich sichtbar hervorgehoben?

→ CSS/Tutorials/Selektoren/Pseudoklasse#Maus-_und_Tastaturinteraktionen

Label

""

Alle interaktiven Elementen benötigen Beschriftungen, die dem Nutzer helfen, Eingabefelder und Buttons richtig zu nutzen.

  • Sind Buttons auch bei deaktiviertem Bilder-Download beschriftet und bedienbar?

→ Formulare/Benutzereingaben zugänglich gestalten

Pflichtangaben kennzeichnen

Formulare sollten klar kennzeichnen, welche Eingabefelder Pflichangaben enthalten. Dann kann der Nutzer diese ausfüllen, bevor er erfolglos versucht, das Formular abzusenden.

→ Formulare/browsereigene Validierung


Empfehlung: Webtechnologien sind im Fluss. Ältere Browser sind oft nicht in der Lage, modernste Technik umzusetzen. Tests auf verschiedenen Browsern können hier durchgeführt werden. Ist die Benutzbarkeit einer Seite von hoher Priorität, sollte man sich auf das Repertoire der gut implementierten Technikelemente beschränken oder sicherstellen, dass eine Nichtinterpretation die Bedienbarkeit nicht einschränkt (progressive enhancement).
Generell gilt: Setze, wann immer möglich Standard-HTML ein.


Sehr umfangreiche Erläuterungen zum Testen von Webseiten findest du auf der Seite BITV-Test [6]. Dort kann man auch einen kostenlosen Selbsttest nutzen.

Die Unterschiede zwischen der national bedeutenden BITV 2.0 und den Web Content Accessibility Guidelines 2.0 (WCAG 2.0) führen zu Problemen, die sich auch auf mögliche Testverfahren auswirken. Der Ansatz des BITV-Testes wird oft kritisiert. Eine sehr ausführlich begründete Kritik hat Jan Eric Hellbusch dazu veröffentlicht [7].


Quellen

  1. ↑ Web Content Accessibility Guidelines (WCAG) 2.2 (W3C)
  2. ↑ User Agent Accessibility Guidelines (UAAG) 2.0 (W3C)
  3. ↑ WAVE WebAIM (WAVE Web Accessibility Evaluation Tools)
  4. ↑ False positives and false negatives (en.wikipedia.org)
  5. ↑ W3C: Easy Checks – A First Review of Web Accessibility
  6. ↑ BITV-Test
  7. ↑ Accessibility Checklist gegen graue Haare von Jan Hellbusch (web.archive.rog)
    BITV 2.0 und „BITV-Test“ sind nicht kompatibel mit den internationalen WCAG 2.0 - ein ausführlicher Vergleich und Kritik
Abgerufen von „http://wiki.selfhtml.org/index.php?title=Barrierefreiheit/Webseiten_auf_Barrierefreiheit_testen&oldid=100150“