764757 - NVDA announces incorrect number of items when display:inline-block; is used

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Isac Lagerblad (:icaaq)]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/16.0 Firefox/16.0a1
Build ID: 20120609030536

Steps to reproduce:

1. Start NVDA (http://www.nvda-project.org/) I used version 2012.2rc2
2. With firefox, Press Cmd+N to open a new browser window, then type http://icaaq.com/sandbox/mozilla/nvda/inline-block.htm in the address bar and press Enter


Actual results:

The second list, with the list-items that has the css property display:inline-block; NVDA announces that the list has seven items


Expected results:

The second list NVDA should announce that the list has four items.

Comment 1

[Marco Zehe (:MarcoZ)]

The first of the two lists shows 4 list item accessibles under the list. The second example shows:

link textnode link textnode link textnode link

For this kind of style, we don't create list item accessibles, and we then count the number of actual child accessibles as the number of items within the list.

I do not know what the visual difference is here, but I suspect we don't behave quite right for display: inline-block; styling.

Comment 2

[Isac Lagerblad (:icaaq)]

> I do not know what the visual difference is here, but I suspect we don't
> behave quite right for display: inline-block; styling.

Visually it looks like every other browser.

Comment 3

[Isac Lagerblad (:icaaq)]

I have updated the url http://icaaq.com/sandbox/mozilla/nvda/inline-block.htm with a display:inline; version, it has the same behavior as inline-block.

Comment 4

[James Teh [:Jamie]]

This is partly an NVDA issue and partly a Firefox issue.

The NVDA bug is that we always use the child count of the list to speak the number of list items. This works with normal (block) list items because Firefox filters out the whitespace nodes between the list items (precisely because they are block elements). For inline list items, this doesn't work because the whitespace nodes are included in the child count. We need to handle this better.

One option is to try to use group position info instead of child count for lists. (This is tricky because the group position info is only on the list items, not the list, and we need the info for the list.) However, for inline-block list items, there is no group position info because Firefox morphs them into paragraph objects. This is the Firefox issue.

Related NVDA issue ticket: http://www.nvda-project.org/ticket/2151

Comment 5

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #4)

> One option is to try to use group position info instead of child count for
> lists. (This is tricky because the group position info is only on the list
> items, not the list, and we need the info for the list.)

Would it be ok if we expose setsize on list similar to what we do for HTML headings (level is exposed only)

> However, for
> inline-block list items, there is no group position info because Firefox
> morphs them into paragraph objects. This is the Firefox issue.

bug 507555

Comment 6

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #5)
> > One option is to try to use group position info instead of child count for
> > lists. (This is tricky because the group position info is only on the list
> > items, not the list, and we need the info for the list.)
> Would it be ok if we expose setsize on list similar to what we do for HTML
> headings (level is exposed only)
That'd be nice, though we can walk into the list if you think this is ugly. Would this get returned from IAccessible2::groupPosition as well? I think that's intended to be only items (not containers), especially given the name "similarItemsInGroup", but we might need clarification on this.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #6)
> (In reply to alexander :surkov from comment #5)
> > > One option is to try to use group position info instead of child count for
> > > lists. (This is tricky because the group position info is only on the list
> > > items, not the list, and we need the info for the list.)
> > Would it be ok if we expose setsize on list similar to what we do for HTML
> > headings (level is exposed only)
> That'd be nice, though we can walk into the list if you think this is ugly.

it seems quite reasonable to ask a container for items amount.

> Would this get returned from IAccessible2::groupPosition as well? I think
> that's intended to be only items (not containers), especially given the name
> "similarItemsInGroup", but we might need clarification on this.

oh, right, iirc similarItemsInGroup == setsize - 1. It doesn't really work. We could go with setsize object attribute though (we expose it on items since ATK doesn't have groupInfo method).

Comment 8

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #7)
> > Would this get returned from IAccessible2::groupPosition as well?
> oh, right, iirc similarItemsInGroup == setsize - 1.
No; they are both equal. My concern was related to where you're supposed to expose groupPosition; I'm not sure whether or not the spec intended it to be exposed on containers.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #8)
> (In reply to alexander :surkov from comment #7)
> > > Would this get returned from IAccessible2::groupPosition as well?
> > oh, right, iirc similarItemsInGroup == setsize - 1.
> No; they are both equal. My concern was related to where you're supposed to
> expose groupPosition; I'm not sure whether or not the spec intended it to be
> exposed on containers.

We can ask on IA2 thread for clarification :) Another question is how do we want to proceed groups within the same container (i.e. when items are separated by separator) and how we want to proceed hierarchical (could be flat) structures.

For example:
<menu>
  <menuitem/>
  <menuseparator/>
  <menuitem/>
</menu>

menu's setsize is 3?

<select>
  <option>
  <optgroup>
    <option/>
    <option/>
  </optgroup>
</select>

select's setsize is 2?

Comment 10

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #9)
> Another question is how do we
> want to proceed groups within the same container (i.e. when items are
> separated by separator) and how we want to proceed hierarchical (could be
> flat) structures.
These are just some of the reasons I don't like the "list with x items" functionality and refuse to add it for other containers. Unfortunately, our users would complain loudly if we dropped that support for lists.

If you do implement this, I think what you've suggested in your examples makes sense. That said, for the reasons you've given, I'm thinking Firefox should not try to implement this, as it's difficult to determine "correct" behaviour in these cases. As much as I hate it, it probably makes sense for us to just special case this for lists in NVDA.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #10)

> If you do implement this, I think what you've suggested in your examples
> makes sense. That said, for the reasons you've given, I'm thinking Firefox
> should not try to implement this, as it's difficult to determine "correct"
> behaviour in these cases. As much as I hate it, it probably makes sense for
> us to just special case this for lists in NVDA.

We need to figure out *wanted* behavior. For example if the user enters into container and he wants to hear something like "entering into list of 3 items, item number 1 in group of 2 items" for the list having 3 items separated into two groups then we can expose that info.

Comment 12

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #11)
> We need to figure out *wanted* behavior. For example if the user enters into
> container and he wants to hear something like "entering into list of 3
> items, item number 1 in group of 2 items" for the list having 3 items
> separated into two groups then we can expose that info.
This particular issue is only related to normal lists in browse mode, which don't have groupings unless done with ARIA. The user just wants to hear "list with 3 items" for the list. (In browse mode, we don't announce position info for items.)

