search

w3c / accname

Accessible Name and Description Computation
https://w3c.github.io/accname/
60 stars 23 forks source link

AccName computation: gap in computation #227

Closed anevins12 closed 5 months ago

anevins12 commented 6 months ago

Description of bug or feature request

It appears that there's a gap in the accessible name computation where authors can implement form controls without accessible names. Please correct me if I'm wrong.

A common scenario that falls through the name computation:

A programmatically associated form control <label> is hidden via CSS visibility: hidden or display: none. As a result, the form control has no accessible name.

<label for="control1" style="display: none"> Search </label>
<input id="control1" type="text" ... />

A scenario that is caught by the name computation:

A programmatically associated form control <label> is hidden via CSS in the same way, but the label is referenced via aria-labelledby:

<label id="control1-name" style="display: none"> Search </label>
<input type="text" aria-labelledby="control1-name" ... />
JAWS-test commented 5 months ago

Does it not belong to: https://github.com/w3c/accname/issues?

And what is the gap? A missing label leads to an element without an accname. That would be an error on the part of the web author. However, a reference via aria-labelledby to an hidden label leads to an accname. This is how it is defined in the specification. If a change in the specification is desired, this could be discussed. However, you should be very careful with this because many existing implementations may then no longer work.

Related: https://github.com/w3c/accname/issues/57

anevins12 commented 5 months ago

Further thought required, I’ll get back to you and read your thread

pkra commented 5 months ago

Thanks for filing an issue. As discussed on today's WG call, closing this in favor of https://github.com/w3c/html-aam/issues/370.