Neues in ARIA 1.1 #5  

Manchmal sind Webseiten so aufgebaut, dass die Reihenfolge bzw. Hierarchie der Inhalte im Document Object Model (DOM) in Hilfsmitteln wie Screenreader nicht optimal genutzt werden können. Mit Accessible Rich Internet Applications (ARIA) kann die Hierarchie der Inhalte für Screenreader und andere Hilfsmittel in wenigen Schritten angepasst werden, ohne dass die Reihenfolge oder Hierarchie im DOM angepasst werden muss. Ist das Zukunftsmusik oder verfügen wir bereits über diese Technik?

Mit dem aria-owns-Attribut für ein HTML-Element können ein oder mehrere Elemente angegeben werden, um sie als eigene Kindelemente zu „beanspruchen“. Wenn die Herstellung einer solchen Beziehung nicht mit HTML hergestellt werden kann, dann kann aria-owns eingesetzt werden, um diese Beziehung nachträglich für Hilfsmittel wie Screenreader besser darzustellen.

Mit der folgenden Auszeichnung:

<div role="heading" aria-level="2" aria-owns="query">Suchergebnisse</div>
...
<div id="query">für "download" </div>

schreibt der Browser im Accessibility-Tree Daten entsprechend:

<h2>Suchergebnisse für "download"</h2>

Wichtig: Im DOM passiert durch aria-owns absolut gar nichts, sondern alle Änderungen finden ausschließlich im Accessibility-Tree des Betriebssystems statt.

Obwohl der Text mit dem Suchstring kein Kind des Überschriftentexts ist, wird er durch den Einsatz des aria-owns-Attributs so im Accessibility-Tree behandelt. Mit dieser Technik können auch mehrere Elemente (mehrere mit Leerzeichen getrennte ID-Werte) auf einer Webseite mit aria-owns eingesammelt und zu Kindelementen eines anderen Elements gemacht werden. Generell gilt aber, dass jede Eltern-Kind-Beziehung zwischen Elementen auf einer Webseite mit HTML darzustellen ist; aria-owns muss meist als Reparaturtechnik für nicht barrierefreien HTML-Code angesehen werden.

Einfaches Beispiel

Eine typische Situation, in der aria-owns als Reparaturtechnik eingesetzt werden könnte, ist die Darstellung einer Hauptnavigation mit einem Untermenü, wobei das Untermenü die Unterpunkte einer der Einträge in der Hauptnavigation darstellt. Visuell kann ein Zusammenhang zwischen Hauptnavigation und Untermenü oft hergestellt werden etwa durch Farben oder Grafiken. Strukturell (z.B. in einem Screenreader) ist die Zuordnung des Untermenüs zu einem der Einträge der Hauptnavigation nicht immer möglich.

Wenn die horizontale Navigation wie folgt aufgebaut wird:

<nav>
<ul>
<li><a href="/">Startseite</a></li>
<li><a class="aktuell" href="/services">Unser Angebot</a></li>
<li><a href="/kontact">Kontakt</a></li>
</ul>
</nav>

und eine vertikale Navigation mit folgendem Aufbau folgt:

<nav>
<ul>
<li><a href="/beratung">Accessibility-Consulting</a></li>
<li><a href="/tests">Konformitätsprüfungen</a></li>
<li><a href="/pdf">Barrierefreie PDF</a></li>
</ul>
</nav>

kann das Untermenü nicht unbedingt einem übergeordneten Punkt zugeordnet werden, auch wenn in diesem Beispiel recht viel auf „Unser Angebot“ deutet. Natürlich kann das Untermenü genauer beschriftet werden etwa mit
<nav aria-label="Untermenü Unser Angebot">
, aber die zweite Linkliste kann auch mit aria-owns explizit als verschachtelte Liste zu „Unser Angebot“ festgelegt werden.

Alternative Lösung mit ARIA

