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
- 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.
- 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.
- Das Attribut
aria-describedby
ist als performativ anzusehen. Es informiert nicht über den Zustand eines Elements, sondern bewirkt eine Referenzierung zu einem Objekt. - 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. - 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:
- 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.
- 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.
Links zur Verwendung von ARIA-Attributen
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.
- 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-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
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.
Links zu aria-current
aria-describedby
: Hinweise für interaktive Elemente
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
Links zu 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.
Links zu aria-invalid
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.
Links zu aria-label
- 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.
Links zu aria-labelledby
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-level (state): ARIA Spezifikation
- ARIA12 Technique for WCAG 2.0: Using role=heading to identify headings
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.
aria-modal
: Hinweise zu verfügbaren Dialogfeldern
Bedeutung von aria-modal
Mit aria-modal
wird für Screen Reader verdeutlicht, ob ein Element Bedienungselemente enthält, wenn es angezeigt ist.
Links zu aria-modal
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.
Links zu aria-multiline
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.
Links zu aria-multiline
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-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>
.
Links zu aria-required
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.
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. [?!] |
Links zu aria-sort
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" ...
.