Barrierefreiheit: Eine Million kaputte Webseiten - und wie man sie repariert

Die meistgenutzten Webseiten haben erhebliche Probleme mit Barrierefreiheit . Dabei lässt sich das leicht verhindern - mit den Entwicklerwerkzeugen der Browser.

3. Juni 2022 um 09:04 Uhr / Eine Anleitung von Christian Heilmann

64 Kommentare News folgen (öffnet im neuen Fenster)

Viele Webseiten sind nicht barrierefrei. (Bild: Pixabay / Montage: Golem.de) — Viele Webseiten sind nicht barrierefrei. Bild: Pixabay / Montage: Golem.de

Jedes Jahr veröffentlicht Webaim.org (öffnet im neuen Fenster) (kurz für: web accessibility in mind) einen Report über die Barrierefreiheit der 1.000.000 am meisten besuchten Webseiten. Und jedes Jahr ist das Ergebnis enttäuschend. Viele Webseiten können nicht von allen Menschen gleichermaßen benutzt werden, unabhängig von ihren technischen oder körperlichen Möglichkeiten. Dabei ist es nicht schwer, Probleme mit Barrierefreiheit in Produkten bereits bei der Erstellung zu erkennen und zu beheben - mit den Entwicklerwerkzeugen in Browsern.

Neue Angebote bei Golem Jobs(öffnet im neuen Fenster)

Berliner Landesnetz Standardnetzzugang Koordinator*in IT-Dienstleistungszentrum (ITDZ Berlin), Berlin (öffnet im neuen Fenster)

Netzwerkadministrator*in (m/w/div) Deutsche Rentenversicherung Bund, Berlin (öffnet im neuen Fenster)

Data Analyst Facility Management (m/w/d) Schwarz Corporate Solutions, Neckarsulm (öffnet im neuen Fenster)

Software Engineer (m/w/d) - Backend PROBAT SE, Emmerich (öffnet im neuen Fenster)

Ausbildung Kaufmann für Digitalisierungsmanagement (m/w/d) Sparkasse Forchheim, Forchheim (öffnet im neuen Fenster)

E-Commerce Manager* Ledlenser GmbH & Co. KG, Solingen (öffnet im neuen Fenster)

Embedded Software Developer (m/f/d) - FPGA Systems Advantest Europe GmbH, Böblingen (öffnet im neuen Fenster)

SAP EWM & TM Inhouse Consultant (w/m/d) CARL BECHEM GMBH, Hagen (öffnet im neuen Fenster)

Der Report berichtet, dass auf den untersuchten Seiten insgesamt 50.829.406 Fehler gefunden wurden. Das heißt, die durchschnittliche Webseite hat 51 Fehler. Zwar sind das 1,1 Prozent weniger Fehler als im Jahr zuvor, allerdings sind die Seiten auch komplexer geworden. Im Durchschnitt bestehen die getesteten Webseiten aus 955 Elementen, 5,3 Prozent davon sind nicht barrierefrei.

Ihnen fehlen beispielsweise ausreichende Kontraste zwischen Vorder- und Hintergrund, Alternativtexte bei Bildern für die Vorlesefunktion oder erklärende Labels für die Eingabefelder in Formularen. Das bedeutet, dass zum Beispiel Menschen mit bestimmten Behinderungen in jedem zwanzigsten Element auf der Seite stecken bleiben können.

Wann immer wir von Barrierefreiheit sprechen, ist es wichtig, sich vor Augen zu führen, dass Behinderung kein binärer Zustand ist, sondern dass es jeden irgendwann einmal betreffen kann. Eine gut lesbare Schrift ist nicht nur für Menschen mit Sehbehinderungen wichtig, sondern auch, wenn man versucht, in der Sonne etwas auf seinem Handy zu lesen. Untertitel sind wichtig für Menschen, die schlecht hören können, aber auch sehr praktisch, um in einer lauten Kneipe zu verstehen, um was es gerade auf dem Fernseher geht. Barrierefreiheit ist nicht nur oft eine gesetzliche Vorgabe, sondern einfach sinnvoll. Wer niemanden ausgrenzt, kann auch viel mehr Nutzer erreichen.

Neues aus der Golem Karrierewelt(öffnet im neuen Fenster)

Workshops und Weiterbildungen: ISO/IEC 27001 verstehen und anwenden – mit offizieller Zertifizierung

zum Artikel

Karriere Ratgeber: Die besten Gmail- und Outlook-Alternativen vorgestellt – mit Proton, Tuta und Fastmail im Direktvergleich

zum Ratgeber

