Zweiter Blick: ARIA States

BarrierefreiheitDarstellungsoptionen



ARIA States and Properties

Boddenleitsystem mit Aufmerksamkeitsfeld

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 Webdesign beides schlicht als Attribut anzusehen.

Sprachliche Aktionen durch 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 Usability-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 Usability-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 Usability-Ü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.

wf

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-controls - Verweis auf kontrollierten Bereich (Property)

Bedeutung von Referenzierungen

Inhalte oder allein die Anwesenheit von Inhalten können von Steuerelementen kontrolliert werden. Denken wir etwa an ausklappbare Seiteninhalte (Accordions)

Das Attribut aria-controls identifiziert den vom Steuerelement kontrollierten Bereich für Screen Reader. Es sollte eingesetzt werden, wenn sich der kontrollierte Bereich im DOM nicht unmittelbar unter dem Steuerelement befindet.

Code für aria-controls

Screen Reader Verhalten bei aria-controls

Befindet sich das Attribut aria-controls in einem Element; liefert JAWS in der Version 18 folgende Zusatzinformationen:

Drücken Sie JAWSTASTE + ALT + M um zum Kontrollelement zu springen.

Folgende Usability-Probleme treten dabei auf:

  • Wird der Ausdruck Kontrollelement überhaupt verstanden?
  • Ist der Ausdruck Kontrollelement überhaupt angemessen, da der Tastaturbefehl nicht zum Steuerelement, sondern zum kontrollierten Element führt?
  • Kann jemand gleichzeitig auf die JAWSTASTE, ALT und M drücken, ohne auf die Tastatur zu schauen?

Meines Erachtens sollte daher auf dieses Attribut verzichtet werden, wenn sich der Erweiterungsbereich im DOM unmittelbar unter dem Steuerelement befindet. Wir kommen mit ohnedies in den referenzierten Bereich.

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

  • Der Link zur aktuellen Seite innerhalb der Standortangaben zur Position innerhalb des Webauftritts (Breadcrumbs). Diskutiert wird hierbei jedoch, ob ein Link zur aktuellen Seite überhaupt sinnvoll ist. Und selten unterscheidet sich der Link zur aktuellen Seite in den Breadcrumbs visuell von anderen Links.
  • Der aktuelle Link oder Button eines Prozessbereichs etwa in einem Formulars , das in mehreren Schritten auszufüllen ist.
  • Das visuell hervorgehobene aktuell relevante Element in einem Flussdiagramm.
  • Hervorhebung des aktuellen Datums oder der aktuellen Zeit innerhalb eines Kalenders oder Fahrplanformulars.

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.

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-expanded – Der Erweiterungszustand (State)

Bedeutung des Erweiterungszustandes

Mit aria-expanded kann in einem Element an den Screen Reader die Information weitergegeben werden, ob der von dem Element kontrollierte Bereich gerade erweitert oder eingeklappt, also unsichtbar ist.

Typischerweise finden sich Funktionalitäten zum Ein- und Ausblenden in großen Navigationsstrukturen oder in so genannten Accordions. Sie sind sinnvoll, wenn sie die Übersichtlichkeit und damit die Usability verbessern.

Code

Für das Attribut aria-expanded sollten die Werte true oder false vergeben werden. Der Standardwert undefined scheint mir zu unklar und in der Interpretation durch Screen Reader zu unsicher.

Der Code für ein aufgefächertes Element könnte also etwa folgendermaßen aussehen:

<button aria-expanded="true">Schalter</button>

Controls ergänzen

Im einleitenden Tag des Schalters sollte ergänzend zu aria-expanded mittels aria-controls der Bereich referenziert werden, der ein- oder ausgeklappt werden kann. Der Code für eine Navigation mit ausklappbaren Unterpunkten könnte also etwa folgendermaßen aussehen:

<nav>
  <ul>
    <li>
      <button aria-expanded="false" aria-controls="obst">Obst</button>
      <ul id="obst">
        <li><a href="aepfel/">Äpfel</a></li>
        <li><a href="birnen/">Birnen</a></li>
        ... weitere Obstsorten
      </ul>
    </li>
    ... weitere Navigationspunkte
  </ul>
</nav>

Das Ein- und Ausblenden der Unternavigation muss natürlich technisch noch realisiert und der aria-expanded-Wert dem tatsächlichen Zustand angepasst werden.

Screen Reader Verhalten

aria-expanded Werte und deren Interpretation
Wert Erläuterung JAWS Meldung
true Der zugehörige Bereich ist visuell und mit Screen Reader wahrnehmbar. Erweitert
false Der zugehörige Bereich ist nicht wahrnehmbar. Reduziert
undefined oder leer (Standard) Unklar Reduziert

Anmerkungen

Das Wording Reduziert von JAWS sollte wohl verständlicher Nicht Erweitert lauten.

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

Bedeutung von aria-label

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

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-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-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-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-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-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-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-Attribut

Mit dem Attribut aria-valuetext kann ergänzend zu aria-valuenow für den Screen Reader ein beschreibender Text für die 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" ....


Baustellenschild

Seite in Aufbau

Sie werden bemerken, dass diese Seite noch nicht fertig ist. Inhalte und Funktionalitäten sind noch nicht gänzlich verfügbar. Sie können aber gerne um die Baustelle herumgehen und den Fortschritt beobachten. Das Betreten der Baustelle ist Ihnen aber schon erlaubt und für Sie völlig ungefährlich!