name from author/content woes

[stevefaulkner]

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 spec role=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:

1. <td>content</td> accessible name for the td is "content"

2. <td aria-label="label text">content</td> accessible name for the td is "label text"

Currently browser implementations differ: Safari:

1. no acc name
2. acc name = label text

chrome:

1. acc name = content
2. acc name = label text

Edge:

1. acc name = content
2. acc name = label text

Firefox:

1. no acc name
2. acc name = label text

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

[boggydigital]

In Edge we few specific changes in that area, I'll use your examples to give more details:

1. <td>content</td>
2. <td aria-label="label text">content</td>

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:

1. CT: DataItem, LCT: "cell", Name: "content", IsControlElement: true

   • CT: Text, Name: "content", IsControlElement: false

2. CT: DataItem, LCT: "cell", Name: "label text", IsControlElement: true

   • CT: Text, Name: "content", IsControlElement: false

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.

[jnurthen]

This never got triaged but I do think we need to deal with this better

[JAWS-test]

This question exists not only for td, but for many elements in general: https://github.com/w3c/accname/issues/59

[jnurthen]

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.

[JAWS-test]

@jnurthen, I agree, therefore I created: https://github.com/w3c/aria/issues/1054

[JAWS-test]

This will probably be solved by https://github.com/w3c/html-aam/issues/160