ARIA
Schematische Darstellung: Person mit weißem Stock gelangt über ein Boddenleitsystem zu einem Aufmerksamkeitsfeld

ARIA Zustände und Eigenschaften
(States and Properties)

[Materialsammlung]

Explizite Anweisungen und Hinweise für assistierende Technologien.

Bedeutung von ARIA States & Properties

Verständlichkeit für Screen Reader gewährleisten

Was etwas auf einer Webseite ist, wozu es dient und in welchem Zustand es sich befindet, ist visuell intuitiv verständlich, wenn die Grafik einer Webseite halbwegs konsistent ist. Für Screen Reader hingegen müssen Name, Rolle, Zustand und Ähnliches technisch wahrnehmbar gemacht werden.

Ob etwa in einer Optionsliste ein Element schon ausgewählt ist oder ob ein ausklappbares Element gerade ausgeklappt ist oder nicht. All das ist auf dem Bildschirm spontan wahrnehmbar und klar. Beim Surfen mit einem Screen Reader sind solche Zustände von Elementen selbst in Standard HTML Elementen nicht immer wahrnehmbar.

Die Accessible Internet Rich Applications (ARIA) States and Properties bieten ein umfangreiches Angebot an Attributen, mit denen im Web Inhalte und Zusammenhänge für Screen Reader wahrnehmbar und verständlich gemacht werden können.

State versus Property

Die Ausdrücke State und Property beziehen sich auch in der Spezifikation auf sehr ähnliche Merkmale von Attributen. Zustände können sich schneller einmal ändern (aria-checked="true | false") als Eigenschaften, etwa bei einer Beschriftung mittels aria-labelledby. Aber auch dies wird nicht als allgemeine Regel vorgegeben.

Mir hat sich bislang noch keine Praxisrelevanz der Unterscheidung erschlossen. Selbst die Spezifikation empfiehlt beim Web Design beides schlicht als Attribut anzusehen.

Clarification of States versus Properties

Sprechakte und ARIA-Attribute

Um für die Funktionalitäten der diversen ARIA-Attribute ein klareres Verständnis zu schaffen, habe ich mich meiner philosophischen Studienjahre erinnert und Anleihen aus der Sprechakttheorie nach John Langshaw Austin und Wittgensteins Sprachspieltheorie Anleihen genommen: Sprache wird nicht nur zur Beschreibung der Wirklichkeit verwendet, sondern kann selbst eine Wirklichkeit schaffen: Eine Information ist etwas anderes als eine Behautung, eine Ernennung oder Verurteilung und Ähnliches.

Ich schlage zur Unterscheidung der Attribute und zum Verständnis deren Einsatzes folgende Klassifikation vor:

Informative Attribute
Das Attribut dient zur Beschreibung des Zustandes eines Elements oder dessen Bezugsumgebung.
Beispiele: aria-checked="true | false", aria-expanded="true | false", ...
Performative Attribute
Das Attribut bewirkt etwas an einem Element oder dessen Darbietung im Kontext.
Beispiele: aria-hidden="true | false", aria-label="[String]", ...
Deklarative Attribute
Das Attribut vergibt einem Element eine Funktionalität innerhalb spezifizierter Auswahlmöglichkeiten.
Beispiele: Alle ARIA Roles

Anmerkungen zur Unterscheidung nach sprachlichen Aktionen

  1. Eine Faustregel für informative Attribute ist, das sie einen Sachverhalt richtig oder falsch wiedergeben können. Performative Attribute können das nicht. Sie können nur fehlerhaft oder unkorrekt eingesetzt werden.
  2. Die deklarativen Attribute stellen einen Sonderfall der performativen Attribute dar: Sie informieren nicht über die Funktionalität eines Elements, sondern weisen eine bestimmte Rolle zu, ja können die natürliche Rolle eines HTML-Elements sogar überschreiben.
  3. Das Attribut aria-describedby ist als performativ anzusehen. Es informiert nicht über den Zustand eines Elements, sondern bewirkt eine Referenzierung zu einem Objekt.
  4. Die Attribute für Live-Regionen (aria-live, aria-atomic, aria-busy, aria-relevant) sind als performativ anzusehen. Sie informieren nicht von sich aus, sondern steuern die Darstellung von beschreibenden Objekten für Screen Reader.
  5. Das Attribut aria-sort dient nicht dazu, eine Tabellenspalte für einen Screen Reader zu sortieren. Es hat keinen performativen Charakter und kann lediglich darüber informieren, ob eine Spalte auf- oder absteigend sortiert ist.

