Suggested simplification #96
Comments
|
I would definitely welcome a re-ordering here since I had to implement it with a There's probably a better implementation possible but for readability alone I'd welcome this change. |
|
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,
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 ]
The text was updated successfully, but these errors were encountered: