In one paragraph
ARIA braille attributes must have a non-braille equivalent means specialised braille output should supplement an ordinary accessible name or role description, not replace it. Verify the normal semantics first and use overrides only for a genuine braille-specific need. The supplied WebAuditOS integration does not surface this rule's review results as findings, so no report entry does not establish that these attributes are correct.
Why it matters
Braille-capable assistive technology can normally translate an element's accessible name without a special author override. A separate braille label can be useful when the usual name produces an unsuitable representation, but arbitrary abbreviation can discard information or interfere with user translation settings.
aria-braillelabel changes the intended braille representation of a name; it is not a replacement name for speech or every other consumer. aria-brailleroledescription similarly concerns specialised role wording and needs an appropriate ordinary role-description counterpart.
Do not add these properties simply because an audit vocabulary mentions them. Most controls need a clear ordinary name and correct role, not multiple redundant versions. Their support and the user's braille settings require real evaluation rather than assumptions based only on a string parser.
How WebAuditOS evaluates this finding
The supplied aria-braille-equivalent rule checks for an ordinary accessible name alongside a non-empty braille label and for a non-empty aria-roledescription alongside the corresponding braille role description.
The source states that problematic cases are returned for review, not as violations, and the report keeps violations only. It therefore raises no finding from this rule under the documented configuration. Its nominal serious impact is not an actual high-severity report entry here. Verify execution and output handling before describing current product behaviour.
How to fix it
- Find all uses of the two braille-specific attributes in source and rendered components. Determine why each exists, who approved its wording, and which supported assistive combinations have been tested.
- Inspect the ordinary accessible name and role first. Fix missing or misleading base semantics through the appropriate native or ARIA mechanism before evaluating an alternative braille representation.
- Keep a braille override only where the normal name does not provide the desired braille experience. Do not duplicate aria-label mechanically or replace descriptive information with unexplained symbols merely to save cells.
- Use appropriate localised human-readable content and meaningful equivalence. Specialist review may be needed for abbreviations, units, scores, or Unicode braille patterns. A short string is not automatically easier to understand.
- For braille role descriptions, verify the ordinary aria-roledescription exists and is itself appropriate for a meaningful semantic role. A second custom phrase cannot repair an inappropriate underlying widget model.
- Test the actual supported speech and braille experience with relevant user settings where feasible. Do not assume a developer's speech-only screen-reader check verifies the braille variant or its translation behaviour.
- Check repeated components and changes of language, value, or task. Updating one representation without the others can create divergent messages for different users.
- Record manual review and retain it in the maintenance workflow. Rescanning other naming checks is useful, but the supplied report's silence on this rule is not evidence of equivalence.
What the fix can break
A specialised label can remove context, obscure an action, or confuse a person's chosen braille translation. Use the ordinary accessible name whenever it already provides a good result.
Do not put a live changing value into a permanent label unless the information model actually requires that wording. Keep name, role, value, and descriptions conceptually distinct.
An ordinary role description can itself reduce clarity by replacing familiar terms. Review whether either custom description is needed before maintaining two versions of an unnecessary override.
Questions
Must every control have aria-braillelabel?
No. The ordinary accessible name is usually the appropriate source for braille translation. Use an override only for a justified need.
Does a braille label name a control for speech too?
Do not rely on that. Preserve a correct ordinary accessible name independently.
Why is no finding not a pass here?
The supplied integration omits this rule's review results from its violations report.
Which related checks help?
Review role descriptions, button names, and the automation limits guide.
What severity does this get in the report?
None - it does not appear. Severity for an axe finding comes from the impact axe reports for the element that failed, and axe declares this rule serious, which we would map to high. But axe returns this rule's failures as "needs review" rather than as violations, and our report only lists violations, so there is no finding to grade.