Nicht wenige Aria Beispiele beschränken sich auf das wesentliche und statten unsemantisches HTML, insbesondere div und span-Elemente, mit den jeweiligen Aria-Attributen aus. In der Praxis wird regelmäßig semantisches HTML als Grundlage genommen. Gleichzeitig passieren hierbei jedoch zwei vermeidbare Fehler.
1. Die Verschachtelung der Aria-Attribute folgt der semantischen HTML-Struktur und nicht der Aria-Spezifikation
Ein typisches Beispiel ist eine Menüleiste, welche mit verschachtelten Listen aufgebaut wurde:
<ul role="menubar"> <li role="menuitem" aria-haspopup="true"> <a href="#" tabindex="0">Menubaritem</a> <ul role="menu" aria-hidden="true"> <!-- weitere menuitems --> </ul> </li> </ul>
Schaut man sich diese Struktur an und vergleicht sie mit der Aria-Spezifikation sollte auffallen, daß
- der Menüeintrag das interaktive Objekt ist und nicht der Link
- der Link innerhalb eines Menüs eigentlich ein artfremdes Objekt ist
- ein Untermnü/Poupup-Menü kein Kind des dazugehörigen Menüitems
Ein entsprechend korrigiertes HTML könnte demnach wie folgt aussehen:
<ul role="menubar"> <li role="presentation"> <a role="menuitem" aria-haspopup="true" href="#" tabindex="0">Menubaritem</a> <ul role="menu" aria-hidden="true"> <!-- weitere menuitems --> </ul> </li> </ul>
Doch auch diese HTML-Struktur ist letztendlich fehlerhaft und wird – insbesondere von Jaws, dem marktführendne Screenreader – recht unangenehm gelesen.
2. Das Reste fressen
Überall im Netz findet man leider Scripte, die die HTML-Struktur so verändern, daß der Screenreader semantische Überreste der alten HTML-Struktur vorgeworfen bekommt. Nachfolgend ein paar Beispiele mit dem typischen a[href]-Problem:
<!-- Tabs --> <a href="#" role="tab" tabindex="-1" aria-selected="false" aria-controls="tab-2">Ein Tab</a> <!-- Menü --> <a href="#" role="menuitem" tabindex="-1" aria-haspopup="true">Ein Menüitem</a> <!-- Menübutton (hier gibt es eine kleine Ausnahme) --> <a href="#" role="button" aria-haspopup="true">Menübutton</a>
Hierbei wird gerne übersehen, daß das href-Attribut eines Anchor-Elements, gleichzeitig immer als Accessibility-Wert des Links an die Zugänglichkeitsschnittstelle übergeben wird. Hat der Link keinen Namen, lesen einige Screenreader als Hilfe eben diesen Wert vor. Nun wurde jedoch in allen Beispielen die Rolle des Anchor-Elements auf eine andere Rolle gemappt und viele Screenreader lesen dann ebenfalls den Wert vor, auch wenn der Name vorhanden ist. Hierbei ist erschwerend zu beachten, daß nicht der Inhalt des HTML-Attributs vorgelesen wird, sondern die href-DOM-Eigenschaft, welche die – vom Browser berechnete – absolute URL darstellt.
Auf dieser Seite würde der Screenreader Jaws beim Fokusieren des oben dargestellten Menüeintrags folgendes vorlesen:
Menüeintrag Ein Menüitem H T T P Doppelpunkt Schrägstrich Schrägstrich w w w Punkt protofunc Punkt com Schrägstrich 2010 Schrägstrich 01 Schrägstrich 03 Schrägstrich wai Bindestrich aria Bindestrich epic Bindestrich fail Bindestrich reste Bindestrich fressen Schrägstrich Raute Untermenü
Im Ergebnis läßt sich folgendes sagen, wenn ein Script solch ein HTML produziert, sollte man dieses Script auf keinen Fall einsetzen. Es ist offensichtlich, daß dieser Code nicht einmal mit dem marktführenden Screenreader getestet wurde und es könnten daher noch weitere Bugs vorhanden.
Ein bereinigtes HTML könnte wie folgt aussehen:
<!-- Tabs --> <a role="tab" tabindex="-1" aria-selected="false" aria-controls="tab-2">Ein Tab</a> <!-- Menü --> <a role="menuitem" tabindex="-1" aria-haspopup="true">Ein Menüitem</a> <!-- Menübutton (hier gibt es eine kleine Ausnahme) --> <a role="button" aria-haspopup="true" tabindex="0">Menübutton</a>
Diese Struktur – insbesondere beim Menübutton – führt zu einigen kleineren Problemen, die man beim Coden von CSS/JS berücksichtigen muß. Die Lösung(en) hierzu würde(n) allerdings den Rahmen sprengen.