console.log()

Barrierefreiheit mit WAI-ARIA – Teil 2/3

| Keine Kommentare

WAI-ARIA ist ein W3C Standard für die Entwicklung barrierefreier Webanwendungen. Mit WAI-ARIA kann die Struktur, Bedeutung und Funktionalität von Webinhalten von Browsern besser erfasst werden, um sie zum Beispiel über Screen Reader wiederzugeben.

WAI-ARIA definiert hierfür eine Taxonomie mit zahlreichen roles, states, properties und values im OWL -Format. HTML-Dokumente können mit diesen Attributen semantisch angereichert werden, die dann vom Browser und Screen Reader interpretiert und ausgegeben werden können.

WAI-ARIA wird inzwischen von fast allen Browsern unterstützt:

  • Voll unterstützt: Internet Explorer 8+ und IE Mobile 10+, Firefox 3+, Firefox for Android: 15+
  • Teilweise unterstützt: Chrome 4+, Safari 4+, Opera 9.5+, iOS Safari 3.2+, Opera Mini 5+, Opera Mobile 10+, Chrome for Android 18+
  • Nicht unterstützt: Android und Blackberry Browser

 

ARIA Landmarks

Mit ARIA Landmark Roles (z.B. role=“main“) können wichtige Bereiche einer Website semantisch ausgezeichnet werden. Die Rollen application, banner, complementary, contentinfo, form, main, navigation und search markieren Bereiche, die der Benutzer eines Screen Readers zur Navigation innerhalb der Website nutzen kann und sollen die Funktion bisher eingesetzter „Jump-Links“ übernehmen.
Bei einer Umfrage von Web AIM gaben zwei Drittel der Benutzer von Screen Readern an, dass sie Landmarks gelegentlich bis häufig bzw. immer wenn diese vorhanden sind zur Navigation verwenden:

Verwendung von ARIA Landmarks

WAI ARIA-Landmarks werden von allen gängigen Screen Readern unterstützt (JAWS, NVDA, VoiceOver, ChromeVox und Window-Eyes). JAWS gibt zum Beispiel die Landmark-Role z.B. „navigation landmark“ aus. Apple VoiceOver gibt zusätzlich aus, wenn ein Bereich, der durch ein Landmark gekennzeichnet ist ausgewählt bzw. wieder verlassen wird:

  • Englisch: „landmark start/end“
  • Deutsch: „Anfang/Ende des Orientierungspunkts“

HTML5-Elemente wie <article> und <section> implizieren entsprechend die Rollen „article“ und „section“. Die Elemente <nav> und <aside> haben bereits die Rollen „navigation“ bzw. „note“. Diese Elemente haben eine implizite Semantik und müssen nicht zusätzlich mit ARIA-Rollen ausgezeichnet werden.
WAI-ARIA Roles dürfen aber auch nicht wahllos oder widersprüchlich auf beliebige Elemente gesetzt werden, sondern sollten zur Semantik des entsprechenden Elements passen. Im ARIA-Kapitel des W3C HTML5 Standards findet sich eine Übersichtstabelle über alle Elemente, deren ’strong native semantics‘ und ‚default implied roles‘.

Beispiel: Navigationsmenü

Eine Navigationsleiste mit hierarchischen Ausklappmenüs für eine Webanwendung oder Website kann mit den Rollen „menubar“ und „menuitem“ semantisch angereichert werden:

<nav id="navigation“>
	<ul role="menubar“>
		<li role="menuitem" aria-haspopup="false">Home</li>
		<li role ="menuitem" aria-haspopup="true">Menu 1
			<ul role="menu" aria-expanded="true">
				<li role="menuitem">Submenu 1.1</li>   
				<li role="menuitem">Submenu 1.2</li>
				<li role="menuitem" aria-disabled="true">Submenu 1.3</li>
			</ul>
		</li>
	</ul>
</nav>

http://oaa-accessibility.org/examplep/menubar1
sowie http://www.w3.org/TR/wai-aria/roles#menubar

Die Eigenschaft aria-haspopup gibt an, ob ein Menüpunkt ein weiteres Untermenü enthält. Das Zustandsattribut aria-expanded gibt an, ob das Menü ausgeklappt ist oder nicht. Bei einer Änderung per Javascript sollte das Attribut entsprechend gestezt werden, damit die Zustandsänderung vom Screen Reader registriert und ausgegeben werden kann. Mit der Eigenschaft aria-disabled kann ein Element als deaktiviert ausgezeichnet werden.
Um die Tastaturbedienung zu ermöglichen, sollte der Focus per tabindex-Attribut oder mit Javascript gesetzt werden. Menüleisten sollten sich dabei, wie von Desktop-Anwendungen bekannt, mit den Pfeil-Tasten bedienen lassen. Eine ausführliche Erläuterung zur Implementierung von ARIA Menus, gibt es im W3C Wiki.

Beispiel: Live-Regions

Das Nachladen von Inhalten per Ajax ist aus modernen Websites nicht mehr wegzudenken. Benutzer von Screen Readern bekommen jedoch von asynchronen Änderungen am DOM nichts mit: Bereiche außerhalb des Fokus, deren Inhalt ohne Benutzerinteraktion aktualisiert wird  werden nicht ausgegeben. Dynamisch aktualisierte Bereiche sollten daher mit dem Attribut aria-live als sog. „Live-Regions“ ausgezeichnet werden, damit Änderungen am Inhalt von Screen Readern berücksichtigt werden. Hier ein Beispiel für einen einfachen Live-Ticker:

