Show Menu

Erstellung Barrierefreiher Webseiten Cheat Sheet by

Hinweise zur Umsetzung der Barrierefreiheit in Webanwendungen (auch für Behörden nutzbar)
web     accessibility     best     barrierefreiheit     anwendung     hinweise     praxis

Nützliche Quellen

* 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 Anforderungen
* BITV Prüfschritte
* MDN - Using ARIA
* MDN - ARIA Barrierefreiheit
* http://www.access-for-all.ch/ch/barrierefreiheit/barrierefreies-webdesign/checklist-2.html
* http://www.barrierefreie-informationskultur.de
* Zusätz­liche Quelle für Lösung­sideen http:/­/wh­ats­ock.co­m/tsg/

Screen­reader

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

Werkzeuge zur Prüfung des Access­ibi­lit­y-Trees

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://accessibility + Accessibility Developer Tools (Chrome Erweiterung
* 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)
* Siteimprove Access­ibility Checker (Chrome Extension)

Struktur & Gliederung & Bezeic­hnung

Allg­emeine 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.

Vorg­ehe­nsw­eisen
* 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.

Seiten­reg­ionen (aria landmark roles)

ARIA Role
HTML Element
Benutzung
role="application"
-
Sehr selten als landmark role nutzbar. Nur für Bereiche in denen eine Webanw­endung mit eigenem Focusm­ana­gement eingeb­ettet ist. Wird häufig falsch verwendet, z.B. wenn lieber Widget Rollen eingesetzt werden sollten.
role="banner"
<header>
Region mit Infos über einen Seiten­abs­chnitt - im Sinne einer Übersc­hrift (je Seite mehrmals nutzbar).
role="contentinfo"
<fo­ote­r>
Region mit Infos über einen Seiten­abs­chnitt - im Sinne von Inhalt und Metadaten (je Seite mehrmals nutzbar).
role="complementary"
<as­ide>
Region für Abschnitte welche in Form von Inhalt­sba­ust­einen zusätz­liche, eigens­tändige Inform­ationen bereit­ste­llen.
role="form"
-
Region mit Formul­are­lem­enten
role="main"
<ma­in>
Hauptr­egion (je Seite nur eine möglich)
role="navigation"
<na­v>
Region mit Naviga­tio­nse­lem­enten
role="search"
-
Region mit Suchel­ementen
Allg­emeine Hinweise
* ARIA definiert 8 landmark roles von denen 5 sogar ein eigenes HTML Element besitzen. Die Verwendung des spezif­ischen HTML Elements mit der Rolle ist generell besser als ein DIV Element zusammen mit der Rolle.
* Regionen sollen unters­che­idbar sein, z.B. per aria-l­abe­lledby oder aria-label
Quel­le: Strategie für Landmark Roles

Dokume­nts­truktur (aria document structure roles)

ARIA Role
HTML Element
Verwendung
article
<ar­tic­le>
Nutzbar für eigens­tändige Teilbe­reiche einer Seite, wie z.B. Artikel einer Zeitung oder Post in einem Weblog. Article sind scha­cht­elb­ar. Screen­reader können hier in einen Betrac­htu­ngs­modus wechseln. Daher evtl. nicht sinnvoll für Bereiche mit Intera­kti­ons­ele­menten.
column­header
definition
directory
document
group
heading
img
list
listitem
math
note
presentation
-
Soll benutzt werden um Semantik zu entfernen, z.B. bei einer Layout­tabelle soll dadurch der Eindruck verhindert werden es handle sich um eine Datent­abelle mit Kopf und Body.
region
<se­cti­on>
row
rowgroup
rowheader
separator
toolbar

Sprach­eingabe für Input Felder

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;
};

Tabellen (Daten­tab­ellen)

* Tabellen benötigen eine Zusammenfassung über das was in der Tabelle dargestellt wird. Dazu wird das Element <caption> verwendet. Das frühere Attribut summary ist veraltet und darf nicht mehr verwendet werden.
* Tabellenspalten müssen eine Überschrift besitzen, damit klar ist welcher Inhalt in der Spalte zu erwarten ist ohne vorher die ganze Tabelle sichten zu müssen. Realisiert wird dies durch Texte in den th Elementen. Falls sich die visuelle Repräsentation von der JAWS Repräsentation unterscheiden soll z.B. Mo und Montag im Datepicker kann ein span mit sr-only und ein span mit aria-hidden="true" im th genutzt werden.

Navigation und Intera­ktion

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

Tooltipps, Altern­ati­vtexte

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

Dialoge, Fragen und Meldungen

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

Darste­llung & Verhalten von Webseiten

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

Download the Erstellung Barrierefreiher Webseiten Cheat Sheet

5 Pages
//media.cheatography.com/storage/thumb/funthomas424242_erstellung-barrierefreiher-webseiten.750.jpg

PDF (recommended)

Alternative Downloads

Share This Cheat Sheet!

 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          More Cheat Sheets by FunThomas424242

          Webcomponents - native Javscript Cheat Sheet
          Mit Javascript unter Node.js entwickeln Cheat Sheet