Verwenden und Vermeiden von ARIA-Attributen

Die ARIA-Attribute stellen für sich keine umfassende Webtechnologie dar, sondern schließen Lücken etwa der HTML-Spezifikation bei der Nutzung mittels Screen Reader. Sie sind also auch nicht immer notwendig und zweckmäßig. Insbesondere folgende Punkte sind beim Einsatz zu bedenken:

Implizite Semantik vor expliziter Semantik

Bietet eine Technologie bereits von sich aus Informationen oder Funktionalitäten aus dem ARIA-Repertoire, wird von impliziter Semantik gesprochen. Ist diese vorhanden, kann auf die entsprechenden ARIA-Attribute verzichtet werden.

So verfügt etwa das HTML-Element <button> über die hinreichende Semantik eines Schalters auch für Screen Reader. Sofern vorhanden, sollte ein solches Element des Host Language auch verwendet werden und nicht etwa eine nachträgliche explizite Semantik, etwa durch <div role="button">.

Auch HTML-Attribute können ARIA ersetzen, wenn die Verwendung laut Spezifikation identisch und nicht nur ähnlich ist. Das HTML-Attribut required liefert dem Screen Reader beispielsweise alle Informationen, die auch aria-required bieten kann.

ARIA-Attribute werden also subsidiär eingesetzt, wenn Wahrnehmbarkeit und Verständlichkeit in der übergeordneten Webtechnologie nicht ausreichend gewährleistet sind.

So wenig wie möglich …

So überraschend es klingt: Viele, die auf Screen Reader angewiesen sind, haben eine Abneigung gegen alles entwickelt, was ihnen auf Grund von ARIA-Anweisungen an Zusatzinformationen geliefert wird. Eine Ursache dafür besteht vielfach in einem fehlerhaften Einsatz von ARIA-Attributen. Ebenso liegt es aber auch an einem überbordenden Einsatz auf Grund fehlender Useability-Tests mit Screen Readern.

Befindet sich etwa in einem Accordion der Erweiterungsbereich im DOM unmittelbar unter dem Steuerelement für den Erweiterungszustand, genügt es, den Erweiterungszustand mittels aria-expanded anzugeben. Zum Erweiterungsbereich zusätzlich mittels aria-controls zu referenzieren führt zu Useability-Problemen für Screen Reader.

Umgang mit mangelhafter Implementation

Stand der Implementation (2018)

Leider kann man sich nicht darauf verlassen, dass korrekt eingesetzte ARIA-Attribute von Screen Readern tatsächlich auch umgesetzt werden. Teilweise resultiert dies aus Versäumnissen auf Entwicklungsseite, teilweise aus vermeintlichen Useability-Überlegungen bei der Entwicklung.

JAWS stellt in der Version 2018 explizit eine Konfigurationsmöglichkeit zum Unterdrücken von Meldungen von HTML 5 und ARIA-Anweisungen. Die Standardkonfiguration führt dabei bereits zu einer eingeschränkten Umsetzung.

Grundsatzüberlegungen zum Umgang bei mangelhafter Implementation

Die Frage, wie mit Unzulänglichkeiten von Technologien umzugehen ist, führt zu philosophischen und pädagogischen Grundentscheidungen:

  1. Wir halten uns an die Möglichkeiten und Einschränkungen aus den technischen Spezifikationen. Funktioniert etwas (noch) nicht, können wir uns auf (positivrechtliche) Bestimmungen berufen. Auftauchende Umsetzungsprobleme liegen in der Verantwortung von Betriebssystemen, Browsern und Assistierenden Technologien, die zur Verantwortung zu ziehen sind.
  2. Wir versuchen das Beste aus den bereits implementierten Funktionalitäten zu machen. Weil der kleinste gemeinsame Nenner der verschiedenen Systeme bei der Implementation oft nicht für eine befriedigende Problemlösung ausreicht, nehmen wir zähneknirrschend unschöne Hacks und Mängel in Kauf.

