Wenn ein HTML-Element die Rolle „presentation“ erhält, wird die Semantik des Elements nicht an den Accessibility-Tree des Betriebssystems übertragen. Gleichwohl sind alle Kindknoten des Elements davon nicht betroffen, d.h. der enthaltene Text und weitere Elemente bleiben weiterhin für Screenreader zugänglich. Da die Rolle „presentation“ offenbar häufig fälschlicherweise so interpretiert wird, dass sowohl das Element als auch seine Inhalte nicht an den Accessibility-Tree übertragen werden, wird in Accessible Rich Internet Applications (ARIA) 1.1 der synonyme Wert „none“ eingeführt.
Ob role=“none“ eindeutiger ist als role=“presentation“ muss sich noch herausstellen. Nach ARIA 1.1 sind beide Rollen identisch. In der Praxis dürfte es allerdings noch ein wenig dauern, bis role=“none“ zuverlässig eingesetzt werden kann, wie einige Testergebnisse vor wenigen Monaten gezeigt haben.
Einsatzmöglichkeiten für role=“none“
Es gibt einige wenige sinnvolle Einsatzmöglichkeiten für role=“none“:
- Dekorative Grafiken können (statt mit einem leeren Alternativtext) für Screenreader vollständig unterdrückt werden:
<img role="none" src="bild.svg" alt="wird ignoriert" title="wird ignoriert">
- die Semantik in Tabellen kann unterdrückt werden, wenn Tabellen zu Layoutzwecken eingesetzt werden. Im Beitrag Layout-Tabellen sind wie Briefe in Excel wird der Effekt von role=“none“ auf ein <table> erklärt).
- Links, die mit tabindex=“-1“ aus der Fokus-Reihenfolge entfernt werden, können auch für Screenreader unzugänglich gemacht werden (wobei aria-hidden=“true“ vorzuziehen ist).
- Wenn in Widgets ein HTML-Konstrukt als Ausgangslage genutzt wird, können mit role=“none“ die „übriggebliebenen“ und überflüssigen semantischen Elemente aus dem Accessibility-Tree entfernt werden.
Beispiel für überflüssige Elemente
Als Beispiel für den letzten Punkt kann eine Registernavigation dienen. Wenn eine Reiterleiste aus einer Linkliste besteht:
<ul>
<li><a href="#register">Registrieren</a></li>
<li><a href="#login">Anmelden</a></li>
<li><a href="#password">Passwort vergessen</a></li>
</ul>
könnte die dynamisierte und barrierefreie Registernavigation wie folgt aussehen:
<ul role="tablist">
<li role="none"><a href="#register" role="tab" aria-selected="false" tabindex="-1">Registrieren</a></li>
<li role="none"><a href="#login" role="tab" aria-selected="true">Anmelden</a></li>
<li role="none"><a href="#password" role="tab" aria-selected="false" tabindex="-1">Passwort vergessen</a></li>
</ul>
Die Listeneinträge erhalten ein role=“none“,
- weil das übergeordnete Element semantisch keine Liste mehr ist, sondern eine Reiterleiste (Tablist), und
- weil die Reiter (Tab) unmittelbare Kinder der Reiterleiste sein müssen.
Nur wenn die Reiter unmittelbare Kinder der Reiterleiste sind kann ein Screenreader beispielsweise korrekt ermitteln, aus wievielen Reitern die Reiterleiste besteht.
Mit role=“none“ wird verhindert, dass die Semantik der Listen-Elemente im Accessibility-Tree abgelegt wird. Die Inhalte des Listen-Elements (die Tabs) sind davon nicht betroffen, weil sich role=“none“ nicht auf die Inhalte des Elements vererbt.
Übertragung auf erforderliche Kindelemente
Bei Listen und Tabellen sollte beachtet werden, dass role=“none“ auf erforderliche Kindelemente übertragen wird. Beispielsweise mit
<ul role="none">
<li>Ein Text <abbr="zum Beispiel">z.B.</abbr> über ARIA</li>
</ul>
werden im Accessibility-Tree weder Liste noch Listeneinträge abgelegt:
Ein Text <abbr="zum Beispiel">z.B.</abbr> über ARIA
Die Rolle bezieht bei einem <ul> Element auch die zugehörigen Listeneinträge ein. Genauso werden bei einer Tabelle die zugehörigen <caption>, <tr>, <th> und <td> Elemente einbezogen (siehe verlinkter Artikel oben). Wenn innerhalb einer Liste oder Tabelle mit role=“none“ weitere Listen oder Tabellen verschachtelt sind, sind diese verschachtelten Elemente nicht von der Rolle betroffen, denn sie sind keine erforderlichen Elemente mehr. Um das gleiche Ergebnis in einer verschachtelten Liste zu erzielen, müssen beide <ul> Elemente die Rolle „none“ erhalten:
<ul role="none">
<li><ul role="none">
<li>Ein Text <abbr="zum Beispiel">z.B.</abbr> über ARIA</li>
</ul></li>
</ul>
Grenzen von role=“none“
Wie bei allen ARIA-Attributen betrifft role=“none“ die Darstellung oder die Funktionalität im Browser in keinster Weise. Vielmehr handelt es sich bei ARIA um einen Satz von Anweisungen an den Browser, was sie an den Accessibility-Tree weitergeben sollen oder nicht. Es gilt daher die Maßgabe, ARIA-Attribute nur dann einzusetzen, wenn die Barrierefreiheit gezielt verbessert werden soll; mit role=“none“ können ebenso wesentliche Strukturmerkmale einer Webseite entfernt und damit die Seite weniger zugänglich gemacht werden.
Außerdem ist role=“none“ nicht universell einsetzbar. Die Rolle wird von Browsern ignoriert in folgenden zwei Situationen:
- Wenn es sich um ein aktives Element handelt (wie Links und Formularelemente, die den Fokus erhalten können).
- Wenn das Element einer der über 20 globalen ARIA-Attribute (wie z.B. aria-label) aufweist.
Wie eingangs bereits erwähnt, ist die Unterstützung für role=“none“ noch nicht in allen Browser-Screenreader-Kombinationen gegeben. Vorerst ist also weiterhin der Einsatz von role=“presentation“ vorzuziehen.
Neues in ARIA 1.1
Es gibt weitere Neuigkeiten in ARIA 1.1, die in loser Folge im Accessibility-Blog veröffentlicht werden:
- Neues in ARIA 1.1 #1 role="presentation" erhält role="none" als Synonym
- Neues in ARIA 1.1 #2 – Mit aria-current das aktuelle Element anzeigen
- Neues in ARIA 1.1 #3 – Ein form-Element als Seitenregion festlegen
- Neues in ARIA 1.1 #4 – role="application" ist jetzt Teil der Dokumentenstruktur (und keine Region)
- Neues in ARIA 1.1 #5 – Mit aria-owns die Hierarchie von Elementen anpassen
- Neues in ARIA 1.1 #6 – Dialogfenster für Screemreader als modal kennzeichnen