aria-braille-equivalent
aria-braillelabel/aria-brailleroledescription müssen eine Entsprechung außerhalb von Braille haben
Prüft, dass Elemente mit aria-braillelabel auch einen regulären zugänglichen Namen haben und Elemente mit aria-brailleroledescription auch aria-roledescription.
Anwendbarkeit. Elemente mit einem nicht leeren aria-braillelabel- und/oder einem nicht leeren aria-brailleroledescription-Attribut.
Erwartung. Laut ARIA-Spezifikation ist aria-braillelabel eine Braille-spezifische ERGÄNZUNG zum regulären zugänglichen Namen des Elements (kein Ersatz dafür), und aria-brailleroledescription ist eine Ergänzung zu aria-roledescription. Ein Element muss daher zusätzlich Folgendes haben:
- einen nicht leeren zugänglichen Namen aus einem Mechanismus außerhalb von Braille, wenn es
aria-braillelabeldeklariert; - ein nicht leeres
aria-roledescription, wenn esaria-brailleroledescriptiondeklariert.
Wird eines der Braille-spezifischen Attribute als EINZIGER Benennungsmechanismus verwendet, erhalten assistive Technologien ohne Braille (die meisten Screenreader, Sprachsteuerung usw.) überhaupt keinen zugänglichen Namen bzw. keine Rollenbeschreibung. Wird als CANTTELL statt FAIL gemeldet: aria-brailleroledescription ohne aria-roledescription erreicht überhaupt niemanden, und ein fehlender zugänglicher Name ist bei Rollen, die einen verlangen, Sache der Benennungsregeln. Dass das Braille-Attribut ohne Gegenstück steht, verdient einen Hinweis, ist aber selbst kein Verstoß gegen ein Kriterium.
Was ein Befund meldet.
attr: das Braille-Attribut ohne Entsprechung:aria-braillelabeloderaria-brailleroledescription.requires: was das Element außerdem braucht: „an accessible name“ (einen zugänglichen Namen) beiaria-braillelabel,aria-roledescriptionbeiaria-brailleroledescription.
Diese Felder in data.details helfen, einen Befund zu lesen und zu reproduzieren. Außer reasonCode und den wenigen Feldern, die Ausgabeschema als stabil nennt, sind sie kein stabiler Vertrag: Ein Feld kann in einer Minor-Version umbenannt werden oder wegfallen, bauen Sie also nicht darauf auf.
Beispiele
<button aria-braillelabel="SAVE">Save changes</button>
Das Braille-Label ergänzt einen echten zugänglichen Namen („Save changes“); assistive Technologien ohne Braille erhalten weiterhin einen Namen.
<button aria-braillelabel="SAVE"></button>
aria-braillelabel ist der einzige vorhandene Benennungsmechanismus; assistive Technologien ohne Braille erhalten überhaupt keinen zugänglichen Namen.
So prüfen Sie es
Wenn diese Regel nicht entscheiden kann, meldet sie cantTell und überlässt die Frage einer Person. Jede Frage, die sie stellen kann, steht hier unter ihrem Reason-Code, mit den Schritten, um sie zu beantworten. Ein Befund enthält dieselben Schritte in howToCheck, in der Sprache des Scans. Siehe Ausgabeschema.
BRAILLE_ATTR_WITHOUT_EQUIVALENT
- Untersuchen Sie das im Bericht genannte Element und notieren Sie, ob es aria-braillelabel oder aria-brailleroledescription hat.
- Hat es aria-braillelabel, öffnen Sie den Bereich „Barrierefreiheit“ in den Entwicklertools des Browsers und lesen Sie den zugänglichen Namen des Elements.
- Braucht die Rolle einen Namen (Schaltfläche, Link, Bild, Kontrollkästchen und Ähnliches), bestätigen Sie, dass es neben dem Braille-Label einen Namen gibt; achten Sie mit einem Screenreader in der Sprachausgabe darauf.
- Hat es aria-brailleroledescription, prüfen Sie, ob es auch aria-roledescription hat; falls nicht, bestätigen Sie, dass die native Rolle weiterhin angesagt wird und nichts anderes gemeint war.
Bestanden. Das Element hat einen gesprochenen Namen (und eine roledescription, wo eine für Braille angegeben ist), oder seine Rolle braucht keinen Namen und nichts geht verloren.
Nicht bestanden. Ein Bedienelement oder Bild hat nur ein Braille-Label, sodass Nutzende der Sprachausgabe keinen Namen erhalten; das verstößt gegen WCAG 4.1.2.