<ul id="ticker" aria-live="polite" aria-relevant="additions" aria-atomic="false">
       <li>69. Mike Hanke trifft zum 2:0!</li>
       <li>51. Coquelin steckt auf Günter durch, der den Ball kurz vor 
       der Grundlinie erreicht und in die Mitte flank, wo … egal, 1:0!</li>
       …
</ul>

Das Attribut aria-live bestimmt hierbei ob und mit welcher Priorität der Screen Reader den neuen Inhalt ankündigen soll:

  • „polite“: Die Änderungen werden erst vorgelesen, wenn keine Nutzerinteraktion mehr stattfindet. Diese Option sollte für die meisten Anwendungsfälle von Live-Regions gewählt werden.
  • „assertive“: Alle Änderungen werden mit hoher Priorität ausgegeben – die aktuelle Sprachausgabe wird jedoch nicht unterbrochen. Diese Option sollte zum Beispiel für Fehlermeldungen oder Validierungsmeldungen bei Formularen gewählt werden.
  • „off“: Default für alle Elemente – dynamische Änderungen werden nicht ausgegeben. Die weitere Ausgabe einer Live-Region kann auch mit aria-live=“off“ explizit unterbunden werden.

Mit dem Attribut aria-relevant wird festgelegt, welche Änderungen der Live-Region ausgegeben werden sollen:

  • „additions“: Der Screen Reader soll nur die neu hinzugefügten Elemente ausgeben.
  • „removals“: Der Screen Reader soll das Entfernen von Elementen ausgeben.
  • „text“: Änderungen am Text der Child-Elemente sollen ausgegeben werden.
  • „all“: Alle Änderungen sollen ausgegeben werden.

Die Werte für aria-relevant können auch kombiniert werden: z.B. „additions text“ oder „additions removals“. Um den Benutzer nicht durch unwichtige Information zu überfordern, sollten „removals“ und „all“ nur eingesetzt werden, wenn es unbedingt erforderlich ist.

Das Attribut aria-atomic bestimmt, ob bei einer Änderung die Live-Region wiederholt als Ganzes ausgegeben werden soll, oder nur die tatsächlich geänderten Bestandteile.

ARIA Best-Practices

Eine gute Übersicht mit zahlreichen Beispielen und Best-Practices gibt es im Mozilla Developer Network.

In den WAI-ARIA Authoring Practices werden Best-Practices für häufig verwendete Widgets (Modal Dialog, Accordion, Tree View etc.) als Design Patterns beschrieben. Die Design Patterns umfassen jeweils eine allgemeine Beschreibung, empfohlene Tastaturinteraktion, mögliche ARIA Roles, States und Properties sowie Anwendungsbeispiele.

Im W3C Editors-Draft ‚Using WAI-ARIA in HTML‘ empfiehlt Steve Faulkner, welche ARIA-Attribute für welche HTML-Elemente verwendet werden sollten und welche nicht. Die Tabelle ARIA Roles, States and Properties fasst hierbei alle WAI ARIA-Attribute kurz zusammen und eignet sich als Übersicht und Nachschlagewerk.

Verschiedene Ansätze für eine barrierefreie Formularvalidierung mit HTML5 und ARIA werden von Marco Zehe (From WAI-ARIA to HTML5 and back .. or maybe not?) und Paul J. Adam (Accessible Client-side Form Validation with HTML5 & WAI-ARIA) diskutiert. Eine Best-Practice für dynamische Formular Labels mit WAI-ARIA erläutert Ted Drake im Yahoo Developer Blog.

tl;dr

Mit WAI-ARIA kann die Struktur, Bedeutung und Funktionalität von Webinhalten vom Browser besser erfasst und von Screen Readern ausgegeben werden. ARIA wird von fast allen gängigen Browsern und Screen Readern unterstützt. Durch Hinzufügen von Landmarks, Rollen und Zustandsattributen zu HTML-Elementen können Webanwendungen mit geringem Zusatzaufwand  für Benutzer von Screen Readern besser zugänglich gemacht werden.

Blogs zu Barrierefreiheit:

Einfach für Alle – Access Blog
Yahoo Accessibility Blog
Marco Zehe
Heiko Kunert – Blind PR
Accessible Culture
The Paciello Group
Googleblog accessibility
Google.com/accessibility
STC AccessAbility Special Interest Group

Barrierefreiheit auf Twitter:

@w3c_wai
@googleaccess
@yahooaccess
@webaim
@SteveFaulkner – The Paciello Group
@MarcoZehe – Mozilla Accessibility Engineer
@codepo8 – Christian Heilmann, Mozilla Developer Evangelist
@HeikoKunert – Blogger für Blind PR, Accessibility Evangelist und Geschäftsführer @BSVH,
@EinAugenschmaus – Julia Probst, Gehörlose Lippenleserin & Bloggerin
@Accessibility_M – Markus Lemcke
@stcaccess – STC AccessAbility SIG

 

Autor: Clemens Fiedler

Clemens ist Webdeveloper im CMS Team "The Contenters" am Standort Freiburg und interessiert sich für Frontend Themen. Sein Schwerpunkt liegt auf JavaScript, HTML, CSS und Responsive Design. Einfach gutes Frontend ist für ihn das was bei den Menschen ankommt, unabhängig von Zugang, Gerät oder Fähigkeiten.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.