Seminar: Microsoft Copilot im Unternehmen implementieren: virtueller Ein-Tages-Workshop

zum Kurs

E-Learning: Exclusive: Microsoft 365 Security Masterclass - Protection, Access and Compliance (E-learning package in English)

zum Kurs

Am enttäuschendsten ist, dass die Fehler in den Seiten(öffnet im neuen Fenster) leicht zu beheben oder sogar zu vermeiden sind.

Der Report geht in seinem Bericht sehr ins Detail(öffnet im neuen Fenster) , doch hier sind die größten Probleme kurz zusammengefasst:

83,9 Prozent der Seiten haben Texte und interaktive Elemente ohne ausreichende Kontraste.
55,4 Prozent haben keinen Alternativtext für Bilder.
50,1 Prozent haben Verknüpfungen ohne Text.
46,1 Prozent enthalten Formularfelder ohne Beschreibung.
27,2 Prozent enthalten Knöpfe ohne Text.
22,3 Prozent haben die Seitensprache nicht definiert.

Vieles davon sollte eigentlich selbstverständlich sein, doch es kann natürlich passieren, dass etwas übersehen wird. Schauen wir uns einmal an, wie uns die Entwicklerwerkzeuge, die mit Browsern mitgeliefert werden, helfen können, diese Probleme zu erkennen und zu vermeiden.

Reklame

Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering

Jetzt bestellen bei Amazon (öffnet im neuen Fenster)

Entwicklerwerkzeuge zum Überprüfen der Barrierefreiheit

Im Folgenden erläutern wir, wie Entwicklerwerkzeuge helfen können, barrierefreie Produkte zu erstellen. Als Beispiel zeigen wir die Werkzeuge des Microsoft-Edge-Browsers, der automatisch mit jedem Windows-Rechner geliefert wird, aber auch für Mac und Linux heruntergeladen werden kann. Andere Browser, die ebenfalls auf Chromium aufbauen, wie Google Chrome oder Brave, haben fast die gleichen Entwicklerwerkzeuge und auch die von Firefox und Safari sind ähnlich aufgebaut.

Die besten Werkzeuge zur Überprüfung der Barrierefreiheit sind das Inspect-Tool (öffnet im neuen Fenster) und die Probleme-Auflistung (öffnet im neuen Fenster) . Die offizielle Dokumentation der Entwicklerwerkzeuge hat eine Referenz(öffnet im neuen Fenster) , welches Problem mit welchem Werkzeug erkannt und bearbeitet werden kann. Außerdem gibt es einen detaillierten Artikel(öffnet im neuen Fenster) , der durch alle Probleme einer Demonstrationsseite geht. Hier eine kurze Übersicht, wie man die im Webaim-Report bemängelten Probleme erkennen kann.

Probleme bei der Barrierefreiheit erkennen

Der einfachste Weg herauszufinden, ob ein Teil der Seite genug Kontrast hat, ist es, das Inspect-Tool zu verwenden und mit der Maus über das Element zu fahren. In einem kleinen Informationsfenster werden dann die Daten des Elements angezeigt, darunter auch Informationen zur Barrierefreiheit (Accessibility).

Im Bereich Contrast zeigen Elemente mit ausreichendem Kontrast einen grünen Haken:

Bild 1/19: Elemente mit genügend Kontrast werden mit einem grünen Haken angezeigt. (Screenshot: Christian Heilmann)

Bild 2/19: Wenn ein Element zu wenig Kontrast hat, zeigt das Informationsfenster einen Fehler an. (Screenshot: Christian Heilmann)

Bild 3/19: Formatvorlagenanzeige der Farbe eines Elements (Screenshot: Christian Heilmann)

Bild 4/19: Farbpicker mit Farbe, die nicht genug Kontrast aufweist (Screenshot: Christian Heilmann)

Bild 5/19: Farbpicker mit Vorschlägen von Farben, die genug Kontrast aufweisen (Screenshot: Christian Heilmann)

Bild 6/19: Neue Farbe mit genug Kontrast, dargestellt im Farbpicker (Screenshot: Christian Heilmann)

Bild 7/19: Der Name im Inspect Tool ist bei Bildern ohne Alternativtext leer. (Screenshot: Christian Heilmann)

Bild 8/19: Der Alternativtext wird als name im Inspect Tool angezeigt. (Screenshot: Christian Heilmann)

Bild 9/19: Link mit Text neben dem Bild hat auch einen Namen in der Barrierfreiheit-Anzeige (Screenshot: Christian Heilmann)

