Suggested simplification

[aleventhal]

So, I'm reading the Chrome code, and looking at 2c-2e and I'm thinking a big simplification would be to reorder it so that the current 2E comes before 2C, then 2D.

Right now, 2C is basically saying, maybe do 2E now if we have an aria-label, and then stop. But if if there is no aria-label, then it will let native markup attributes take precedence over the value. It's very confusing that 2C is saying to do 2E first. So then why do we have that order at all?

It's much simpler and works just as well for any use cases I know of to say: New 2C) If from descendant recursion and labelling another widget, use value if available [ was old 2E ] New 2D) Otherwise, use non-empty aria-label if available [ was old 2C ] New 2E) Otherwise, use native markup if available [ was old 2D ]

[eps1lon]

I would definitely welcome a re-ordering here since I had to implement it with a GOTO essentially (https://github.com/eps1lon/dom-accessibility-api/blob/ccfdd3bc888d4c08cc47f6f540d305eabc83047b/sources/accessible-name-and-description.ts#L581-L586)

There's probably a better implementation possible but for readability alone I'd welcome this change.

[JAWS-test]

This would make a lot of sense, especially since there is currently a bug in the specification that this will fix. Because with 2C there is a reference to 2E, but with 2D there is no reference to 2E. I.e. if I go strictly by the specification,

• for a form element labeled with aria-label I would use the value,
• but for a form element labeled with label I would use the label and not the value, because I would reach 2D first and thus never 2E. This is obviously wrong, because at 2E also label is mentioned

[MelSumner]

@accdc and I have decided to track the prose clarity comments with separate issues (see #125 and #126 ) and move forward with merging this issue and updating existing issues to match the new ordering. Thank you everyone!