Die wenigsten Menschen, die mit Assistierenden Technologien arbeiten, kennen die möglichen Funktionalitäten ihrer Systeme. Sie haben sich bestenfalls bescheidene Schneißen für einen Zugang zum Internet geschlagen. Das weiß ich aus meiner langjährigen Arbeit mit blinden und sehbehinderten Menschen.

Wir können also nur von wenigen Einzelpersonen ausgehen, die eine mangelhafte Umsetzung überhaupt in Betracht ziehen. Die meisten führen Probleme auf eigene Unzulänglichkeiten oder gar Bedienungsfehler zurück und ergeben sich ihrem Schicksal.

Die wenigen, denen die Möglichkeiten von ARIA-Attributen überhaupt bekannt sind, müssen sich bei Problemen erst dazu aufraffen, von ihrem Screen Reader nachhaltig eine Umsetzung der Spzezifikationen einzufordern. Wer wie ich mit der Materie ständig zu tun hat, weiß dass beim Surfen täglich mehrere Webseiten mit Mängeln in der Barrierefreiheit zu finden sind. Alle diese Mängel zu analysieren und zu dokumentieren, würde die eigenen Ressourcen und Nerven bei Weitem überstrapazieren.

Was ich damit sagen will: Verlassen wir uns nicht auf die Wehrhaftigkeit der Betroffenen, sondern gewöhnen wir diese an gut wahrnehmare und bedienbare Inhalte. Sie werden diese immer deutlicher erkennen und schätzen lernen.

Letztlich bleibt es eine Grundsatzentscheidung, die ich den Betreibern von Webseiten nicht abnehmen kann. A oder B, also die Berufung auf die Spezifikationen oder die Kunst des bereits Möglichen.

Unterseiten zu einzelnen Attributen

aria-atomic (Ausgabedetails für Live Regionen )
Festlegen der Aktualisierungsinformationen zu Live Regionen (Gesamter Inhalt / Änderungen)
aria-autocomplete
Metainformationen über Ergänzungsvorschläge bei der Formulareingabe.
aria-busy - Benachrichtigungen nach Abschluss des Prozesses
Informationen über den Abschluss eines Prozesses in Live Regionen
aria-controls
Verweis auf einen Bereich , der von einem Steuerelement kontrolliert wird.
aria-expanded
Information über den Erweiterungszustand einer ausklappbaren Komponente.
aria-haspopup
Beschreibung des Vorhandenseins und Typs eines Popup-Fensters, das durch das Steuerelement ausgelöst werden kann.
aria-hidden
Element für assistierende Technologien verbergen
aria-roledescription
Festlegen einer eigenen Beschriftung für standardmäßig definierte Rollen.

aria-checked: Info über Aktivierungszustände

Mit dem Attribut aria-checked sollte der Zustand eines Formularelements der Typen checkbox oder radio gekennzeichnet werden können. Ob das jeweilige Element gerade ausgewählt ist oder nicht sollte mit den Werten true, false oder mixed an den Screen Reader übergeben werden können.

Ich schreibe im Konjunktiv, den Screen Reader kümmern sich noch nicht um das Attribut (Stand August 2018). Wer ein Formular mit HTML-Attributen korrekt realisiert, braucht sich deswegen aber nicht den Kopf zerbrechen. Screen Reader geben dann den jeweiligen Zustand ohnedies sauber wieder, ohne dass aria-checked erforderlich wäre.

Zu Unterscheiden ist übrigens auch die Verwendung von aria-checked und dem HTML Attribut checked. Letzteres dient dazu, eine Voreinstellung vorzunehmen und nicht dazu, einen Zustand zu beschreiben.

aria-checked (state): ARIA Spezifikation

aria-current - Hervorhebung aktueller Zustände (State)

Bedeutung von Hervorhebungen aktueller Zustände

Zweckmäßigerweise werden in komplexeren Seitenelementen, wie etwa Kalendern, aktuelle Angaben visuell hervorgehoben. Für die technische Wahrnehmbarkeit solcher Hervorhebungen für Screen Reader steht das aria-current Attribut zur Verfügung.

Gekennzeichnet wird auf diese Weise ein Element innerhalb einer Gruppe zusammengehöriger Elemente. Üblicherweise handelt es sich um Aufzählungen von Elementen desselben Typs.

