aria-braille-equivalent
aria-braillelabel/aria-brailleroledescription must have a non-braille equivalent
Checks that elements using aria-braillelabel also have a regular accessible name, and elements using aria-brailleroledescription also have aria-roledescription.
Applies to. Elements with a non-empty aria-braillelabel and/or non-empty aria-brailleroledescription attribute.
Expectation. Per the ARIA specification, aria-braillelabel is a Braille-specific SUPPLEMENT to (not a replacement for) the element's regular accessible name, and aria-brailleroledescription is a supplement to aria-roledescription. An element must therefore also have:
- a non-empty accessible name from a non-braille mechanism, if it declares
aria-braillelabel; - a non-empty
aria-roledescription, if it declaresaria-brailleroledescription.
Using either braille-specific attribute as the ONLY naming mechanism leaves non-braille assistive technology (most screen readers, voice control, etc.) with no accessible name/role description at all. Reported at CANTTELL rather than FAIL: aria-brailleroledescription without aria-roledescription reaches no user at all, and a missing accessible name is the naming rules' decision for the roles that require one. The braille attribute being unpaired is worth surfacing, but it is not itself a criterion failing.
What a finding reports.
attr: the braille attribute that has no equivalent:aria-braillelabeloraria-brailleroledescription.requires: what the element also needs: "an accessible name" foraria-braillelabel,aria-roledescriptionforaria-brailleroledescription.
These data.details fields help to read and reproduce a finding. Apart from reasonCode and the few fields Output schema names as stable, they are not a stable contract: a field may be renamed or dropped in a minor release, so don’t build on them.
Examples
<button aria-braillelabel="SAVE">Save changes</button>
The braille label supplements a real accessible name ("Save changes"); non-braille assistive technology still gets a name.
<button aria-braillelabel="SAVE"></button>
aria-braillelabel is the only naming mechanism present; non-braille assistive technology gets no accessible name at all.
How to check
When this rule can’t decide, it reports cantTell and leaves the question to a person. Each question it can ask is listed here under its reason code, with the steps to answer it. A finding carries the same steps as howToCheck, in the scan’s language. See Output schema.
BRAILLE_ATTR_WITHOUT_EQUIVALENT
- Inspect the element the report names and note whether it has aria-braillelabel or aria-brailleroledescription.
- If it has aria-braillelabel, open the Accessibility pane in the browser's developer tools and read the element's accessible name.
- If the role is one that needs a name (button, link, image, checkbox and similar), confirm that a name exists besides the braille label; with a screen reader in speech, listen for it.
- If it has aria-brailleroledescription, check whether it also has aria-roledescription; if not, confirm the native role is still announced and nothing else was meant.
Pass. The element has a spoken name (and a roledescription where a braille one is given), or its role needs no name and nothing is lost.
Fail. A control or image has only a braille label, so speech users get no name, which fails WCAG 4.1.2.