881869 - Accessible name not exposed for non-interactive list items

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Todd Kloots]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36

Steps to reproduce:

When I toggle NVDA's virtual cursor off, then move focus to a non-interactive list item the text content of list items is not announced, just the control type (e.g. "list item") and position (e.g. "one of three").

Simple repro case:

1. Take the following markup

<ol>
  <li tabindex="0">This is the first tweet</li>
  <li tabindex="0">This is the second tweet</li>
  <li tabindex="0">This is the third tweet</li>
</ol>

2. Startup NVDA and toggle the virtual cursor off

3. Press Tab and move focus between the list items. Notice how the content of the list item is not announced.


Actual results:

Since Firefox doesn't expose a name for non-interactive list items, NVDA cannot announce the content of the list item when the virtual cursor is toggled off.


Expected results:

Firefox should expose a name for non-interactive list items. Or at the very least, non-interactive list items made interactive via the use of the application of a "tabindex" attribute and focus().

Pros:
1. Seems like an obvious win as currently, without a name the user isn't provided with enough information about the current element. And I've always understood that users of screen readers need at least the following pieces of information about a control/element:
- Type
- Label or text content
- State

And with the current implementation, the users only gets two out of three.

2. Saves developers from browser + AT-specific workarounds. For example, my testing indicates that this problem only surfaces in Firefox + NVDA. All other screen reader + browser combinations announce the text content in this scenario. Meaning, in order to fix this on my end I need to:

A. Add the "listbox" and "option" roles to all my lists. (Side note: As the context here is timelines for twitter.com, I don't believe these are even the right roles since I've always understood the "listbox" role maps to <select> and timelines aren't form controls.)

B. Because of "A", VoiceOver won't announce the text content of the list item properly so I now need to add an "aria-labelledby" attribute to the items with a role of "option" to fix that.

Comment 1

[alexander :surkov (:asurkov)]

Another example was: <h3 tabindex="0">some text</h3>

Same time it seems it's not good to expose name in case of <div contentEditable="true">hello a very complex tree</div> which is also tabbable like a @tabindex elements above.

So what a proposal would be?

Comment 2

[Todd Kloots]

Alexander,

It sounds like what's been holding you guys back from exposing the name in such cases is if the subtree is complex it is very expensive to compute the name. Is that right?

If so, how is this not already a problem if the node has an interactive ARIA role applied? For example:

<li role="option"></li> or <div contentEditable="true" role="textbox">

What heuristics do you use in these cases? And can you not apply the same heuristics to solve this issue?

The argument being an ARIA role shouldn't be the sole indicator of interactivity. Especially considering that a role alone doesn't make an element interactive — you also need tabIndex.

If that proposal isn't a workable solution, some other ideas:

1) Announce a subset of the text of the subtree based on what you find to be a manageable balance of performance and accessibility. This way the user is presented with a preview and has the option of entering the element to get more.

2) Limit the computation to descendant nodes of composite elements. For example:
   - You would compute a name for <LI>, but not for <OL> or <UL>

Comment 3

[alexander :surkov (:asurkov)]

Jamie, what do you think?

Comment 4

[alexander :surkov (:asurkov)]

(In reply to Todd Kloots from comment #2)

<div contentEditable="true" role="textbox"> shouldn't expose its content as name because it's exposed as value

> 1) Announce a subset of the text of the subtree based on what you find to be
> a manageable balance of performance and accessibility. This way the user is
> presented with a preview and has the option of entering the element to get
> more.

it's probably a good idea

> 2) Limit the computation to descendant nodes of composite elements. For
> example:
>    - You would compute a name for <LI>, but not for <OL> or <UL>

yep but which ones? what about <h3 tabindex="0"> case?

Comment 5

[Todd Kloots]

I'd exclude elements that are exclusively "containers"— elements with an explicitly defined child type. For example, if you consider the HTML 4 spec, you'd exclude the following:

- table
- dl
- ol
- ul

This way you're only calculating the name for descendant nodes or nodes that are not known container types. 

So, given that logic you would calc the name for <h3 tabindex="0"> since it is not a container and is unlikely to have a complex subtree that would be expensive to calc the name for.

Comment 6

[alexander :surkov (:asurkov)]

cc'ing Mick per Jamie advice.

Comment 7

[alexander :surkov (:asurkov)]

what about <div tabindex="0"></div>?

Comment 8

[Todd Kloots]

For <div tabindex="0"></div> you could either not calc the name unless it has a role, since the subtree could be infinitely deep, or just got with the approach mentioned early of only announcing a subset of its text content based on some perf. heuristics in the interest of giving the user a preview of the content.

Comment 9

[alexander :surkov (:asurkov)]

I'd propose to calculate name from subtree for roles allowing name from subtree in recursive mode only (things like h1) if the accessible is focusable and not editable.

Btw, we expose accessible name from subtree for HTML li already (see original example).

Comment 10

[Todd Kloots]

I like your proposal.

If you expose accessible name from subtree for HTML li already, then I wonder why NVDA isn't announcing it. Any idea what the problem could be then?

Comment 11

[alexander :surkov (:asurkov)]

(In reply to Todd Kloots from comment #10)
> I like your proposal.

ok

> If you expose accessible name from subtree for HTML li already, then I
> wonder why NVDA isn't announcing it. Any idea what the problem could be then?

we need to wait for Jamie or Mick I think but it must be different issue

Comment 12

[James Teh [:Jamie]]

(In reply to Todd Kloots from comment #10)
> If you expose accessible name from subtree for HTML li already, then I
> wonder why NVDA isn't announcing it. Any idea what the problem could be then?
My sincere apologies. This appears to be an NVDA issue; Mozilla does expose the name. The relevant code is from the dark ages of NVDA, so I need to do some detective work to work out why it's there at all. I suspect this bug will probably end up being worksforme, but let me investigate it properly first.

Comment 13

[Todd Kloots]

No problem Jamie, I'm just happy we got to the bottom of this one. :)

Comment 14

[James Teh [:Jamie]]

As noted in comment 9, the test case in comment 0 works as expected. Comment 12 suggests this issue was caused by an NVDA bug. I just tested with NVDA and this works as expected, so even the relevant NVDA bug must have been fixed. :)