Einsatzbereiche für aria-current

Werte für aria-current

aria-current Werte und deren Bedeutung
Wert Bedeutung
page Die aktuell geladene Seite innerhalb des Webauftritts
step Der aktuelle Schritt in einem Prozess, etwa beim Ausfüllen von Formularen
location Der aktuelle Standort in einer Umgebung, etwa einem Flussdiagramm
date Das aktuelle Datum etwa innerhalb eines Kalenders
time Die aktuelle Zeitangabe innerhalb von mehreren Zeitangaben
true Das aktuelle Element einer Elementengruppe.
false (Voreinstellung) Ist aktuell kein aktuelles Element.

aria-current oder aria-selected?

aria-current und aria-selected haben unterschiedliche Bedeutungen, die sich jedoch auch überschneiden können. In diesem Fall kann es sinnvoll sein, beide Attribute auf ein Element anzuwenden. Ich rate jedoch zu einem sparsamen Einsatz beider Elemente gleichzeitig, um Redundanzen beim semantischen Verständnis zu vermeiden.

Im Gegensatz zu ↓ aria-selected wird aria-current natürlich jeweils nur auf ein Element angewendet.

Im Zweifelsfall sollte wohl meist aria-selected verwendet werden, etwa um den aktuell ausgewählten Tab in einer Tabliste zu kennzeichnen. aria-current ersetzt technisch visuelle Indikatoren. Und der ausgewählte Tab ist visuell anders als bei der linearen Wahrnehmung mittels Screen Reader ohnedies spontaner wahrnehmbar.

Mit dem Attribut aria-describedby kann für einen Screen Reader auf nötige Hinweise und Beschreibungen referenziert werden, sobald ein Link oder Formularelement den Fokus erhält.

aria-details (Property)

Bedeutung von aria-details

aria-disabled: Kennzeichnen inaktiver Seitenbereiche

Bedeutung inaktiver Seitenbereiche

Mit dem Attribut aria-disabled können aktuell wahrnehmbare, aber nicht bedienbare Elemente gekennzeichnet werden. Sie sind also nicht gänzlich ausgeblendet und werden typischerweise visuell ausgegraut.

Einzelne Formularelemente können zu einem bestimmten Zeitpunkt deaktiviert sein, etwa um den Ausfüllfortschritt übersichtlicher darzustellen. Elemente sind natürlich immer nur kontextabhängig deaktiviert.

Technische Kennzeichnung inaktiver Seitenbereiche für Screen Reader

Der jeweilige Darstellungszustand kann mit dem Attribut aria-disabled und den Werten true / false für den Screen Reader angegeben werden. Das Attribut wirkt sich auf das gekennzeichnete Element und dessen Descendets aus.

Es kann zweckmäßig sein, wenn deaktivierte Elemente überhaupt nicht mittels Tabulator fokussiert werden können.

aria-errormessage: Referenzieren auf Fehlerhinweise

Mittels aria-errormessage kann ähnlich zu aria-describedby auf Fehlerhinweise bei mangelhaften Formulareingaben referenziert werden.

Leider erscheint die Unterstützung durch Browser und Screen Reader noch sehr wackelig, wie ich durch eigene Experimente und Webrecherchen feststellen musste (Stand August 2018).

aria-errormessage implementation: Diskussion auf der WebAIM Diskussionsliste 2018

aria-invalid: Fehlerhafte Eingaben

Bedeutung von aria-invalid

Mit dem Attribut aria-invalid kann ein Formularelement mit einer fehlerhaften Eingabe als solches gekennzeichnet werden.

aria-label: Beschriftung von Elementen für Assistierende Technologien

Bedeutung von aria-label

Mittels aria-label kann ein (Steuer-)Element explizit für Assistierende Technologien beschriftet werden. Es ist also wichtig zu berücksichtigen, dass diese Beschriftungen ohne Assistierende Technologien nicht wahrnehmbar sind.

W3C | aria-label (property): ARIA 1.1 Spezifikation
Die ARIA 1.1 Spezifikation (Recommendation)
TPGi | Short note on aria-label, aria-labelledby, and aria-describedby
Für welche Elemente dürfen diese Attribute verwendet werden?

aria-labelledby: Beschriftung mittels Referenzieren

Bedeutung von aria-labelledby

