accname
accname copied to clipboard
w3c
Step D needs clarification
Why is [title] mentioned in step D? Title should not be considered until the end of the calculation (step I).
If title were considered at step D for all html elements, that would put title before a name-from-content element's subtree (step F).
Example:
<button title="there">hello</button>
As currently written, the algorithm would produce an accName/accDesc of "there hello".
Real world screen reader testing produces "hello there".
Should title only be used in step D for specific HTML elements, such as an iframe? If so clarification is needed as to what those elements are.
Furthermore, in step D, it would be helpful to have a significant amount of clarification for all native html elements. For example, when a form element has an associated label, should it only grab the innerText of the label, or should the algorithm be treating the label like a name from content element, recursively traversing through the label's child nodes? Also, should the algorithm consider whether the label has an aria-label or title attribute?
I have a similar question regarding Rule D. As I read the current TAN computation the following markup should return ‘Title Text’ as the accName for h1.
Example:
<h1 title="Title Text">
<img src="images/destination.com/image.png" alt="Image Alt">
<div>
<div>Part 1</div>
<strong>Part 2</strong>
</div>
</h1>
Both Chrome and Safari are returning the accName as ‘Image Alt Part 1 Part2” in their respective accessibility trees.
What is the correct calculation of the accName for h1?
Hi, In the case of your H1 code, the accessible name would only be the accumulated names from the inner content, and not the title.
So, accName = “Image Alt Part 1 Part 2”, and accDescription = “”.
The reason being that, the word title in the spec in this context wasn't meant to refer to the title attribute, but rather that of alt text, as noted in issue 10. I'll work on getting that fixed for 1.2 soon.
For future reference, there is a mirror project on GitHub that provides a live executable representation of what we expect the accessible name and description computation to be based on what the AccName spec is meant to replicate within browsers, at https://github.com/WhatSock/w3c-alternative-text-computation
I’ve attached a simple HTML page that you can edit directly to run the AccName Prototype code from GitHub, which includes the H1 code mentioned here. You can modify the code to experiment with different combinations to see how this changes when you activate the “Calculate Accessible Name and Description” button when running the markup in your browser. Just change the file extension to .htm to use this. It doesn’t matter which browser you use to do this, the result will always be the same. Also, since this pulls directly from the GitHub code, it will always represent the latest AccName code, even as updates for 1.2 are worked on in the future.
The attached test page also can be used to run Visual ARIA, which automatically loads the bookmarklet documented at https://accdc.github.io/visual-aria/github-bookmarklet/visual-aria.htm Which is an educational utility for learning how various structural ARIA roles map when used together and when they are interacted with using the keyboard. As an FYI, Visual ARIA attempts to run the same AccName computation as provided within the AccName Prototype, which is shown when mousing over interactive elements, however it may not always be 100% accurate since it uses CSS rendering to display the results, which by their own nature end up changing the accessible name of an element. So treat this Visual ARIA feedback as an approximation if you use this.
That being said, the AccName Prototype itself is meant to be an exact representation of the AccName spec, so if you notice any issues or discrepancies, please let us know as soon as possible so we can correct them.
Also, the AccName Prototype code is open source, so you are welcome to use this within any project you like anywhere for any reason.
All the best, Bryan
Hi, For whatever reason I can't seem to attach a text doc on GitHub, so I've added this live test page in the 'docs' folder in the download at https://github.com/WhatSock/w3c-alternative-text-computation