Eigenschaft Beziehung

`aria-owns`

Deklariert eine Eltern-Kind-Beziehung im Barrierefreiheitsbaum, wenn die DOM-Struktur diese nicht abbildet. Die referenzierten Elemente werden für assistive Technologien als Kinder dieses Elements betrachtet. Ein mächtiges Werkzeug — leicht falsch einzusetzen.

Wann zu verwenden

Nur dann, wenn der DOM die Kinder nicht dort platzieren kann, wo der Barrierefreiheitsbaum sie benötigt. Der häufigste Anwendungsfall ist eine Popup-Listbox für eine Combobox: Die Liste befindet sich aus Z-Index-Gründen am Ende von <body>, gehört semantisch aber zur Combobox. aria-owns auf der Combobox, das auf die ID der Listbox zeigt, teilt assistiven Technologien mit, die Listbox als Kind zu behandeln.

Lässt sich der DOM so umstrukturieren, dass das Kind ein echtes Nachfahren-Element ist, sollte das bevorzugt werden. aria-owns ist die Notlösung — es funktioniert, umgeht aber jeden natürlichen Plausibilitätscheck, der sicherstellt, dass Markup und Semantik übereinstimmen.

Verhalten

Der Wert ist eine leerzeichen-getrennte Liste von Element-IDs. Der Barrierefreiheitsbaum wird so neu aufgebaut, dass jedes referenzierte Element in der angegebenen Reihenfolge als Kind des besitzenden Elements erscheint. Der ursprüngliche DOM-Elternteil verliert diese Kinder in der Ansicht des Barrierefreiheitsbaums.

Regeln für einen gültigen Baum:

Jede referenzierte ID muss existieren und eindeutig sein.
Ein Element kann jeweils nur von einem Elternteil via aria-owns beansprucht werden. Das Beanspruchen desselben Elements von zwei Stellen führt zu undefiniertem Verhalten.
Ein Vorfahre des eigenen Elements darf nicht beansprucht werden. Das erzeugt einen Zyklus im Barrierefreiheitsbaum.
Das Element muss im DOM erreichbar sein — display: none ist erlaubt, ein vollständig abgetrenntes Element hingegen nicht.

Häufige Fehler

Auf eine ID zeigen, die nicht existiert oder beim letzten Rendering entfernt wurde.
aria-owns verwenden, obwohl der DOM die Kinder korrekt verschachteln könnte. Erhöht die Komplexität ohne Mehrwert.
Zwei aria-owns-Referenzen für dasselbe Kind von unterschiedlichen Eltern — die assistive Technologie wählt willkürlich eine aus.
Vergessen, dass die Fokusreihenfolge unabhängig von aria-owns ist. Die Tastatur durchläuft weiterhin die visuelle DOM-Reihenfolge; der Barrierefreiheitsbaum beeinflusst nur, wie Screenreader die Zugriffsbaumhierarchie traversieren.
aria-owns einsetzen, um ein Problem mit Fokus oder Scroll-into-view zu lösen. Es bewirkt beides nicht.
Eine Region beanspruchen, die ihren eigenen Besitzer enthält — das erzeugt einen Zyklus und bricht den Baum.

Beispiel

<!-- Combobox, deren Popup für den Stapelkontext an body portiert wurde -->
<div
  role="combobox"
  id="city-cb"
  aria-haspopup="listbox"
  aria-expanded="true"
  aria-owns="city-listbox"
>
  <input type="text" aria-controls="city-listbox" aria-activedescendant="city-opt-2">
</div>

<!-- Listbox am Ende von body, semantisch der Combobox zugeordnet -->
<ul role="listbox" id="city-listbox">
  <li role="option" id="city-opt-1">London</li>
  <li role="option" id="city-opt-2" aria-selected="true">Paris</li>
</ul>