Skip to content
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

Open
stevefaulkner opened this issue Dec 7, 2017 · 6 comments
Open

name from author/content woes #683

stevefaulkner opened this issue Dec 7, 2017 · 6 comments
Assignees
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Milestone

Comments

@stevefaulkner
Copy link
Contributor

stevefaulkner commented Dec 7, 2017

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
Copy link
Contributor

boggydigital commented Dec 11, 2017

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
  1. 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 jnurthen added this to the ARIA 1.3 milestone Sep 27, 2019
@jnurthen
Copy link
Member

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

@JAWS-test
Copy link
Contributor

This question exists not only for td, but for many elements in general: w3c/accname#59

@jnurthen
Copy link
Member

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
Copy link
Contributor

@jnurthen, I agree, therefore I created: #1054

@JAWS-test
Copy link
Contributor

This will probably be solved by w3c/html-aam#160

@jnurthen jnurthen self-assigned this Mar 4, 2021
@jnurthen jnurthen added the clarification clarifying or correcting language that is either confusing, misleading or under-specified label Aug 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Projects
None yet
Development

No branches or pull requests

4 participants