Skip to content

What is the connection between accessible name and descriptive visual label? #4345

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mbgower opened this issue Apr 17, 2025 · 2 comments
Open

Comments

@mbgower
Copy link
Contributor

mbgower commented Apr 17, 2025

In the comments for #4212 @mraccess77 said"

I'm still unclear from the wording updates if a visual label was descriptive but the accessible name was not descriptive then would SC 4.1.2, 1.3.3, 2.5.3 fail and not 2.4.6? Is 2.4.6 just about visible labels?

This issue will attempt to address/resolve that question.

@detlevhfischer
Copy link
Contributor

detlevhfischer commented Apr 17, 2025

The PR #4212 includes the text

It is possible for controls and inputs to have an appropriate accessible name (e.g. using aria-label="…") and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion (if the label is inaccurate or insufficiently clear or descriptive).

To me that clearly indicates that non-visual labels are as much subject to testing in 2.4.6 as visible ones. Since the issue is the same as with visible labels, I think it makes sense to cover descriptiveness here in 2.4.6 instead of wedging it into 4.1.2. If there is a descriptive visible label with a deviating programmatic label via aria-label, that would certainly fail 2.5.3 and arguably also 2.4.6 since for non-visual users, there would be no descriptive label (I guess even linking via for would be overridden by aria-label). I see no connection to 1.3.3, though.

@mbgower
Copy link
Contributor Author

mbgower commented Apr 21, 2025

@detlevhfischer, the PR does not add that paragraph. It is pre-existing (covered by lines 45-50). All the PR does is some very slight grammatical fixes, and incorporate the notion of "accuracy"

Image

That's why I opened this question as a separate issue; it is not related to the PR changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants