Erstellung Barrierefreiher Webseiten Cheat Sheet by FunThomas424242

* 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.