Comment 13

[James Teh [:Jamie]]

Note that we worked around this in NVDA, so this can probably be closed unless we want to fix it for correctness.

Comment 14

[Marco Zehe (:MarcoZ)]

Alex, your thoughts?

Comment 15

[alexander :surkov (:asurkov)]

Can we have a use case (original link doesn't work anymore)?

Comment 16

[James Teh [:Jamie]]

New test case in URL. See the list under the heading "List with CSS display property set to inline"

Comment 17

[alexander :surkov (:asurkov)]

Since container may be an item like flat trees or menus then it'd be good to not use 'setsize' or groupPosition to expose number of items. We can go with object attributes taking into account IA2 provides variant version (i.e. we can return number) and give a name like 'itemcount', benefit is it never gets confused with setsize. How does it sound?

Comment 18

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #17)
> Since container may be an item like flat trees or menus then it'd be good to
> not use 'setsize' or groupPosition to expose number of items.
Can you clarify this? In what cases would using setsize/groupPosition be problematic? Are you reerring to the uncertainty I expressed in comment 6?

> We can go with object attributes taking into account IA2 provides variant version (i.e. we
> can return number) and give a name like 'itemcount', benefit is it never
> gets confused with setsize. How does it sound?
Sounds fine otherwise.

Comment 19

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #18)
> (In reply to alexander :surkov from comment #17)
> > Since container may be an item like flat trees or menus then it'd be good to
> > not use 'setsize' or groupPosition to expose number of items.
> Can you clarify this? In what cases would using setsize/groupPosition be
> problematic? Are you reerring to the uncertainty I expressed in comment 6?

<tree>
  <treeitem aria-level="1">item1</treeitem>
  <treeitem aria-level="2">item1.1</treeitem>
  <treeitem aria-level="3">item1.1.1</treeitem> 
</tree>

so 2nd treeitem is container for 3d item and child of 1st item, thus we cannot use groupPosition/setsize obj attr to expose number of its children on it. Having a different name like 'itemcount' let us to be flexible and avoid possible confusions.

Comment 20

[James Teh [:Jamie]]

Fair enough. I guess I imagined this would only be used on true containers (trees, lists, etc.), not other items, but it could certainly be argued that exposing it on these items does make sense. Also, itemCount is probably just less confusing. I'm happy with that.

Comment 21

[u554753]

This issue is still reproducible. Only works when e10s is enabled.

Steps to Reproduce:
1. With NVDA screenreader on, Navigate to http://oaa-accessibility.org/example/10
2. Focus on the combobox 
3. Press the arrow keys up and down.

Expected Result:
NVDA Screenreader reads <Name of State> (# of #)

Actual Result:
NVDA Screenreader reads "Alabama", "Alaska" and the list is expanded, regardless of what state is chosen.

Comment 22

[Jim Mathies [:jimm]]

Hey Grover - you mentioned "Only works when e10s is enabled." Is that accurate? We're not tracking this bug with a11y work but you are. We need to determine if this is a valid e10s bug.

Comment 23

[u554753]

Sorry about that. Error on Comment 21. This is reproducible with e10s enabled/e10s disabled.

Comment 24

[Jim Mathies [:jimm]]

I'm not able to repo following these steps:

1) load the test page
2) use tab to move focus to the combo box
3) navigate using up/down arrow

