[…] You wouldn’t steal their cursor!
– Laura Carvajal
Entwickler sind für die technische Umsetzung verantwortlich. Wichtige Voraussetzungen für die Zugänglichkeit mit assistiven Technologien wie z.B. Screenreader oder Spracheingabe sind ein semantisch korrekter Code und eine gute Tastaturbedienbarkeit. Das heißt, alle Bedien- und Formularelemente sollten mit der Tastatur fokussierbar sein und zwar in einer schlüssigen Reihenfolge und mit einer sichtbaren Fokushervorhebung. Kann die Semantik mit nativem HTML nicht zur Verfügung gestellt werden, muss sie mit WAI ARIA ergänzt werden. Dies ist in der Regel bei dynamischen mit JavaScript gesteuerten Komponenten der Fall, sofern man nicht Module einsetzt, welche schon so angepasst sind. Die WAI ARIA Authoring Practices sind eine hilfreiche Ressource für die zugängliche Umsetzung von Widgets, wie z.B. Tap Panels oder Akkordeons.
HTML
Die folgenden Infos stammen aus einem Mitschrieb des Video-Kurses „Meeting Web Accessibility Guidelines“ von pluralsight.com. Hier der pdf-Mitschrieb zum Download.
Gutes semantisches HTML ist unabdingbar:
| Seitenstruktur | Inhaltsstruktur |
|---|---|
| Maschinen lesbarer Code | Menschen lesbarer Code |
| Landmarks Landmarks richtig einbauen (roles und html5 tags wie <nav>) Es sollten vor allem, wo möglich und sinnvoll, die Landmarks <header>, <main> und <footer> verwendet werden, außerdem noch <section> und evtl. <aside>. Dies dient vor allem der Verbesserung der Semantik und ist hilfreich für Screenreader. | Headlines Die Reihenfolge der Headline muss eingehalten werden (h1, h2, h3…), Sections sollten headings haben, wo es passt. Für Screenreader müssen Headlines aussagekräftig sein. Eine sinnvolle h1 muss auf jeder Seite sein. Man kann auch Headline, die offscreen sind, einsetzen (speziell als Hilfe für Screenreader, z. B. wenn auf der Seite visuell kein Platz für eine Headline ist), sollte aber damit nicht übertreiben. Ist außerdem bei Mehrsprachigkeit nicht so einfach zu handhaben. |
Seitenstruktur: Die visuelle Reihenfolge der Seite folgt der DOM order, damit die Navigation für Screenreader etc. verbessert wird. Eine gute Seitenstruktur ist wichtig für Screenreader.
DOM order:
Elemente sollten dort auf der Seite erscheinen, wo sie aufgrund ihrer Platzierung im html Code auch sind.
Beispiel eines Menüs:
Home | Navpunkt 2 | Suche
Im Code sollte diese Links so unter- bzw. hintereinander stehen, und nicht in einer anderen Reihenfolge (und dann mit css wieder umpositioniert)
<li><a href=“#“ title=“Home“>Home</a></li>
<li><a href=“#“ title=“Navpunkt 2″>Navpunkt 2</a></li>
<li><a href=“#“ title=“Suche“>Suche</a></li>
Es sollten auch absolut positionierte Elemente dort stehen, wo sie erscheinen, z. B. ein „to top“ Button ganz unten auf der Seite sollte soweit unten wie möglich im html platziert sein.
Gesamte Seite:
<!doctype html>
Richtiges Parsing ermöglichen durch: tags richtig öffnen und schließen, keine doppelten Element Attribute, keine doppelten ids (ids müssen eindeutig sein)
Sprache der Seite:
<html lang=“de“>
Wichtige Infos (auch wenn sie nicht als Fehler angezeigt werden, wenn sie fehlen):
<meta charset="utf-8"> <meta http-equiv="x-ua-compatible" content="ie=edge">
Der meta-tag darf nicht verwendet werden;
<meta http-equiv="refresh">
Titel
<title></title>
- Für jede Seite anders (auch gut für SEO)
Für Mobil:
<meta name="viewport" content="width=device-width, initial-scale=1.0, shrink-to-fit=no">
Relative Einheiten für das Sizing (rem)
Damit User mit der für sie geeigneten Technik zoomen können. User müssen bis zu 200% zoomen können, ohne Funktion und Lesbarkeit zu verlieren: Text, Bilder und Funktionen dürfen nicht abgeschnitten werden
Body: Landmarks (header, main, footer, nav, aside)
Mehrere Navigation (nav): aria-labels nötig
Inhaltsstruktur: h1 (eine, sollte das erste Element in sein) bis h6. Nicht skippen! Im Header sollte keine h1 sein.
Links
Links müssen eindeutig sein. Die Linkbezeichnung muss einmalig sein. Es darf keine Links geben, die gleich lauten, aber zu verschiedenen Zielen führen.
Der Sinn eines jeden Links (text only) sollte allein durch den Linktext klar werden (Links sollten aussagekräfitig sein). Links wie „Details“ oder „Read more“ sind zu vermeiden. Besser sollte man dann schreiben „Details zu Thema“ oder „Read more about xy“, oder einen anderen Teil im Absatz verlinken, oder die Überschrift.
Alles was als Link fungiert, muss einen anchor tag haben (href). Dann erscheint der Link in der „linkslist“ des Screenreaders und funktioniert auch mit dem Keyboard (wird angesprungen).
Links sollten nicht zu Buttons umfunktioniert werden. Wenn es ein Button ist, immer <button> verwenden. (Wichtig z. B. bei Formularen, weil der Screenreader sonst den Button nicht erkennt)
Fließtextlinks
Links müssen eindeutig oder „sprechend“ formuliert sein. Für die Barrierefreiheit ist es wichtig, dass alle Links außerhalb ihres Kontextes für sich stehen können, damit z.B. in Sprachausgaben die Navigation mit der Tabulatorentaste möglich ist.
Wenn mehrere Textbeiträge auf einer Seite angerissen werden und im Anschluss der Teaser ein Link mit der Bezeichnung „mehr“ zu weiteren Informationen führt, so sind die „mehr“–Links nicht eindeutig. Eindeutig wird der Link, indem
- der Text des Links erweitert wird, etwa „mehr zum Beitrag XY“, oder
- der Link ein aria-label mit der genaueren Bezeichnung erhält:
<a href=“ziel.html“ aria-label=“Mehr zum Artikel XY“>mehr </a>
Auch im Fließtext sollten alle Links außerhalb ihres Kontextes einen sinnvollen Bezug haben. Wenn also Text verlinkt wird, dann sollen die verlinkten Begriffe „für sich“ stehen. Beispielsweise ist in einem Satz „Die Grundsatzrede finden Sie auch in unserem Archiv.“ das Wort „Grundsatzrede“ vermutlich eindeutiger als „Archiv“.
Treffende Linkbezeichnungen
Listen
3 Typen mit verschiedenen Bedeutungen:
Ordered list, Unordered list, Description list (z. B. Glossar oder sogar FAQ)
<ol> <ul> <dl>
Warum Listen benutzen?
Um die Semantik zu nutzen, damit Screenreader besser damit umgehen können und Listen finden, den Typ der Liste festzustellen und die Anzahl der Listeneinträge zu bekommen, damit sie wissen wo in der Liste man sich befindet.
Navigation und Skip Links
Konsistente Navigaton
- Mehrere Wege um Seiten / Content zu finden
- Bedeutungsvoller Link Content
- Konsistentes Interface
- Skip Links
Genauer:
Innerhalb von <nav>: Liste machen
Navi-Einträge: Plain Text nutzen, keine Bilder
Navi-Einträge sollten immer und überall an der gleichen Stelle stehen und in der gleichen Reihenfolge sein
Mehrere Wege, Seiten zu finden: Navi, Suche (form mit role=“search“), Sitemap (verlinkt vom Footer aus)
Buttons und Image sollten immer gleich benannt werden, wenn sie die gleiche Funktion haben
Linktexte sprechend, wenn das nicht geht, für Screenreader Text einfügen (z. B. show-for-sr – mit css verstecken)
Skip Link: Ein Link am Beginn des <body> (vor der Navigation, muss der allererste Link auf der Seite sein), der zur id des Main Content (<main>) linkt (mit Klasse, um ihn per css anpassen zu können). Für ältere Browser muss man dem <main> auch noch noch den tabindex=“-1″ mitgeben. Css z. B.: position: absolute, top mit -Wert, damit der Link nicht zu sehen ist und dann mit pseudo Klasse :focus sichtbar machen über top: 0. Mehr Info über Skip Links gibt es hier. Der Skip-Link muss innerhalb einer Landmark stehen!
Zusätzlich zum css für skiplinks ist dieses js gut (Cross-browser Support)
var skipLink = document.querySelector('.skip-link');
skipLink.addEventListener('click', function(e) {
document.querySelector(skipLink.getAttribute('href')).focus();
});
Tabellen
Zum Darstellen von Daten in Reihen und Spalten. Nicht für Layout!
Bei einer sinnvoll aufgebauten Tabelle kann man sagen, welche Informationen in den einzelnen Spalten und Zeilen der Tabelle enthalten sind. Man kann diesen Inhalt allgemein fassen, nicht nur als eine Zusammenstellung der in den einzelnen Zellen abgelegten Werte. Die Bedeutung der einzelnen Spalten und Zeilen kann in den Überschriften gefasst sein. Das ist aber nicht zwangsläufig so, auch eine Tabelle ohne Überschriften kann sinnvoll strukturiert sein.
Für Screenreader muss man Tabellen aufbereiten:
<caption>
Jede Datentabelle muss beschriftet werden. Für Tabellen existiert dazu in HTML das caption-Element. Der Inhalt des caption-Elements kann von einem Screenreader mit der Tabelle in Verbindung gesetzt werden. Damit haben Screenreader die Möglichkeit die Beschriftung beim Vorlesen einer Seitenübersicht oder als Navigationshilfe zu verwenden. Die Beschriftung soll der Tabelle einen Titel geben, mit dem es möglich ist, die Tabelle gegenüber weiteren Tabellen zu identifizieren. Wichtig ist, dass die Beschriftung nicht die Informationen aus der Zusammenfassung des summary-Attributs wiederholt.
Das summary-Attribut ist in HTML5 für die Beschreibung von Tabellen nicht mehr erlaubt. Falls in HTML5-Dokumenten eine Beschreibung der Tabelle bereitgestellt wird, sollte diese auf anderem Wege umgesetzt werden, wie z. B. innerhalb von caption, mit Hilfe von aria-describedby oder figure und figcaption.
Zusätzlich zu <td> und <td> noch <thead><tfoot><tbody>
vor allem bei komplexen Tabellen, aber schadet auch so nicht.
<th><td>
Scope bei th wichtig (scope=”col”, scope=”row”, nicht bei td erlaubt) und headers (bei komplizierten Tabellen können ids und mehrere tbody und mehreren headers verwendet werden).
Bei komplizierten Tabellen, bei denen es wichtig ist, die Beziehungen der Zellen zueinander darzustellen, sollte mit scope (col, row, colgroup) und colgroups gearbeitet werden.
Wie kann man (ohne Screenreader) prüfen, ob eine Datentabelle richtig aufgebaut ist?
Man nimmt eine beliebige Zelle und liest sie zusammen mit den zugehörigen Spalten- und Zeilenüberschriften:
„[Überschrift(en) der Spalte] – [Überschrift(en) der Zeile]: [Inhalt der Zelle]“
Ist die Bedeutung der Zelle so verständlich?
Anwendungsbeispiel
Ein Anwendungsbeispiel mit <figure> und <figcaption> gibt es hier in WordPress, wenn man den Block „Tabelle“ einfügt (s. Quellcode):
| Headline 1 | Headline 2 |
|---|---|
| Daten | Daten |
| Daten | Daten |
| Footer 1 | Footer 2 |
Tags
<i> tag sollte nach Möglichkeit nicht für icons verwendet werden, ist aber ok wenn es nicht anders geht, bzw. das framework das so vorsieht.
Formulare
Die technischen Grundfunktionen eines Formulars – erfassen, ausfüllen und abschicken – müssen mit allen möglichen Mitteln der Ein- und Ausgabe gelingen. Konkret heisst das, Anbieter von Webseiten müssen assistierende Techniken wie z. B. Screenreader, Sprachsteuerung oder Spezialtastaturen berücksichtigen.
Artikel zu html/css für Formulare
- Formulare: Absende-Button nötig (nicht mit Return abschicken), inputs mit Label (wenn kein label möglich/gewünscht, dann z. B. mit aria-label arbeiten)
- Interaktive Elemente zeigen ihren Zweck und ihren Status:
Mit Tab erreichbar und sichtbar, wo man sich befindet (verändert das Element sein aussehen, wenn man es auswählt?)
Gibt es einen visuellen Hinweis, dass man hier etwas tun kann? - Buttons brauchen labels bzw. aria roles
- Wichtig: Formular mit Screenreader testen:
Verkündet der Screenreader den Namen jedes Elements, die Rolle, den gegenwärtigen interaktiven Status? Wenn die Rolle oder der Status unklar ist, muss man evtl. die entsprechenden ARIA Rollen hinzufügen.
Barrierefreie Formulare: Fehleridentifizierung, Farbe, Tastatur-Navigation / Fokus-Anzeige
- Farb-Kontrast Vordergrund zum Hintergrund ist wichtig (und umgebende Farben)
- Placeholder Texte sind ein Problem (wenn sie zu dunkel sind, hält man sie für
vorausgefüllte Felder, Browser behandeln sie unterschiedlich, in manchen
verschwinden sie sobald man ins Feld klickt und dann ist die Beschreibung, was ins
Feld muss weg -> ohne Label weiß man dann nicht mehr was hier hin muss) - Besser sind Labels
- Gruppierung wichtig (fieldset + legend z. B. bei Radios und Checkboxen)
- Pflichtfelder kennzeichnen
- Fokus-Anzeige unbedingt drin lassen (man kann sie per css hübscher machen)
- Keyboard-Traps vermeiden
- Fehlermeldungen gut sichtbar und zuordenbar, und nicht nur mit Farbe kennzeichnen und Infos liefern, wie man den Fehler beheben kann
- Keine „disabled“ buttons – Beispiel: der Absendebutton wird auf disabled gestellt, bis alles ausgefüllt ist. Mögliche Probleme dadurch: es gibt kein Feedback, das Interface sieht kaputt aus, man sieht ihn schlecht, er ist nicht fokussierbar, er wird evtl. missverstanden, der User bekommt nicht mit wenn der Button aktiv wird,
Man sollte die native HTML5 Browser Validierung abschalten, da diese „HTML5 validation ballons“ nicht barrierefrei sind, und stylen kann man sie auch nicht wirklich.
z. B. <form…. novalidate>
Text (<p>) sollte außerhalb von <form> stehen.
Labels:
<label for=“idinput“>Name (Required):</label><input id=”idinput” required>
Geht auch: explicit label (ohne for=)
<label><input></label>
Gutes Erklärvideo zu Labels bei AccessibilityOZ
Die richtigen types für inputs verwenden (text, email, tel).
Gruppieren mit <fieldset> + <legend> verwenden (auf jeden Fall bei Radio Buttons und Checkboxen).
Man kann visuelle Labels auch nur für Screenreader anzeigen, aber man sollte überlegen, ob sie für sehende Benutzer auch interessant/hilfreich sind.
Fehler-Validierung mit css und js und aria
z. B.
<span class=“error-message”>Fehlermeldung</span>
Oder mit Blur (mit aria-live=“assertive“) -> Die Fehlermeldung wird gleich vorgelesen, wenn man nichts eingibt:
<label for=“name“ aria-live=“assertive“>Name (Required):<span class=“errormessage”> Fehlermeldung</span></label><input>
Section am Anfang der <form> für eine Liste der Fehler mit aria-live
<section id=“errors“ aria-live=“assertive” tabindex=”-1”>
Medien
Bilder
- Kein Text auf Bildern verwenden
- Text-Alternativen für Bilder anbieten: alt attribute, dekorative Bilder müssen ein leeres alt Attribut haben: alt=““ (wird im Screenreader dann nicht gelistet)
- Tipps für guten ALT Text: das Bild nicht buchstäblich beschreiben „Dies ist ein Bild das zeigt: ….“. Besser: Beschreiben was die Bedeutung oder der Zweck des Bildes ist. Was visuell übermittelt wird, muss auch programmatisch übermittelt werden (Wahrnehmbarkeit) Zu diesem Thema siehe auch: A11y: Bilder und Alt-Text
Hintergrundbilder mit css
- Brauchen Text-Content: Beschreibung des Icons
SVG
- Role beim svg vergeben (role=“img“)
- <title> mit id benutzen
- <desc> bei längerem Content
- Aria-labelledby benutzen und den title oder die desc zu referenzieren
Audio
- Textalternative muss da sein (transcript des audio): Bezahlter Service,
Spracherkennungs-Apps (Google Docs Voice Typing, Windows Speech Recognition,
Apple Dictation), Manuell - Tipps: Namen der Sprecher einfügen, Alles beschreiben, auch sounds (die ganze
Geschichte beschreiben) - Wie? Inline, Link zum Transcript
Video
- Textalternative wie bei Audio Dateien
- Captions anbieten (Open: immer sichtbar, in Videos eingebettet / Closed: kann vom
User an- und abgeschaltet werden) - YouTube bietet Auto-subtitle an (Guter Startpunkt)
- Manueller Eintrag
- Video Captioning Services
- Audio Beschreibung: Alle nicht sichtbaren Hinweise beschreiben, z. B. Donner und
Blitz vor dem Fenster.
- Barrierefreie Online-Videos zeichnen sich durch folgende Merkmale aus:
- sie sind barrierefrei erreich- und bedienbar (barrierefreie Einbindung),
- für höreingeschränkte Menschen wird eine Untertitelung zur Verfügung gestellt und
- wichtige visuelle Informationen werden für blinde Menschen über eine Audiodeskription vermittelt.
- Guter Artikel zum Thema
Inhalt des Artikel: Hier wird erklärt, was die Anforderungen an das Media-Element gemäß BITV sind: Tastaturbedienbarkeit, Sichtbarer Fokus, Objekt identifizierbar und Bedienelemente beschriftet (über <video> ist das gegeben, Bedienelemente müssen in der Hauptsprache der Website beschriftet sein), Kontrast, Untertitelung (Captions) einbindbar (je nach Player verschieden, dyamische Text-Untertitelung geht über das html Element <track>), Audiodeskription einbindbar. - Thema YouTube: Wer Videos über YouTube einbetten möchte, sollte sich an den Empfehlungen für Entwickler orientieren, damit YouTube-Videos über einen HTML5-Player wiedergegeben werden.
Animationen
Wenn man Animationen auf einer Website anbietet, sollte man immer gut überlegen, ob man sie unbedingt braucht, und wenn ja, sollte man die Zugänglichkeit beachten. Wichtig ist in diesem Zusammenhang:
- Die Animation sollte abstellbar sein (über das css über die media query „prefers-reduced-motion“ und/oder über einen Button zum Starten und Stoppen der Animation)
- Sie darf nicht schneller blinken als 3 mal in der Sekunde oder schneller
- Es sollte auf keinen Fall zu viel animiert werden
Weiteres
- Kein Autoplay (pause, stop, hide)
- Kein Flackern
- Iframes sollten title attribute haben
iframes
iframes brauchen titles / Beschreibungtitle– und name-Attribute sind gemäß Spezifikation und im Sinne der Barrierefreiheit bei der Verwendung von Frames erforderlich
Frames können mit aussagekräftigen title-Attributen auch von Screenreadernutzern für die Navigation auf Webseiten verwendet werden.
Codebeispiel:
<iframe src=“inhalteingefuegt.pdf“ width=“80%“ height=“400″ title=“PDF-Datei über Kunst“ name=“PDF-Datei über Kunst“ > <p>Wir müssen leider einen IFrame verwenden</p> </iframe>
Generell sollte vermieden werden, frames zu benutzen.
Responsive Web Design und Barrierefreiheit
Tab-Order
Die Tab Order muss funkionieren und logisch sein, der Fokus muss sichtbar sein (Vermeiden, in die Standard-Auszeichnung einzugreifen bzw. den Fokus sogar besser machen mit einem guten Fokus-Konzept -> hier muss das Design vorarbeiten)
Tabindex: Falls nötig, kann mit tabindex gearbeitet werden. Ein tabindex von -1 sorgt dafür, dass das Element nicht in der natürlich tab order drin ist, aber per javascript mit der focus() method fokussiert werden kann. Dies ist z. B. wichtig bei Offscreen Inhalten wie einer Flyout Navigation. Solange sie eingeklappt ist, darf sie nicht den Fokus erhalten, sonderm nur wenn sie ausgeklappt ist. Auch wichtig z. B. bei Modals (Popups).
Ein tabindex=“0″ fügt das Element der natürlichen tab order hinzu und kann fokussiert werden (wichtig bei selbst gebauten „widgets“, z. B. ein Checkbox Replacement, bzw. ein Element das sich wie eine Checkbox verhält, aber nicht das Standard HTML Element für checkboxen verwendet. S. auch ARIA). Ein tabindex, der größer als 0 ist, bringt das Element in der tab order nach vorne, egal wo es im html Code (= in der DOM order) ist. Generell sollte ein tabindex größer als 0 nicht verwendet werden. Der beste Weg, etwas weiter vorne in der Tab Order zu haben, ist es, das Element weiter oben in der DOM order zu haben, also weiter oben im Code.
Fokus: Entscheiden, was Fokus bekommen soll. Generell sollten nur Elemente, mit denen der User etwas tun kann, einen Fokus erhalten (z. B. Buttons, inputs, tabs…). Wenn man etwas fokussiert, dass eigentlich nicht fokussiert gehört, verwirrt das eher als das es hilft.
Ausnahme z. B.: Single Page App („Managing Focus„): Content, der nicht auf einer neuen Seite geladen wird, da es nur eine Seite gibt. Wenn man hier auf einen Navigationspunkt klickt, ist dort der Fokus. Möchte man jetzt in den Content und dort z. B. einen Content-Link per Tastatur anklicken, muss man erst durch die restlichen Punkte in der Navi durchtabben. Die Lösung ist hier, den Headlines (dort wo im Content hin gesprungen wird) einen tabindex -1 zu geben, und dann per js und der focus() Methode anzuwählen.
Managing Focus
Wichtig z. B- bei selbst gebauten Elementen, z. B. wenn man eine Dropdown Liste selbst baut. Die Liste muss sich bei der Bedienung mit einem Keyboard gleich verhalten wie wenn es z. B. eine Select Liste wäre (mit Tab rein und dann mit den Pfeiltasten auswählen, Return zum Abschicken). Um herauszufinden, welche Keyboard Optionen man braucht, kann man im Aria Design Patterns guide (Kapitel 11) nachschauen. Funktioniert mit tabindex -1 und 0, und der focus() method.
Offscreen Inhalt sollte vom Fokus ausgenommen sein: bei Start mit display:none oder visibility:hidden
Context wechseln
Sollte nicht unerwartet sein, z. B. Wechseln der Seite durch ein Dropdown Menü: besser mit Button zum Absenden, aber es sieht nicht gut aus. Besser: Menü Button den man aktiv aufmachen muss
Reihenfolge von Content / Fokus
- Wenn man die Seite kleiner schiebt und z. B. die Sidebar bei einem breakpoint woanders hinspringt, muss die Reihenfolge beim durchtabben gleich bleiben, bzw. Sinn machen
- Visuelle Ordnung muss der DOM Ordnung ensprechen
Mobile Geräte
- Nicht auf eine Orientation beschränken
- Pointer Gestures: nicht nur diese benutzen, man braucht auch Buttons
- Pointer Cancellations: Man muss Aktionen rückgängig machen können (action bei click und tap, nicht touch-down)
- Motion Actuation: schütteln, rotieren: kann nicht die einzelne Möglichkeit sein,
Button anbieten
Zusätzliche Responsive Richtlinien
- Content barrierefrei verstecken, z. B. mit dem hidden attribute (display:none und visibility: hidden -> versteckt für alle)
- Relative Einheiten benutzen (em, rem, %)
- Text-Spacing (dies sollte mindestens vom user einstellbar sein, ohne dass die Seite nicht mehr benutzbar ist): Line-height ist 1,5x der Font-size, 2x font-size spacing nach Absätzen, Letter-spacing sollte mindestens .12x der font-size sein, Word-space sollte mindestens .16x der font-size sein
- Es sollte keine Scrollbars geben beim Vergrößern
WAI-ARIA: Kurzform ARIA
Bedeutung:
WAI – Web Accessibility Initiative
ARIA – Accessible Rich Internet Applications (Specs): Zum Überbrücken der Bereiche, in denen normales Htmls bei Accessibility-Themen nicht mehr ausreicht
Elemente werden durch die Angabe von ARIA Attributen anders in den „Accessibility-Tree“ geschrieben (lesbar von Screenreadern)
Beispiel: Nachgebaute Checkboxen – Wenn man aus z B. Design-Gründen nicht die nativen Checkboxen verwenden will, muss man sicherstellen, dass die selbst gebauten Checkboxen, außer mit der Tastatur bedienbar zu sein und den Fokus zu bekommen, auch noch die role=“checkbox“ und das Attribut aria-checked=“true“ oder aria-checked=“false“ haben, sonst liest der Screenreader nicht vor, dass es sich um eine Checkbox handelt, und auch nicht ob sie gecheckt oder nicht gecheckt ist.
Mit ARIA spricht man mit der „Assistive Technology“, also z. B. Screenreadern. Man hilft, die Semantik zu erkennen.
Liste der ARIA Roles mit Erklärungen, wann sie zu benutzen sind.
aria-label: String, der direkt als accessible label benutzt werden kann. Er überschreibt einen evtl. vorhandenen Link-Text, so dass der Screenreader ihn vorliest anstatt des Textes.
aria-labelledby: Erlaubt es, eine Element ID zu spezifizieren, die zu einem anderen Element im DOM als dessen Label referenziert (wie bei id und label for. aria-labelledby ist die id und id ist dann bei label das for). aria-labelled-by überschreibt alle anderen Namen (z. B. aria-label). Es kann allen Elementen zugewiesen werden, und auch mehrere Werte haben.
Code Beispiele & Best Practice
In diesem Blog-Artikel sammeln wir Links zu Seiten mit vielen Beispielen und Informationen zu einer barrierefreien Herangehensweise beim Coding.
Weitere Links
HTML & A11y Cheatsheet
Diese Tabelle listet die am meisten vorkommenden und nützlichsten HTML Elemente, die einen Einfluss auf die Barrierefreiheit haben.
HTML Semantics and Accessibility Cheat Sheet
WAI (Web Accessibility Initiative):
Ein guter Startpunkt, sich mit barrierrefreier Entwicklung vertraut zu machen sind die Seiten der WAI.
Resources for Developers
Inbesondere diese Seite:
Tips for Getting Started Developing for Web Accessibility
Ebenfalls gibt es bei WAI Tutorials für Seitenstruktur, Menüs, Bilder, Tabellen, Formular und Slider.