Virtual control listing by AT punishing devs: Recommended procedures for identical labels of repetitive content

[stes-acc]

Recommended procedures for identical labels of repetitive content (such as identical “Details” link labels in multiple rows of a table).

Virtual listings of screen readers like Jaws extract label texts from repetitive content (such as identical “Details” link labels or buttons in multiple rows of a table) and present them in their own dialog for instance as link lists with identical label content. As a result, for users and testers all links look similar and they feel WCAG label uniqueness requiremnt violated.

Assistive tech could easily ectract the row info to these and make the labels unique but nobody tells them so. In opposite, cooking recipies exist in Web for authors to add row number info to the labels as hidden additions that the virtual listings in screen readers will get corrected. This puts absolutely UNECCESSARY burden on the shoulders of authors and causes distrust in recommended established labelling techniques, not to mention there is no established pattern recommendation to perform this.

In addition, validators may complain also about identical labels for buttons etc. because this violates the "label uniqueness" requirement of WCAG. Sure this is a WCAG thing but also affects all ARIA label-related properties.

-> Expectation statement regarding exceptions for identical labels or procedures making unique virtual listings of labels in screen readers should be raised by the ARIA group in the respective documents dealing with label-related properties.

[scottaohara]

initial thought is this seems like a feature request for AT / something to maybe surface in the ARIA AT project.

The linked deque university page is about duplicate IDs though, and axe/a11y insights, html validator and ibm's a11y checker doesn't raise any issues about links with the same accessible name in different table cells.

FWIW i think it's a good idea to propose to screen reader vendors to make their listing of elements more contextual, but I'm not sure this would be something needed in any ARIA/HTML spec - what's probably needed here is clarification added to a wcag understanding doc to prevent people from saying things fail wcag when they don't.

[jnurthen]

@stes-acc This isn't an ARIA issue. The exact same thing happens with native tables and buttons/links etc.
Discussions about improving this need to happen with AT directly - the ARIA working group can't really facilitate these discussions as it doesn't really fit into our area.