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

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 + Access­ibility Developer Tools als Erweit­erung.

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

Tabellen (Daten­tab­ellen)

* Tabellen benötigen eine Zusamm­enf­assung über das was in der Tabelle darges­tellt wird.
* Tabell­ens­palten müssen eine Übersc­hrift besitzen, damit klar ist welcher Inhalt in der Spalte zu erwarten ist ohne vorher die ganze Tabelle sichten zu müssen.

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

4 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

          eclipse Keyboard Shortcuts