GeezerVison

@joanmarie what are the next steps for this one?

@joanmarie what are the next steps for this one?

Group review, including from @accdc who is taking the lead on this spec.

Hi @joanmarie, there should not be a change to the algorithm. When aria-describedby is used, it uses the name algorithm as it stands now to get the text. That algorithm does not consider description markup, it only returns the primary text.

When aria-describedby is not used, then aria-description can be used to set the description. However, aria-description does not affect the recursive algorithm, whether it's used for name or description.

Ok.... Though I still think it's odd that the algorithm for computing the name and description lacks any mention of aria-description. If no one else thinks so.... 🤷‍♀️

Ok.... Though I still think it's odd that the algorithm for computing the name and description lacks any mention of aria-description. If no one else thinks so....

As it stands, we have these 3 headings, which is confusing already:
Accessible Name Computation
Accessible Description Computation (which mentions aria-description)
Accessible Name and Description Computation (reused by the others)

IMO the overlap between these names is kind of confusing already. The last one could be renamed "Primary Text for a Subtree Computation". Then the first two would explain that the Primary Text for a Subtree is used for aria-labelledby and aria-describedby.

But it doesn't make sense to mention aria-description in that Primary Text Computation, because that would change the way aria-description works, which is not desired.

See also #77

The ARIA Working Group just discussed aria-description.

@aleventhal Notes from the meeting bot:

aaronlev: I like that name. "Text Content Computation"
aaronlev: how about if I just expand the current pr to add this?

There was general agreement (not in the notes because the scribe was lagging behind... 😄 ).

I think this is is a step in the right direction, but doesn't solve everything.

In the table, I mention all relevant HTML markup, because currently I think the spec dances around HTML markup, yet seems to desperately want to mention it. HTML should be treated as a first class citizen by this spec, maybe even SVG too. Otherwise it's hard to define an order of markup precedence, let alone which markup should be processed. Getting names and descriptions right in HTML is too important to just hand wave around this.

Hi, I think this is a great step in the right direction. Please merge if you will. We will continue working on the rest as well after.

@aleventhal, many thanks for the comprehensive revision. I think it removes all the ambiguities and errors that were previously contained. In the preview, there is only one problem with the numbering of the list items: instead of letters, numbers are used, so that the references (e.g. "2F.i") no longer work. But maybe this is just a CSS problem of the preview.

The table for description is very good. I just think the first column header is wrong (it should be "precedence" instead of "predence", right?)

@accdc I'm not authorized to merge, unfortunately. Do you want to authorize me or merge?

I'm never going to be as good with github as others here, so if you or Melanie could help with this I'd appreciate it.

From call: Dependent on #433? @scottaohara

Do we intend the aria-description value on an element to be able to be included in its description by a self-reference in the value of aria-describedby?

If so, that does not appear to be supported by the current definition of aria-describedby computation.

If not, we may want to make that constraint more clear. It would make the behavior of aria-describedby slightly different from the behavior of aria-labelledby.

Do we intend the aria-description value on an element to be able to be included in its description by a self-reference in the value of aria-describedby?

I don't think that makes sense. If elements are referenced by aria-describedby, then their AccName is relevant and not their AccDesc. I.e. the AccName of an element becomes the AccDesc of the element which is referred to by aria-describedby. The AccDesc of an element does not matter (whether via title, aria-description or any other method) if the element is referenced via aria-describedby.