Mittels aria-labelledby kann ein Element durch Referenzieren auf ein anderes Element beschriftet werden. Dies kann etwa sinnvoll sein, wenn sich in einem Formular eine Tabelle mit Eingabemöglichkeiten jeweils zur selben Spaltenüberschrift befindet.

aria-level - Infos über das Niveau eines Elements

Bedeutung von aria-level

Mit aria-level kann etwa die Überschriftenebene eines Elements festgelegt werden, das mittels role="heading" als Überschrift gekennzeichnet ist.

aria-live - Infos zu Live Regionen

Seitenbereiche oder Seitenelemente ändern sich zeitbasiert oder durch Eingaben gelegentlich, etwa bei der Aktualisierung von Börsenkursen oder bei Eingaben in Formularelementen. Damit auch der Screen Reader diese dynamischen Änderungen vermittelt, muss das aria-live Attribut verwendet werden.

Mit aria-modal wird für Screen Reader verdeutlicht, ob ein Element Bedienungselemente enthält, wenn es angezeigt ist.

aria-modal (property): ARIA Spezifikation

aria-multiline: Mehrzeilige Eingabe möglich

Bedeutung von aria-multiline

Mit aria-multiline wird für Screen Reader verdeutlicht, ob in einem Textfeld eine mehrzeilige Eingabe erlaubt ist.

aria-multiline (property): ARIA Spezifikation

aria-multiselectable: Mehrfachauswahl möglich

Bedeutung von aria-multiselectable

Mit aria-multiselectable wird für Screen Reader verdeutlicht, ob eine Mehrfachauswahl möglich ist. Wenn gewöhnliche HTML Checkboxen in einer Liste angeboten werden, erscheint dieses Attribut nicht erforderlich.

aria-multiselectable (property): ARIA Spezifikation

aria-placeholder: Platzhalter für ein Eingabefeld

Soweit ich es sehe, kann mit aria-placeholder das gemacht werden, was das HTML-Attribut placeholder nicht nur für Screen Reader macht. Ich sehe daher keinen Einsatzbereich, lass mich aber gerne belehren.

aria-placeholder (property): ARIA Spezifikation

aria-pressed - Der Zustand eines Toggle-Schalters

Bedeutung von aria-pressed

Mit aria-pressed kann der Zustand eines Toggle - Schalters an den Screen Reader übergeben werden.

aria-readonly (property): Formularelemente ohne Bedienungsmöglichkeiten

Mit aria-readonly="true" kann ein Formularelement, das nicht editierbar ist, als solches gekennzeichnet werden. Dass das Formularelement tatsächlich nicht editierbar ist, muss mit anderen Webtechnologien gewährleistet werden.

Die Unterstützung durch Browser / AT ist noch nicht gegeben (Stand August 2018).

aria-readonly (Property): ARIA Spezifikation

aria-relevant - Filter auf mitzuteilende Aktualisierungen

Filter für die Referenzierungen auf Live Regionen (Dynamische Seiteninhalte)

aria-required – Pflichtfelder in Formularen kennzeichnen

Bedeutung von Pflichtfeldern

Formulare verfügen gelegentlich über Formularelemente, die unbedingt auszufüllen sind. Wer beispielsweise einen Newsletter abonnieren möchte, braucht vielleicht nicht seinen Namen angeben, unbedingt jedoch seine E-Mail Adresse.

Grafisch werden Pflichtfelder häufig durch ein Sternchen (*) oder durch grafische Hervorhebungen gekennzeichnet. Damit die Bedeutung an den Screen Reader ausgegeben wird, sollte aria-required="true" verwendet werden.

Technischer Einsatz von aria-required

Bei Textfeldern wird das Attribut im <input>-Element eingefügt.

Soll ein Element aus einer Gruppe, etwa einer Optiongroup oder einer Sammlung von Checkboxen unbedingt gewählt werden, sollte sich das Attribut im übergeordneten Element befinden. Zweckmäßig ist das ein <fieldset> oder eine <ul>.

aria-selected - Kennzeichnung als ausgewählt

Bedeutung von aria-selected

Mit aria-selected werden üblicherweise Elemente in einer Auswahlgruppe gekennzeichnet, die eine Auswahl mehrerer Elemente zulässt. Das können Optionen in einer Listbox sein oder Zeilen einer Tabelle.

