Artikel von Christina da Silva
Kürzlich wurde ich gefragt, ob wir eine Liste mit den wichtigsten und einfachen Aufgaben hätten, um eine Website möglichst barrierefrei zu gestalten. Tasks, die ohne Diskussion vom Entwickler mit dem Designer oder dem Kunden auf kurzem Weg umgesetzt werden können. Quick Wins für Accessibility! Welche einfachen Veränderungen entfalten eine grosse Wirkung? In diesem Blogeintrag führe ich in das Thema ein, erkläre zunächst die Basics und erläutere warum Barrierefreiheit so relevant ist und stelle weiter unten eine Quick-Win-Checkliste zur Verfügung.
Es gibt einige Grundregeln, für die Barrierefreiheit von Webseiten , die ich hier zunächst aufliste und im Anschluss erläutere, bevor ich zu den echten Quick Wins komme:
HTML semantisch korrekt verwenden und aufbauen
Inhalt, der nicht durch Text beschrieben und nicht nur visuelle Dekoration ist, mit beschreibendem Text für den Screenreader ergänzen
Rein dekorative Elemente für Screenreader verstecken
Tastaturbedienbarkeit gewährleisten und Fokus erkennbar setzen
Warum ist die HTML-Struktur so wichtig?
Menschen, die durch Beeinträchtigung ihrer Sinne nicht in der Lage sind, Websites ohne Weiteres zu erfassen, nutzen häufig Screenreader, die ihnen dies ermöglichen. Ein Screenreader ist eine eigenständige oder bereits im Betriebssystem integrierte Applikation oder ein Browser-Addon. Diese wandelt die auf dem Bildschirm zur Verfügung stehenden Informationen in eine natürliche Sprache um und liest sie dem Benutzer vor. Auf einer Webseite wird dafür die HTML-Struktur und deren Inhalt verwendet und vom Screenreader interpretiert.
Natives HTML ist bereits accessible. Komponenten wie Buttons, Links, Labels oder Formfelder werden bereits als solche vom Screenreader erkannt und entsprechend vorgelesen. Es nimmt uns als Developer also Arbeit ab. Anders ist es bei Custom Widgets, die der Screenreader nicht ohne weitere Hinweise erkennen kann. Hinzu kommt, dass Screenreader Tastaturkürzel haben, um beispielsweise über alle Links auf einer Seite zu springen oder durch alle Headings zu navigieren.
Man kann sich einen Screenreader wie eine Art Lesekopf oder Plattenspielernadel vorstellen, wobei immer nur genau das erkannt und wiedergegeben wird, was sich direkt darunter befindet. Elemente ohne Text oder weitere Erkennungsmöglichkeiten können nicht vorgelesen werden und bleiben Usern mit besonderen Bedürfnissen unverständlich oder gänzlich unzugänglich.
Wie werden Websiteinhalte für den Screenreader lesbar?
Bei Website-Elementen für Screenreader kann zwischen zwei Arten unterschieden werden: jenen, die visuell sichtbar sind und jenen, die visuell verborgen bleiben. Verborgen bleiben sollen zum Beispiel Elemente, die zusätzlichen Informationstext enthalten, der visuell bereits anderweitig dargestellt wurde.
Exklusive Screenreader-Inhalte können mit CSS visuell verborgen werden, so dass die DOM-Struktur erhalten bleibt und somit vom Screenreader lesbar ist. Der Accessibility Developer Guide schlägt hierfür folgende Klasse vor:
.visually-hidden {
position: absolute;
left: -10000px;
top: auto;
width: 1px;
height: 1px;
overflow: hidden;
}Damit werden Elemente ausserhalb des Bildschirms und so klein wie möglich dargestellt. Setzt man jetzt noch das Padding auf 0 und die Margins auf -1, hat man sogar ein Element mit Dimension 0x0, das aber immer noch in der DOM-Struktur enthalten ist.
In Zusammenhang mit Screenreadern und Accessibility kommt häufig der Begriff WAI-ARIA auf. WAI-ARIA steht für Web Accessibility Initiative - Accessible Rich Internet Applications haben zum Ziel, einen Webstandard zu erstellen, um Webseiten barrierefreier und für Screenreader verständlicher zu machen.
Wie versteckt man etwas vor einem Screenreader und warum?
Inhalte, welche für den Screenreader nicht sinnvoll sind, weil sie zum Beispiel nur der Dekoration dienen, sollten vor ihm versteckt werden, da sie für Benutzer von Screenreadern unnötige Informationen darstellen. Dies sind unter anderem Icons, einzelne Zeichen oder unbekannte Abkürzungen. Gleichzeitig sollte aber auch darauf geachtet werden, dass eine verständliche Alternative für die ausgelassenen Bereiche zur Verfügung gestellt wird.
Mit dem Attribut aria-hidden=”true” können einzelne Tags und all deren Kindelemente vor Screenreadern verborgen werden.
Tastaturbedienbarkeit und Fokus, besser mit Konzept
Um den roten Faden nicht zu verlieren, ist es wichtig, dass der Fokus jederzeit ersichtlich ist. Das heisst, werden die von Browsern individuell angewandten Fokus Styles überschrieben, so muss dieser dennoch in allen neuen Stylings klar ersichtlich sein. Wird der Fokus zum Beispiel mit blur von einem Element entfernt, sollte er direkt wieder gesetzt werden, da man ansonsten beim Navigieren im Leeren landet. Wenn nötig, kann der Tabindex der entsprechenden Elemente angepasst werden. Jedoch sollte der Seitenaufbau und deren HTML-Struktur so gewählt werden, dass dies nicht nötig ist.
Quick-Win-Checkliste für Accessibility
Folgende Anregungen sind Quick Wins, um die Accessibility auf Websites zu erhöhen. Mit der Checkliste für Developer erheben wir keinen Anspruch auf Vollständigkeit und wir freuen uns über email hidden; JavaScript is required.
Folgende Fragen sollten Developer mit ja beantworten können, um Webseiten barrierefreier zu gestalten:
Haben Buttons und Links aussagekräftigen Text?
Sind klickbare Elemente als Buttons und nicht als Link dargestellt?
Werden Links nur für Verlinkungen auf andere Seiten oder als Anchor verwendet?
Sind Eingabefelder mit ihren Labels verknüpft?
Haben alle inhaltlich relevanten Elemente einen beschreibenden Text?
Wurden Titel aussagekräftig gewählt oder ergänzt?
Sind die heading-Tags korrekt strukturiert?
Werden native HTML-Komponenten Custom Widgets vorgezogen?
Stimmt die angegebene Sprache im <html>-Tag mit der Textsprache überein?
Ist die Navigation zuoberst auf der Seite und kann mit einem Anchor-Link davor direkt zum Inhalt gesprungen werden?
Können alle Funktionalitäten nur mit der Tastatur erreicht und ausgeführt werden?
Ist der Fokus jederzeit erkennbar?
Wie erkennt man Lücken bei der Accessibility einer Website? Und wie können solche Lücken möglichst schnell entdeckt werden?
Um eine erste Übersicht darüber zu erhalten, wie barrierefrei eine Webseite ist, können Browser-Plugins wie beispielsweise WAVE unterstützen. Dieses findet schnell die vorhandenen Lücken und führt sie in einer Liste auf.
Developer könnten darüber hinaus einmal auf das Styling der Webseite komplett verzichten und schauen, wie weit die Seite dann noch bedienbar ist. Funktioniert noch alles? Kommt man noch überall zurecht? Finden sich doch noch labellose Komponenten?
Was häufig vergessen wird, sind die reine Tastaturbedienbarkeit und das Fokus Konzept. Dabei können folgende Fragen gestellt werden:
- Ist die Webseite auch nur mit Tastatur bedienbar?
- Können alle notwendigen Elemente erreicht werden?
- Folgt die Navigation dem Seitenverlauf oder wird unlogisch hin und her gesprungen?
- Ist zu jeder Zeit erkennbar, wo man sich mit dem Fokus befindet?
Was gibt es sonst noch und wofür ist das gut?
Von diesen kleinen Verbesserungen profitieren alle, nicht nur Benutzer mit Screenreadern. Developer kennen die Aussage: Schöner Code ist lesbarer und deshalb einfacher zu warten. Doch hiervon profitieren nicht nur Developer, sondern auch normaler Nutzer und Nutzer mit Screenreader. Besonders deutlich wird dieser Anwendungsfall bei eingeschränkter Internetverbindung, wenn die Styles nicht geladen werden können und alte Geräte oder Browser verwendet werden. Bei schlechten Sichtverhältnissen oder Sonneneinstrahlung profitieren darüber hinaus auch alle Nutzer von einem optimierten Kontrast.
Eine Webseite mit Screenreader zugänglich zu machen ist nur ein Teil der digitalen Barrierefreiheit. Es gibt noch viele weitere Möglichkeiten, den Zugang nicht nur visuell zugänglicher zu machen, sondern auch motorisch, kognitiv oder auditiv.
Hilfreiche Links
Folgende Webseiten haben mir immer wieder bei meiner Arbeit geholfen, Webapplikationen barrierefrei zu gestalten:
Ire Aderinokun’s Blog bitsofcode und ihr Accessibility Cheatsheet [https://bitsofco.de/the-accessibility-cheatsheet/]
a11y with Lindsey [www.a11ywithlindsey.com]
Accessibility-Developer-Guide [www.accessibility-developer-guide.com]
Mozilla’s Seite über Accessibility [https://developer.mozilla.org/en-US/docs/Web/Accessibility]
- die beiden Artikel von Manuel Matuzovic auf Medium über CSS und JavaScript
Ich befasse mich seit gut eineinhalb Jahren mit Accessibility auf Webseiten. Angefangen hat für mich alles mit einem Ticket, auf dem stand, die Applikation solle “AA compliant” werden. Damals wusste ich knapp, dass Bilder ein alt-Attribut haben und man auf Farben achten sollte.
Artikel von Christina da Silva