aria-label is used when computing accessible description in Chrome/Firefox/Safari
Step 2C
Otherwise, if computing a name, and if the current node has an aria-label attribute whose value is not the empty string, nor, when trimmed of white space, is not the empty string: If traversal of the current node is due to recursion and the current node is an embedded control as defined in step 2E, ignore aria-label and skip to rule 2E. Otherwise, return the value of aria-label.
Note that it says "if computing a name", which means that this step does nothing when computing a description.
Given this markup:
<div id=x aria-label="foo">bar</div>
<button aria-describedby=x>button</button>
In Chrome and Firefox, when inspecting the button in devtools, has the description "foo". Using the Accessibility Inspector in macOS to inspect the button in Safari, the "Help" property is "foo".
Is the spec wrong, or are the implementations wrong?
Hi, The spec could likely be made a bit clearer on this.
However, the intent is for the algorithm to be recursive in both cases, so that two separate algorithms don't have to be created separately to essentially perform the same action.
So, after aria-labelledby or aria-describedby references a node, the algorithm for that node (referred to as 'current node' in the spec) begins using the same algorithm at the step for checking aria-label, then proceeds down from there until it finds a valid name. Name in this case simply refers to the returned textual string for that step in the algorithm.
Does this help?
I understand that the algorithm is recursive and that the same algorithm is used for both names and descriptions.
The issue is that the spec doesn't match implementations as far as I can tell.
- Removing "if computing a name, and" would fix it.
- If that part is intentional, then implementations should be fixed.
Pick one. 🙂
Thanks, I'll bring this up when we work out the phrasing changes for 1.2. :)
cc @spectranaut