Bild 10/19: Link nur mit einem SVG ohne Titel hat keinen Namen in der Barrierfreiheit-Anzeige (Screenshot: Christian Heilmann)

Bild 11/19: Formularfeld mit dem Namen "Other" in der Barrierefreiheit-Anzeige (Screenshot: Christian Heilmann)

Bild 12/19: Formularfeld ohne Namen "Other" in der Barrierefreiheit-Anzeige (Screenshot: Christian Heilmann)

Bild 13/19: Das Probleme Werkzeug (Screenshot: Christian Heilmann)

Bild 14/19: Das Probleme-Werkzeug mit Informationen, welche Bilder keine Textalternativen haben (Screenshot: Christian Heilmann)

Bild 15/19: Die Experimente-Liste der Entwicklerwerkzeuge in Edge (Screenshot: Christian Heilmann)

Bild 16/19: Kontrast Report im Probleme-Werkzeug (Screenshot: Christian Heilmann)

Bild 17/19: Das Elemente-Werkzeug mit Erklärung, warum das HTML Element eine Sprache definiert haben muss (Screenshot: Christian Heilmann)

Bild 18/19: Live-Barrierefreiheit Analyse in Visual Studio Code (Screenshot: Christian Heilmann)

Bild 19/19: Die Problemeliste in Visual Studio Code mit Barrierefreiheit-Problemen (Screenshot: Christian Heilmann)

Problematische Seitenelemente dagegen zeigen ein Ausrufezeichen an:

Wenn man nun auf das Seitenelement klickt, öffnet dies das Elemente-Werkzeug und in den Formatvorlagen kann man sehen, welche Farben eingesetzt wurden.

Das Anklicken des farbigen Quadrats öffnet einen Farbpicker, in dem das Kontrastverhältnis dargestellt wird. Bei nicht ausreichendem Kontrast zeigt der Picker einen durchgestrichenen Kreis an.

Wenn man den Knopf mit dem Pfeil nach unten anklickt, zeigt der Farbpicker verschiedene Möglichkeiten an, eine Farbe zu wählen, die genug Kontrast zur Hintergrundfarbe hat.

Man kann entweder die zwei vorgeschlagenen Farben auswählen (AA und AAA sind dabei die WCAG-Standards für Barrierefreiheit(öffnet im neuen Fenster) ), mit der Pipette eine Farbe in der Seite aufnehmen oder eine Farbe im Farbmenü oben entlang der weißen Linien auswählen.

Hat man eine Farbe gewählt, zeigt der Farbpicker auch deren Kontrast an. Bei Farben mit genug Kontrast signalisieren Haken, dass sie den AA- und AAA- Qualitätsansprüchen genügen.

Bei der Wahl von Farben im Netz gibt es noch mehr zu beachten, zum Beispiel, dass die genutzten Farben auch für Menschen mit Farbenblindheit verständlich sind, oder auch wie Nutzer der hohen Kontrasteinstellung von Betriebssystemen die Seite erleben. Auch dafür gibt es Simulationen in den Browser-Entwicklerwerkzeugen(öffnet im neuen Fenster) .

Alternativtext und fehlende Beschreibungen

Das Inspect-Tool hilft auch bei dem Problem fehlender Alternativtexte für Bilder und leerer Verknüpfungen und Knöpfe. Alternativtexte dienen dazu, etwa Menschen mit Sehbehinderungen oder kognitiven Einschränkungen beim Verständnis von Bildern zu unterstützen. Wieder ist hier der Abschnitt der Barrierefreiheit des Tools hilfreich. Diesmal geht es aber um die Rolle und den Namen des Elements. Das folgende Bild zum Beispiel hat zwar die Rolle eines Bildes, aber keinen Alternativtext, daher ist der Name leer.

Das Bild mit einem Alternativtext hat einen Namen und ist somit auch barrierefrei.

Alternativtexte sollten immer erklären, warum das Bild da ist und was es darstellt. Nicht nur, dass es ein Bild ist. Wenn Bilder allein zur Zierde da sind, ist es sinnvoller, sie als Hintergründe einzubinden.

Das Problem mit Verknüpfungen und Knöpfen, die leer sind, entsteht oft, wenn man ein Bild in einem Anker-Element oder Knopf einfügt, das keinen Alternativtext hat. Damit ist dann der Name des Elements wieder leer. Im folgenden Fall hat der Anker den Text "More" und den Pfeil als SVG-Element - und damit einen Namen.

Wenn der Text nicht vorhanden ist und das SVG-Bild keinen Titel hat, ist die Verknüpfung namenlos und damit nicht barrierefrei.

Formularfelder ohne Beschreibungen

Auch bei Formularfeldern ist es wichtig, ihnen mittels eines Label-Elements einen Namen zu geben. Das folgende Eingabefeld hat ein Label und ist damit barrierefrei.

Dieses hat keins, daher zeigt das Inspect-Tool an, dass der Name fehlt.

Ein einfacher Test, um herauszufinden, ob ein Formularfeld mit einem Label verbunden ist, besteht darin, auf den Text zu klicken. Wenn das Label passend mit dem Feld verbunden ist, wird dadurch das Eingabefeld fokussiert. Das ist gerade bei kleinen Formularelementen sehr praktisch.

Automatische Problemerkennung mit dem Probleme-Werkzeug

Das Inspect-Tool ist ein praktisches Werkzeug, um eine Seite testen. Allerdings kann kann das ziemlich lange dauern. Viele Probleme kann der Browser auch automatisch erkennen und als Abarbeitungsliste anbieten. Dafür gibt es das Probleme-Werkzeug, das auflistet, was mit dem offenen Webprodukt falsch läuft. Das Probleme-Werkzeug erklärt vieles, aber in diesem Fall hier interessiert uns nur die Barrierefreiheit.

Leider werden die Probleme derzeit nur auf Englisch erklärt, aber es wird daran gearbeitet, diese auch auf Deutsch zur Verfügung zu stellen.

Wenn man die Knöpfe mit den Pfeilen im Bereich Barrierefreiheit anklickt, bekommt man Erklärungen, warum etwas ein Problem und welches Element betroffen ist sowie Verknüpfungen zu noch detaillierteren Informationen.

Es gibt auch eine Möglichkeit, Kontrastprobleme in dem Werkzeug anzuzeigen. Da sich das allerdings negativ auf die Leistung der Entwicklerwerkzeuge auswirken kann, ist diese Option derzeit noch ein Experiment. Wenn man das Zahnrad anklickt, kann man das Experiment anschalten. Der Name ist Enable automatic contrast issue reporting via the Issues panel .

Nach dem Einschalten und einem Neustart der Entwicklerwerkzeuge wird nun auch eine Liste der Elemente angezeigt, die nicht genug Kontrast haben.

Wenn man auf die Elementverlinkungen klickt, kommt man automatisch zu dem Element.

Im Elemente-Werkzeug werden problematische Elemente ebenfalls herausgehoben. Ähnlich wie bei Word oder anderen Textverarbeitungsprogrammen sind diese unterringelt, und wenn man mit der Maus darüber fährt, bekommt man genauere Informationen, was das Problem ist.

Damit wäre dann auch das letzte Problem aus dem Webaim-Report gelöst.

Fehlerbehebung während der Entwicklung

Dass der Browser uns hilft, Probleme zu erkennen, ist toll, setzt jedoch eigentlich zu spät an - nämlich, wenn die Fehler schon gemacht wurden. Für Nutzer von Visual Studio Code als Texteditor geht es sogar noch einfacher. Wenn man die Erweiterung Microsoft Edge Devtools for VS Code (öffnet im neuen Fenster) installiert, wird HTML und CSS automatisch auf Probleme getestet und man bekommt durch Unterringelung angezeigt, welche Elemente problematisch sind.

Man kann sich auch in der Problemliste alle Fehler im ganzen Projekt anzeigen lassen.

Die Fehleranalyse ist hierbei live. Wenn man also ein Bild ohne Alt-Attribut eintippt, wird das rot unterringelt. Sobald eines eingefügt wird, verschwindet die Fehleranzeige wieder. Das ist genauso einfach, wie wenn man sich in Word vertippt hat.

Ein guter Anfang

Natürlich sind nicht alle Probleme mit Barrierefreiheit mit diesen Werkzeugen zu vermeiden. Oft ist es auch so, dass Probleme erst durch Software von Drittanbietern oder das CMS entstehen. Allerdings hilft das Wissen über die browsereigenen Werkzeuge, sehr einfache Probleme zu verhindern - und somit die eigene Webseite vielleicht besser nutzbar zu machen als die 1.000.000 meistgenutzten Webseiten.

Chris Heilmann ist seit 1997 Webentwickler, bloggt seit 2005 auf Christianheilmann.com(öffnet im neuen Fenster) und ist Autor mehrerer Bücher über Javascript und Barrierefreiheit. Derzeit lebt er in Berlin und arbeitet als Principal Program Manager mit seinem Team in Microsoft an Entwicklerwerkzeugen.

Zur Startseite 64 Kommentare

Reklame Hier geht es zu den aktuellen Blitzangeboten bei Amazon