Tested with NVDA 2017.3 on Win 7, 64-bit build of Nightly, no issues. NVDA correctly reads the state names in the combo box.

Marco, would you mind testing?

Comment 25

[Marco Zehe (:MarcoZ)]

Note I just tested this with the 56 beta and E10S off, and it works just fine. You have to tab to that combo box, or press Enter on the Application line when virtual buffer is there, and then the pressing of arrows up or down reads the state names, for me they even double-speak.

Comment 26

[u554753]

I'll do a tinytake of the problem. One moment.

Comment 27

[u554753]

Below is a tinytake capture of the problem.

https://ranisharma22.tinytake.com/sf/MTkyMzE0MV82MTIzMTcx

Comment 28

[Marco Zehe (:MarcoZ)]

Sorry, I don't know what you're doing there, and the language is one I don't speak. I hear it repeating the same phrase over and over, but I don't know how you get to that state. I definitely don't see such a bug here.

Comment 29

[Jim Mathies [:jimm]]

Attachment: nvdathing.jpg

Hey Grover, what's this "NVDA Speech" window? I think that's what's causing the overlapping narration. If you get rid of that things work better.

Comment 30

[Jim Mathies [:jimm]]

Hey David, any idea what this window is?

Comment 31

[u554753]

That's the window that always appears when I begin testing with NVDA screenreader. I thought this was default behavior of the program.

Comment 32

[James Teh [:Jamie]]

(In reply to Grover Wimberly IV [:Grover-QA] from comment #21)
> 1. With NVDA screenreader on, Navigate to
> http://oaa-accessibility.org/example/10
> 2. Focus on the combobox 
> 3. Press the arrow keys up and down.

This is a very different issue (and set of steps to reproduce) to the issue described in comment 0. If this is still relevant (and it looks like it might not be as per comment 25), it shuold be filed as a separate bug.

We ended up working around the original issue in NVDA (NVDA issue #2151, commit 8f8563c). While it might still theoretically be nice to do something like comment 17, this is solved as far as users are concerned and I think we have bigger fish to fry. Suggest won't fix.

Comment 33

[David Bolter [:davidb] (NeedInfo me for attention)]

I like to use that NVDA speech viewer window too... it allows me to test speech output with no sound. Grover can you test it without that window showing? (It is an option)

Comment 34

[u554753]

Interesting to note, this issue is also reproducible without the window showing in NVDA and it is also reproducible with the JAWS screenreader, so I will file this as a different bug.

Comment 35

[u554753]

Closing this bug as WFM since the issue was misunderstood. I filed a new bug that involves these new comments as Bug 1398271.