Das aria-owns-Attribut verändert die Hierarchie der Elemente nur im Accessibility-Tree und kann dann eingesetzt werden, wenn beabsichtigte oder offensichtliche Eltern-Kind-Beziehungen im DOM nicht hergestellt werden können. Bevor in diesem Beispiel aria-owns eingesetzt wird, sollte deshalb geprüft werden, ob folgender Aufbau des HTML möglich ist und auf aria-owns verzichtet werden kann:

<nav>
<ul>
<li><a href="/">Startseite</a></li>
<li><a class="aktuell" href="/services">Unser Angebot</a><ul>
<li><a href="/beratung">Accessibility-Consulting</a></li>
<li><a href="/tests">Konformitätsprüfungen</a></li>
<li><a href="/pdf">Barrierefreie PDF</a></li>
</ul></li>
<li><a href="/kontact">Kontakt</a></li>
</ul>
</nav>

Wann immer möglich, ist die Anpassung des DOM dem Einsatz von aria-owns vorzuziehen. Die Anpassung des DOM kann manchmal Probleme bereiten etwa wenn sie zusätzliche Anpassungen im CSS oder PHP nach sich zieht. Nur wenn der Umbau des HTML nicht möglich ist, kommt die alternative Lösung mit aria-owns in Frage:

<nav>
<ul>
<li><a href="/">Startseite</a></li>
<li aria-owns="untermenue"><aa class="aktuell" href="/services">Unser Angebot</a></li>
<li><a href="/kontact">Kontakt</a></li>
</ul>
</nav>
...
<nav>
<ul id="untermenue>
<li><a href="/beratung">Accessibility-Consulting</a></li>
<li><a href="/tests">Konformitätsprüfungen</a></li>
<li><a href="/pdf">Barrierefreie PDF</a></li>
</ul>
</nav>

Hinweis: Das aria-owns mag bestimmte Beziehungen in Screenreadern wiederherstellen, aber für die Barrierefreiheit müssen die Beziehungen auch in anderen Situationen gegeben sein, etwa bei Vergrößerung oder im Kontrastmodus.

Unterstützung in Screenreadern

Die Unterstützung von aria-owns in Screenreadern ist derzeit durchwachsen. Das Beispiel mit der Navigation und einem Untermenü haben wir mit verschiedenen Browsern und Screenreadern getestet. Das erwartete Ergebnis ist:

1. Eine Navigationsregion wird identifiziert.
2. In der Navigationsregion befindet sich eine Linkliste mit drei Einträgen.
3. Nach dem zweiten Eintrag beginnt eine verschachtelte Liste mit weiteren drei Links.
4. Hingegen wird der Navigationsbereich mit dem Untermenü hinter der Hauptnavigation nicht vom Screenreader erfasst (weil die Region keinen Inhalt mehr hat).

Auf Windows 10 wurden die folgenden Browser getestet:

• Internet Explorer 11,
• Edge 40
• Firefox 56 und
• Chrome 61

Folgende Screenreader wurden getestet:

• JAWS 18,
• Cobra 11.2,
• NVDA 2017.3,
• Narrator und
• ChromeVox 53 (nur auf Chrome).

Darüber hinaus wurden Safari mit VoiceOver auf iOS 11.0.3 sowie Chrome 62 mit TalkBack auf Android 4.4.2 getestet.

Unterstützung von aria-owns

Rolle
aria-owns

Der Grad der Unterstützung ist derzeit sehr unterschiedlich. Einige Beispiele sind:

• Die referenzierten Inhalte werden zwar zum Elternelement herangezogen, aber die referenzierten Inhalte bleiben zugänglich, so dass sie doppelt vorhanden sind (Internet Explorer mit JAWS).
• Die zweite Region wird nicht ignoriert, wenn sie leer ist (JAWS mit Firefox).
• Beim Navigieren nach unten wird die neue Hierarchie richtig ausgegeben, aber wenn rückwärts navigiert wird, orientiert sich die Lesereihenfolge an den DOM (Narrator mit Internet Explorer).

Teilweise wurden Daten aus dem Accessibility-Tree mit ausgegeben oder der Umfang der Listen falsch angegeben (Liste mit zwei statt drei Einträgen).

Da die Ergebnisse so unterschiedlich sind und oft eher zur Verwirrung beitragen, muss derzeit vom Einsatz des Attributs abgeraten werden.

Weitere Hinweise zu aria-owns

Das globale aria-owns-Attribut verändert die Reihenfolge von Inhalten, aber ausschließlich im Accessibility-Tree. Auf den DOM hat aria-owns keinen Einfluss. Die per aria-owns referenzierten Inhalte werden in einem Screenreader als Kind des Elements mit dem aria-owns dargestellt und an der Stelle, wo sie vorher nach dem DOM stehen sollten, stehen die referenzierten Inhalte nicht mehr im Accessibility-Tree. So viel zum Soll-Zustand!

Das Beispiel mit den zwei Linklisten weist ein ganz anderes Problem auf. Die Lesereihenfolge im Screenreader wird zwar in bestimmten Browser-Screenreader-Kombinationen geändert, aber die Fokus-Reihenfolge bleibt davon unberührt und die Lesereihenfolge weicht von der Fokus-Reihenfolge ab. Wenn jemand mit der Tab-Taste durch die Links wandert, bleibt die Reihenfolge im DOM entscheidend für die Fokus-Reihenfolge, es sei denn, es wird ein autorenseitiges Fokus-Management implementiert. Das wäre für das Beispiel sicher ein Overkill, aber für bestimmte Widgets (z.B. Comboboxen, sortierbare Tabellen oder Baumnavigationen) muss ein Fokus-Management bereitgestellt werden, so dass dann theoretisch auch mit aria-owns gearbeitet werden könnte.

Im Accessibility-Tree des Betriebssystems setzen sich die Kindelemente eines beliebigen Elements zusammen aus den eigentlichen Kindelementen, wie sie im DOM stehen, und weiteren Elementen, die mit aria-owns herangezogen werden. Standardmäßig stehen die echten Kindelemente an erster Stelle, und die mit aria-owns herangezogenen Elemente bilden die letzten Kindelemente des Elternelements. Wenn diese Reihenfolge geändert werden soll, dann erfolgt das über das aria-owns-Attribut. Im folgenden Beispiel wird das erste echte Kindelement als letztes Kindelement im Accessibility-Tree dargestellt:

<div aria-owns="irgendwas1 irgendwas2 ersterabsatz">
<p id=ersterabsatz">Erster Text</p>
<p>Zweiter Text</p>
</div>
...
<p id="irgendwas1">Dritter Text</p>
<p id="irgendwas2">Vierter Text</p>

Im Accessibility-Tree ist die Reihenfolge Zweiter Text, Dritter Text, Vierter Text und dann Erster Text.

Schließlich muss darauf hingewiesen werden, das Elemente, die sonst keine Kindelemente besitzen, auch nicht mit aria-owns Kindelemente erhalten dürfen. Ob ein <img> oder <input> oder <textarea> – diese Elemente haben alle niemals Kindelemente! Das gilt auch dann, wenn beispielsweise ein Eingabefeld die Rolle „combobox“ erhält. Auch für aktive Elemente wie <button> oder <a href> – die selbstverständlich Kindelemente haben dürfen – gibt es eine Einschränkung: Aktive Elemente dürfen keine anderen aktiven Elemente als Kindelement haben.

Ein aria-owns-Attribut ist vor allem in zusammengesetzten Widgets (z.B. Comboboxen) sinnvoll, aber der Einsatz ist heute noch problematisch wegen der unzuverlässigen Unterstützung. Besser ist die Behebung von Aspekten der Hierarchie oder der Reihenfolge im HTML – diese Herangehensweise ist zumindest normalerweise machbar und leichter nachzuvollziehen.

Dieser Beitrag ist Teil einer mehrteiligen Serie zu Aria 1.1:

• 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