Clarify description computation for aria-describedby

w3c / accname

Accessible Name and Description Computation

https://w3c.github.io/accname/

61 stars 23 forks source link

Clarify description computation for aria-describedby #177

Closed adampage closed 1 year ago

adampage commented 1 year ago

Closes #176.

Added editorial notes to 4.2 Description Computation.

Preview | Diff

JAWS-test commented 1 year ago

I suspect your change is wrong and has nothing to do with what was discussed:

your change, if I understand correctly, prohibits me from referring to the own element via aria-describedby. This should not be forbidden and was not so far
It was discussed that aria-description doesn't matter when referring to the element with aria-description via aria-describedby. The AccName and not the AccDesc of the element referenced by aria-describedby does matter (because aria-labelledby and aria-describedby work the same).

JAWS-test commented 1 year ago

See https://www.w3.org/2022/11/10-aria-minutes#t07 and https://github.com/w3c/accname/pull/69#issuecomment-1302483079

adampage commented 1 year ago

I understand now. 🤦🏻‍♂️ Thank you for setting me straight, @JAWS-test. This is particularly embarrassing because I scribed that Nov 10 meeting. My brain was apparently not in attendance.

Assuming that I do actually understand now 😅, it seems like this simple replacement of “Text content computation” with the more specific “Name computation” would be sufficient?

cookiecrook commented 1 year ago

(E.g. line 247, just below this diff boundary)

adampage commented 1 year ago

I think the answer is yes, so I'm changing my response from "Comment" to "Request Changes."

Done. Thanks, @cookiecrook.

accdc commented 1 year ago

Hi, I've been rereading this issue and am confused because it seems to flip back and forth. Is the purpose to prevent self-referencing by aria-describedby but not for aria-labelledby?

I have seen this used successfully on tables that have checkbox or radio button controls that will reference the parent row using aria-describedby to announce the full content of the row being selected when the screen reader is interacting with it, and this is quite helpful.

Would this change prevent something like this from working?

cookiecrook commented 1 year ago

@accdc wrote:

Hi, I've been rereading this issue and am confused because it seems to flip back and forth. Is the purpose to prevent self-referencing by aria-describedby but not for aria-labelledby?

I have seen this used successfully on tables that have checkbox or radio button controls that will reference the parent row using aria-describedby to announce the full content of the row being selected when the screen reader is interacting with it, and this is quite helpful.

Would this change prevent something like this from working?

If you're referring to the note @jnurthen and I were discussing in the thread, no, it won't prevent anything from working. It's just informative authoring guidance.

If "this change" is referring to something else, I would need a more specific reference.

adampage commented 1 year ago

I’m inclined to limit this PR to clarifying that aria-describedby’s computation should only gather the accessible name(s) of the referenced node(s), not their accessible descriptions. I’m to blame for misinterpreting the original consensus to begin with. 😣 If we think there’s merit to discouraging a node from describing itself, how about tackling that as a separate issue?

In the meantime, I’ve committed your suggested reversion, @cookiecrook. I also created a quick Codepen to examine aria-labelledby, aria-label, aria-describedby, and aria-description, in case it could be helpful in follow-up discussions.

adampage commented 1 year ago

Thanks very much, @cookiecrook. I believe this is ready for merge, @spectranaut / @jnurthen / @pkra?