Sechs schnelle Wege zum barrierefreien Coding
Das Thema barrierefreie Programmierung kann einschüchternd wirken. Wenn man aber erst einmal damit beginnt, stellt man fest, dass es gar nicht so beängstigend ist. Am besten fangen Entwickler klein an und arbeiten sich dann nach oben. Sechs schnelle Barrierefreiheit-Checks helfen ihnen dabei.
Beim Thema Barrierefreiheit kann man als Entwickler schnell einer Analyse-Paralyse verfallen: Es gibt vermeintlich immer irgendetwas, das man erst noch überprüfen muss, etwas, von dem man gehört hat, dass jemand anderes es bereits tut, oder einfach nur das vage Gefühl, dass man noch nicht genug weiß. Nur noch ein weiterer Blog, ein weiterer Konferenzvortrag, ein weiteres Video – dann bin ich bereit, mit dem Schreiben von barrierefreiem Code zu beginnen. In der Zwischenzeit bleiben die Nutzer auf dem gleichen alten, unzugänglichen Code sitzen.
Warum nicht einfach nach bestem Wissen und Gewissen loslegen, barrierefreien Code schreiben und sich dabei bewusst sein, dass man auch Fehler machen kann? Softwareentwicklung funktioniert doch schließlich immer so. Wir programmieren Dinge mit den Fähigkeiten, die wir haben, verwenden die uns bekannten Best Practices und halten uns an die aktuellen Webstandards. Mit der Barrierefreiheit verhält es sich genauso. Man programmiert barrierefreie Funktionen so, wie es einem möglich ist, nach seinem derzeitigen Wissen und basierend auf den aktuellen Richtlinien für Barrierefreiheit. Code ist nicht in Stein gemeißelt, oder? Man kann immer zurückgehen und aktualisieren.
Wie soll ich anfangen?
Am besten fängt man klein an und arbeitet sich nach oben. In einer komponentenbasierten Anwendung funktioniert dieser Ansatz besonders gut, weil sie natürlich in diese Bausteine unterteilt ist. Entwickler können mit dem Hinzufügen von Barrierefreiheitsfunktionen zu ihren Basiskomponenten beginnen und diese dann bei der Skalierung und der Verwendung in anderen Komponenten (und dann dieser Komponenten in wieder anderen usw.) ohne weiteren Aufwand nutzen. Man kann sich eine Handvoll Basiselemente aussuchen, die immer wieder in der Anwendung benutzt werden und sie schnellen Barrierefreiheit-Checks unterziehen. Dabei helfen die folgenden sechs Fragen:
1. Verwendet diese Komponente semantisches HTML?
Die wichtigste Maßnahme zur Verbesserung der Barrierefreiheit ist die Verwendung des richtigen semantischen Elements für die jeweilige Aufgabe. Semantisches HTML hilft Screenreadern zu erkennen, was sie sehen, erleichtert die Navigation mit der Tastatur und organisiert eine Seite von innen heraus. Wenn wir eine Website oder eine App öffnen, überfliegen wir in der Regel kurz den Inhalt, um schnell das zu finden, was wir brauchen. Sehbehinderte Nutzer können das nicht immer, aber ihre Bildschirmleser ermöglichen es. Sie lesen ihnen die Überschriften von Abschnitten vor und ermöglichen es ihnen, vorwärtszuspringen; informieren sie darüber, womit sie interagieren können, indem sie nach Schaltflächen suchen; lesen Inhalte im Listenformat vor oder können schnell durch Menüs und Formulare navigieren sowie vieles mehr. Das alles können Screenreader aber nur, wenn die richtigen Elemente verwendet werden und nicht einfach nur ein div über alles gelegt ist.
Die meisten Entwickler sind bereits mit einer Handvoll gängiger semantischer HTML-Tags vertraut: Die textbezogenen Tags (h1 bis h6 und p) zählen neben button oder img wahrscheinlich zu den bekanntesten. Darüber hinaus profitieren Anwendungen von nav für die Navigation, header, footer main, section, article und aside für die Definition der Inhalte, forms für Formulare mit Benutzereingaben und table für Datentabellen. Es lohnt – falls noch nicht geschehen – sich mit der aktuellen Liste der verfügbaren HTML5-Elemente vertraut zu machen. Je mehr korrekte semantische Tags zum Einsatz kommen, desto zugänglicher wird eine Anwendung. Sie sind ein "Quick Win" und bieten eine wunderbare Möglichkeit, die Barrierefreiheit sofort zu verbessern!
2. Haben alle Bilder einen Alt-Text?
Einen weiteren schnellen Erfolg verspricht das Durchsuchen der Komponenten nach img tags. Wenn nicht alle Bilder einen Alt-Text enthalten, bietet sich eine zusätzliche Möglichkeit, die Barrierefreiheit zu optimieren. Alt-Text, kurz für alternativer Text, ist ein beschreibender Text, der einem sehbehinderten Nutzer (oder jemandem, der die Bilder nicht laden kann) erklärt, was auf den Bildern zu sehen ist. Um Bilder mit Alt-Texten auszustatten, müssen lediglich den img tags die Beschreibungen hinzugefügt werden.
Beim Verfassen von Alt-Texten sind einige Dinge zu beachten:
- Es muss nicht "Bild von" oder "Foto von" eingefügt werden, weil das implizite Informationen sind. Lediglich bei Illustrationen, Gemälden oder anderen Kunstwerken geben solche Angaben den Nutzern einen wichtigen Kontext.
- Ein leerer Alt-Text sollte nur bei dekorativen Bildern eingefügt werden. In den meisten Fällen ist alt="" ein Muster, das es zu vermeiden gilt. Die Ausnahme von dieser Regel sind rein künstlerische Elemente. Ränder, Trennlinien und andere Dinge, die dazu dienen, eine Seite hübsch aussehen zu lassen, vermitteln den Nutzern keine wertvollen Informationen.
- Anschaulichkeit ist gefragt! Bilder sollten nicht nur mit ein oder zwei kargen Worten erklärt werden. alt="Kuchen" ist wesentlich weniger anschaulich als alt="Ein Schokoladenkuchen mit Kerzen, vor einem kleinen Mädchen, das einen Geburtstagshut und ein rosa Kleid trägt"
- Alle relevanten Texte aus den Bildern selbst sollten in die Beschreibungen aufgenommen werden. Grundsätzlich ist es zwar keine gute Idee, Bilder zu verwenden, die Texte enthalten, aber in manchen Fällen lässt sich das nicht vermeiden – etwa bei Buchdeckeln oder Verkehrsschildern. Ihre Beschriftungen sollten in die Alt-Angabe aufgenommen werden, weil den Nutzern diese wichtigen Informationen sonst verloren gehen.
3. Wurde eine barrierefreie Farbauswahl getroffen?
Farbe ist mächtig, keine Frage. Man darf aber nicht vergessen, dass eine farbige Gestaltung nicht immer für alle Nutzer zugänglich ist. Dabei fallen einem an erster Stelle natürlich blinde und farbenblinde User ein, aber es sind nicht nur sie. Die Wirkung der gewählten Farben kann auch bei Nutzern beeinträchtigt werden, die Night Shift aktiviert haben, im grellen Sonnenlicht stehen oder mit Sonnenbrille auf ihr Smartphone schauen. Eine barrierefreie Farbauswahl ist für alle User vorteilhaft und den Aufwand wert.
Bei der Auswahl der Farben für seine verschiedenen UI-Elemente sollte man darauf achten, dass diese einem barrierefreien Standard für Farbkontrast entsprechen. Die WCAG (Web Content Accessibility Guidelines) definieren drei Stufen für Farbkontrastverhältnisse: "Failing", "AA" und "AAA". Stufe AA bedeutet, dass die Farben ausreichend kontrastreich sind, um lesbar zu sein, manchen Nutzern aber dennoch Probleme bereiten könnten. Stufe AAA erreicht einen extrem hohen Kontrast, der für die meisten User lesbar ist. AAA sollte immer das Ziel sein, aber ein "Failing" zu vermeiden, ist schon einmal ein guter Ausgangspunkt.
Entwicklern stehen zahllose Online-Tools wie etwa der Adobe Color Contrast Checker zur Verfügung, um ihre Farbkontraste zu überprüfen. Sie können dort ihre Vorder- und Hintergrundfarben eingeben und sparen sich das Rätselraten bei der Ermittlung das Farbkontrastverhältnisses.
Ein anderer wichtiger Aspekt von Barrierefreiheit ist es, zu vermeiden, dass Informationen allein durch Farbe vermittelt werden. Formulare sind dafür ein gutes Beispiel. Oft wechselt bei Formularen der Rahmen des Eingabeelements auf Rot, um eine fehlgeschlagene Validierung anzuzeigen. Das ist auch gar nicht weiter schlimm, solange ein Symbol, ein Text oder ein anderes Element hinzugefügt werden, um dem Nutzer anzuzeigen, dass etwas nicht in Ordnung ist. Wenn man sich allerdings allein auf die rote Farbe des Rahmens verlässt, wird ein großer Prozentsatz der Nutzer nicht herausfinden, warum sie ihr Formular nicht abschicken können.
4. Kann ich mit der Tastatur durch den Inhalt navigieren?
Ein guter Check für Barrierefreiheit ist auch der Versuch, die eigenen Komponenten zu verwenden, ohne dabei die Maus zu berühren. Die Navigation mit der Tastatur ist ein wichtiger Bestandteil von Barrierefreiheit, weil es viele Gründe gibt, warum eine Maus für Nutzer nicht praktikabel oder nutzbar ist: etwa Blindheit, Verformung und Verlust von Gliedmaßen oder eingeschränkte Feinmotorik. Einige Power-User ziehen es vielleicht auch einfach vor, ausschließlich die Tastatur zu benutzen, weil sie schneller und effizienter ist als eine Maus.
Die gute Nachricht ist: Tastaturnavigation gibt es mit guten alten HTML und CSS kostenlos. Semantisches HTML spielt auch hier eine entscheidende Rolle, denn es ermöglicht den Nutzern, zwischen interaktiven Elementen zu springen, Kontrollkästchen ein- und auszuschalten, Dropdown-Menüs zu navigieren, zu scrollen und vieles mehr – aber nur, wenn für all diese Dinge auch tatsächlich HTML verwendet wurde. Wenn ein "Button" in der Praxis nur ein div mit einer onClick-Aktion ist, dann geht die ganze schöne eingebaute Barrierefreiheit flöten! Es ist zwar möglich, diese Elemente mit Hilfe von ARIA-Landmarks und erzwungenen Fokus-Indikatoren barrierefrei zu machen, aber es geht viel einfacher und schneller, wenn man nicht versucht, das Rad neu zu erfinden.
Beim Check der Tastaturnavigation sollten Entwickler Folgendes beachten:
- Sieht man einen visuellen Indikator dafür, auf welches Element man sich gerade konzentriert? Diese Fokus-Indikatoren erscheinen normalerweise immer – es sei denn, sie wurden überschrieben, weil man die Gliederungsstile des Elements auf 0 oder gar nicht eingestellt hat. Man kann den Fokus-Stil natürlich ändern, damit er besser zum Look-and-feel einer Marke passt, sollte ihn aber nicht entfernen und auch immer darauf achten, dass er nicht zu subtil ist.
- Kann man auch auf nicht interaktive Elemente fokussieren? Die Nutzer sollten nur auf ein Element fokussieren können, mit dem sie auch in irgendeiner Weise interagieren können. Die Fokussierbarkeit von Elementen lässt sich zwar durch die Verwendung von tabindex erzwingen, aber wenn der Nutzer damit gar nicht interagieren kann, sollte sichergestellt sein, dass diese Funktion nicht angewendet wird.
- Wie lange dauert es, die Seite mit der Tastatur zu navigieren? Nutzer sollten nicht gezwungen sein, endlos herumzusteuern, um zum gewünschten Element zu gelangen. Es ist wichtig, semantisches HTML zu verwenden, um die Seite in kleinere Abschnitte zu unterteilen (main, article, nav usw.) und bei Bedarf Sprunglinks zu weiter unten liegenden Inhalten anzubieten.
- Folgt die Tastaturnavigation dem visuellen Fluss der Seite? Wenn man sich mit der Tastatur durch eine Seite arbeitet, sollte der Fokus dem Inhalt folgen: von oben nach unten, von links nach rechts. Auch das geschieht von selbst, wenn das zugrundeliegende HTML richtig strukturiert ist. Immer beachten, dass HTML für die Struktur sowie Organisation und CSS für die visuellen Einstellungen (falls erforderlich) zuständig sein sollte!
5. Brauche ich ARIA-Attribute?
ARIA-Attribute können einer der verwirrendsten Aspekte des barrierefreien Codings sein. Also sollten wir zunächst einmal versuchen, etwas Klarheit zu schaffen. ARIA steht für "Accessible Rich Internet Applications" und ARIA-Attribute gibt es, damit komplexere Widgets und benutzerdefinierte Tools barrierefrei verwendet werden können. Ein Großteil der Verwirrung um ARIA-Attribute resultiert aus ihrer Verwendung in der Vergangenheit. In HTML4 gab es weitaus weniger semantische Elemente und wenn ein Entwickler ein interaktives Element einfügen wollte, für das es keinen HTML-Tag gab, musste er es selbst erstellen und dann mit ARIA-Attributen ergänzen, um volle Barrierefreiheit zu erreichen. Heute gibt es immer weniger Fälle, in denen das notwendig ist, weil inzwischen eine große Vielfalt an HTML5-Elementen existiert – und damit ist auch der Bedarf an ARIA-Attributen geringer geworden (solange man semantisch programmiert). Wenn man ein natives HTML5-Element verwendet, muss man keine ARIA-Attribute einfügen: Diese Features sind bereits integriert. Deshalb sollten Entwickler, wann immer möglich, das semantische HTML-Element verwenden.
Es gibt aber Situationen, in denen ARIA-Attribute dennoch nützlich sind. Das sind einige der häufigsten:
- ARIA Live zur Ankündigung von Inhaltsänderungen
Bei modernen Anwendungen ist es üblich, dass nach dem initialen Laden einer Seite neue Inhalte auf dem Bildschirm erscheinen – beispielsweise durch Feeds, die automatisch aktualisiert werden, oder Benachrichtigungen. Diese neuen Inhalte sind für die meisten Nutzer offensichtlich, aber nicht für Nutzer von Screenreadern. Durch die Einbindung von aria-live kann man Bereiche auf einer Seite kennzeichnen, in denen dynamische Inhalte geladen werden und der unterstützenden Technologie mitteilen, dass sie diesen Bereich für Aktualisierungen im Auge behalten soll. Man kann aria-live entweder höflich oder durchsetzungsfähig einstellen. Damit wird festgelegt, ob der Screenreader die nächste Leerlaufphase abwartet, um die Aktualisierung des Inhalts zu verkünden, oder ob er den Nutzer unterbricht, um sie sofort mitzuteilen. Logischerweise sollte man sich immer für höflich entscheiden, außer, die Mitteilung ist wirklich dringend und duldet keinen Aufschub. - ARIA-Labels für Elemente, die keinen Text enthalten
Ein gutes Beispiel dafür ist eine Schaltfläche, die ein Symbol zur Identifizierung verwendet, aber keinen Text. In so einem Fall sollte aria-label eingefügt werden, um dem Element einen barrierefreien Namen zu geben. - ARIA Roles für Elemente, die keine semantische Entsprechung haben
Wenn man ein benutzerdefiniertes Widget erstellt, für das sich die eingebauten HTML5-Elemente nicht verwenden lassen, sollte man den Nutzern mitteilen, welche Funktion das Element übernimmt, indem man ihm eine aria-role zuweist. Dadurch erhalten die Nutzer einen zusätzlichen Kontext, der ihnen hilft, das Layout zu verstehen.
6. Wie klingen die Komponenten mit einem Screenreader?
Für den letzten Teil des Barrierefreiheit-Checks benötigt man einen Screenreader. So gut wie jedes größere Betriebssystem verfügt inzwischen über einen eingebauten Bildschirmleser, die beiden gängigsten sind VoiceOver für Mac und Narrator für Windows. Entwickler können sie in den Systemeinstellungen des Betriebssystems aktivieren und dann wie gewohnt navigieren und sich ihre Komponenten anhören.
Dieser Test ist besonders wirkungsvoll, wenn er mit reiner Tastaturnavigation kombiniert wird. Man bekommt sofort ein Gefühl dafür, wenn etwas schwierig zu navigieren ist und wie viel Inhalt vorgelesen wird, während man versucht, eine Aufgabe zu erledigen. Entwickler sollten sich mindestens einen Tag lang (idealerweise noch länger) in die Lage ihrer Nutzer versetzen, indem sie mit eingeschaltetem Screenreader arbeiten. Sie werden vielleicht überrascht sein, wie sich ihre Anwendung anhört!
Bereit zu starten?
Barrierefreies Coding mag einschüchternd wirken, aber wenn man erst einmal damit beginnt, wird man feststellen, dass es gar nicht so beängstigend ist. Sicher: Es gibt eine Menge großartiger Inhalte zu diesem Thema, aber man muss aufpassen, nicht in der Recherchephase steckenzubleiben und die eigentliche Implementierung endlos vor sich herzuschieben. Jede Optimierung ist besser, als Barrierefreiheit völlig zu ignorieren. Barrierefreie Funktionen kommen allen Nutzern zugute: Diese großartige Möglichkeit, die User Experience der eigenen Anwendung zu verbessern, sollte man sich als Entwickler wirklich nicht entgehen lassen.
