Erstellung Barrierefreiher Webseiten Cheat Sheet

Buch: "­Bar­rie­ref­reiheit verstehen und umsetz­en", Jan Eric Hellbusch & Kerstin Probiesch, dpunkt.ve­rlag, 2011, ISBN: 978-3-­898­64-­864-6
BITV Anford­erungen
BITV Prüfsc­hritte
MDN - Using ARIA
MDN - ARIA Barrie­ref­reiheit
http:/­/ww­w.a­cce­ss-­for­-al­l.c­h/c­h/b­arr­ier­efr­eih­eit­/ba­rri­ere­fre­ies­-we­bde­sig­n/c­hec­kli­st-­2.html
http:/­/ww­w.b­arr­ier­efr­eie­-in­for­mat­ion­sku­ltur.de
Zusätz­liche Quelle für Lösung­sideen http:/­/wh­ats­ock.co­m/tsg/

NVDA Ein freier Screen­reader für Windows Systeme.
JAWS Ein kommer­zieller Screen­reader für Windows Systeme.
TalkBack Ein Screen­reader von google für Android Geräte (in der Regel vorins­tal­liert).
ChromeVox Ein Screen­reader von google für den Chrome Browser (in der Regel vorins­tal­liert).

Um zur Entwic­klu­ngszeit das Verhalten von Screen­readern halbwegs sicher erraten zu können, reicht eine Prüfung des DOMs nicht aus. Für die Ausgaben der Screen­reader ist der Access­ibi­lit­y-Tree aussch­lag­gebend. Mit folgenden Werkzeugen lässt sich der Access­ibi­lit­y-Tree analys­ieren und prüfen:
Active Access­ibility Object Inspector (Windows)
Aviewer (Firefox, IE und Chrome unter Windows)
JAWS script namens "­BX", das MSAA und UI Automation unters­ucht.
Access­ibility Inspector (OS X)
AccProbe (Linux)
Chrome: chrome­://­acc­ess­ibility + Access­ibility Developer Tools (Chrome Erweit­erung
Chrome: Developer Tools (F12) / Elements / Untertab Access­ibi­llity
Chrome Lighthouse testet automa­tisiert WCAG Suites{{/popup}
Axe API (Plugins für Lighth­ouse)
Chrome Erweit­erung Axe
WAVE Browser Plugin
WCAG Access­ibility Audit Developer UI (Chrome Extension)
* Siteim­prove Access­ibility Checker (Chrome Extension)

Allgemeine Hinweise
Die Textst­ruktur, die Gliederung und auch Einrüc­kungen müssen auch für nicht sehende Menschen klar erkennbar sein. Sie sollen die Orient­ierung, Navigation und den Lesefluß unters­tützen.
Die Bezeic­hnungen für nicht sehende Nutzer sollten identisch zu denen für Sehende sein und nur um weitere Details angere­ichert werden. Hinter­grund ist die Verstä­ndigung zwischen Sehenden und Nichts­ehenden beim Betrachten genau der selben Seite am gleichen PC. Wenn der Sehende eine Schalt­fläche "Als Gelesen markie­ren­" sieht und der Screen­reader über den Tooltipp "­Bea­rbeiten der Nachricht beende­n" vorliest fällt es schwer auf die selbe Schalt­fläche zu schließen.

Vorgeh­ens­weisen
Untert­eilung der Seite in Regionen mit Hilfe von landmark roles. Diese lassen sich per Tastatur ansteuern.
Für Regionen die nicht über landmark roles abgedeckt werden können, lassen sich document structure roles verwenden. Diese sind nicht per Tastatur ansteu­erbar sondern fügen der Seite nur nützliche Zusatz­inf­orm­ationen hinzu.

Die Möglic­hkeit der Sprach­eingabe ist nach der Nutzung des Vorlesens von Texten (text to speech) das Wichtigste Feature für Sehbeh­inderte Nutzer. Damit wird vieles verein­facht.

Technische Umsetzung
<input x-webk­it-­speech />

Event nach Sprach­eingabe kann ausgew­ertet werden mit:
var suchei­ngabe = docume­nt.g­et­Ele­men­tsB­yTa­gNa­me(­"­inp­ut")[0];
suchei­nga­be.o­nw­ebk­its­pee­chc­hange = functi­on(e) {
locati­on.href = "­htt­p:/­/ww­w.g­oog­le.d­e/­sea­rch­?q=­"+ suchei­nga­be.v­alue;
};

Bei einer Navigation zurück soll der Fokus wieder genau dort stehen von wo die Navigation erfolgte z.B. auf Seite 3 in Zeile 7 auf dem 5. Link in einer mehrse­itigen Liste (falls genau dieser Link vorher die Navigation auslöste).
Bei Intera­kti­ons­ele­menten welche je nach Status ihre Präsen­tation ändern z.B. ein Icon für erledigt und nicht erledigt muss nach Auslösen der Intera­ktion der Fokus wieder auf diesem Icon (Inter­akt­ion­sel­ement) stehen.

Nicht länger als 60 Zeichen sonst wird im strukt­uri­erten Modus von JAWS nur ein Teil des Textes auf dem Braill­eviewer angezeigt.
Textbeginn identisch mit der Oberfläche halten, damit Sehender und Nichts­ehender sich über die Inhalte unterh­alten können.
* Textan­fänge in Listen möglichst mit unters­chi­edl­ichen Buchstaben oder Wortan­fängen beginnen, damit der Nichts­ehende über Tasten­kürzel schnell die gewünschte Stelle erreichen kann (funkt­ioniert nur bei Texten die nach einer Weile als bekannt angesehen werden können, z.B. Liste von Berufen etc.).

Fragen sollen stets in einfachen kurzen Sätzen und positiv formuliert werden. Negierte Fragen sind schwerer verstä­ndlich und von Lernsc­hwachen Menschen teilweise nicht korrekt erfassbar.
Fehler­mel­dungen sollten prinzi­piell aus 2 Sätzen bestehen. Im ersten Satz sollte die Fehler­ursache kurz beschr­ieben werden. Der 2. Satz sollte einen Lösung­svo­rschlag beinhalten z.B. "Es wurde ein ungültiges Startdatum eingeg­eben. Bitte tragen Sie ein korrektes Datum als Startdatum ein."
* Fehler­mel­dungen wie "Für diese Aktion besitzen Sie keine Berech­tig­ung­" sollen vermieden werden - Ätschi bäh Effekt! Intera­ktionen die der Nutzer nicht durchf­ühren darf sollen nicht angezeigt werden.

Zunächst wird die Struktur einer Webseite beschr­ieben z.B. durch HTML oder XML.
Durch Frameworks (JSP, AngularJS, doxia, ...) wird die Struktur mit Dateni­nhalten und Verhal­ten­sin­for­mat­ionen angere­ichert.
Über Styles­heets (css, xsl) wird die Struktur mit Inform­ationen zum Layout und Design angere­ichert.
Über aria-role Attributen werden der Struktur semant­ische Inform­ationen zugeor­dnet.

Das Gesamt­erg­ebnis im Browser ist eine Darste­llung von Daten gemäß einem defini­erten Layout und entspr­echend den Design­vor­gaben mit einem Verhalten welches sowohl durch die verwen­deten Frameworks als auch über die per Rollen definierte Semantik bestimmt wird.