Clarify description computation for aria-describedby

[adampage]

Closes #176.

Added editorial notes to 4.2 Description Computation.

---

Preview | Diff

[JAWS-test]

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]

See https://www.w3.org/2022/11/10-aria-minutes#t07 and #69 (comment)

[adampage]

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]

Would this also need to be changed in item 3 (Host language features) where the phrase "text equivalent computation" is used? It's not clear to me why this one would be specific to name comp, but the latter references T.E. comp.

[cookiecrook]

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

[cookiecrook]

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

[adampage]

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

Done. Thanks, @cookiecrook.

[MelSumner]

👍

[accdc]

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]

@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]

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.

[cookiecrook]

Seems okay to me

[adampage]

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