Es kann aber auch dazu verwendet werden, ein Element als aktiv zu kennzeichnen, ohne dass sich der Fokus gerade auf dem Element befindet, etwa ein Tab innerhalb einer Seite.

Es empfiehlt sich, aria-selected nur für columnheader, gridcell, menuitemradio, option, row, rowheader, tab und treeitem einzusetzen. Bei radio buttons gehen die Meinungen auseinander, ob für diese nicht ausschließlich aria-checked verwendet werden sollte.

Missbrauch von aria-selected

aria-selected darf nicht in Links verwendet werden, um etwa einen Toggle Schalter zu simulieren. Ebenso ist das Attribut nicht geeignet, um Kontrollkästchen als angekreuzt zu kennzeichnen. Ausgewählt ist nicht das gleiche wie angekreuzt.

aria-sort: Kennzeichn einer sortierten Spalte

Bedeutung von aria-sort

Mit aria-sort kann eine Spalte als aufsteigend oder absteigend sortiert gekennzeichnet werden.

Anders als der Ausdruck sort vermuten lässt, ist das Attribut nicht performativ, sondern informativ. Die Spalte wird damit nicht sortiert, sondern es wird nur eine Zustandsbeschreibung an den Screen Reader übergeben, die nicht einmal den Tatsachen entsprechen muss. Intuitiver wäre wohl der Ausdruck aria-sorted gewesen.

Ich denke, das Attribut aria-sort kann beim Einsatz von Screen Readern in vielen Fällen zum Verständnis und der Bedienbarkeit von Tabellen beitragen (UX!). Die Unterstützung durch Browser und Assistierende Technologien ist jedenfalls schon sehr gut gegeben.

Technische Realisierung von aria-sort

Das Attribut wird in der Spaltenüberschrift gesetzt, also etwa im TH-Element in HTML.

Werte für das Attribut aria-sort
Wert Bedeutung
ascending Die Tabelle ist aufsteigend sortiert beginnend mit dem niedrigsten Wert in dieser Spalte (Niedrigste Zahl, frühestes Datum, etc.)
descending Die Tabelle ist absteigend sortiert beginnend mit dem höchsten Wert in dieser Spalte (Größter Gewinn, meiste Einwohner, etc.)
none (Standardwert) Unsortiert
other Eine Sortierung liegt vor, die aber weder auf- noch absteigend ist. [?!]

aria-value-Attribute: Werte und Wertbereiche

Bedeutung der aria-value-Attribute

Mit den Attributen aria-valuemin, aria-valuemax und aria-valuenow können etwa bei einem Schieberegler (Slider) der mögliche Wertebereich und der aktuelle Wert an den Screen Reader übergeben werden. Der Wert des Attributs besteht jeweils aus einer Zahl.

Technischer Einsatz von aria-value-Attributen

Der Code kann etwa folgendermaßen aussehen:

 <div role="slider" 
   aria-valuemin="1"
   aria-valuemax="10"
   aria-valuenow="4">

Sind Maximalwert und Minimalwert für einen Bereich bekannt sollten aria-valuemax und aria-valuemin eingesetzt werden.

JAWS 2018 gibt übrigens tatsächlich nur den aktuellen Wert wieder, nicht jedoch Minimal- und Maximalwert.

aria-valuetext (Eigenschaft)

Mit dem Attribut aria-valuetext kann ergänzend zu aria-valuenow für den Screen Reader ein beschreibender Text für den aktuellen Wert festgelegt werden, etwa Niedrig / Mittel / Hoch. Der Code für die niedrigste Stufe könnte hierbei etwa folgendermaßen aussehen: 

 <div role="slider" 
   aria-valuemin="1"
   aria-valuemax="3"
   aria-valuenow="1"
   aria-valuetext="Niedrig">

Eine saubere technische Umsetzung scheint mir ziemlich aufwendig zu sein. Insbesondere muss im Sinne der Barrierefreiheit auch für eine adäquate visuelle Realisierung der Beschriftung gesorgt werden. Da es sich bei diesen Auswahlwerten meist nur um eine kleine Gruppe von Optionen handeln dürfte, liegt es daher nahe gleich eine Optionsgruppe anzulegen und jeden einzelne Wert als <input type="radio" ....