-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
name from author/content woes #683
Comments
In Edge we few specific changes in that area, I'll use your examples to give more details:
Starting with Edge in Windows 10 Anniversary Update we now try to consistently expose anonymous text blocks/inlines (http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level) in the UIA tree as Text elements. With that most of the text that users would perceive visually should be available in the UIA tree for ATs as well. This is pretty close to IE model (it wasn't as consistent though) and a change from Edge before Anniversary Update that only added "interesting" elements and required to use Text Pattern for all other textual content. Now, since Anniversary Update, textual content is available in both the (raw) tree and Text Pattern. For elements that take the name from content we still create UIA Text node, but it's only available in the raw tree, not content tree (IsControlElement = false, IsContentElement = false), so by default for most ATs it wouldn't have any effect on the existing experience. In the two examples you've provided the resulting structure would be just a bit more complex:
please note that the "content" text is available in both cases, and ATs can access it would they have need from the raw UIA tree. Second example was one of the cases we've targeted specifically. If author provided an accessible name, this should be respected and used by default, but one can imagine cases where some additional information present in the text content could be valuable to the ATs - including the cases, were authors provided "bad" name just to suppress the validation tools, for example. In our current design we provide this additional data in a way that doesn't compromise the existing behaviors and still makes this available to the ATs. |
This never got triaged but I do think we need to deal with this better |
This question exists not only for |
Yes - but I don't think it is an accname issue. Accname is defining what the accessible name is being computed as not what its purpose is and whether it overrides the content or not. |
This will probably be solved by w3c/html-aam#160 |
I have been having a discussion with colleagues from freedom scientific about how JAWS should handle the accessible name for
td
elements. This relates directly to ARIA as the HTML acc API spec defers to the ARIA specrole=cell
in respect to implementation.For role=cell it is specified that the acc name is derived from either the content or from the author (via
aria-label
etc.)for example:
<td>content</td>
accessible name for the
td
is "content"<td aria-label="label text">content</td>
accessible name for the
td
is "label text"Currently browser implementations differ:
Safari:
chrome:
Edge:
Firefox:
note: IE11 does its own thing: when content is text only its uses the content as accessible name, when it includes interactive content does not.
A question on the above: when the name is from content should the content or the cell name be announced when the cell receives virtual focus? If its the acc name does that mean in case 2 the cell content should not be announced?
@joanmarie @cookiecrook @boggydigital @asurkov
The text was updated successfully, but these errors were encountered: