search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.1k stars 634 forks source link

Sequence of tab items in tablist not read out in browse mode #9296

Open ydogandjiev opened 5 years ago

ydogandjiev commented 5 years ago

Steps to reproduce:

  1. Open tab sample here: http://accessibility.athena-ict.com/aria/examples/tabpanel2.shtml
  2. Click on the "Prices" tab to select it
  3. Switch NVDA into browse mode (Insert + Space)
  4. Press the Down Arrow key, observe read out --> "Tab Features"
  5. Press the Up Arrow key, observe read out --> "Tab selected Prices"

Actual behavior:

In browse mode NVDA reads out "Tab Features", "Tab selected Prices", omitting the sequence information - i.e. "1 of 2", "2 of 2".

Expected behavior:

Full tab sequence information is read out in browse mode - i.e. "Tab Features 2 of 2", Tab selected Prices 1 of 2".

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2018.4.1

Windows version:

Windows 10.0.17134

Name and version of other software in use when reproducing the issue:

Chrome 72.0.3626.109

Other information about your system:

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

No

ehollig commented 4 years ago

I think this was discussed in another issue. Does anyone know why the announcement differs in browse mode and focus mode? In focus mode, it announces the number of items in the tablist, but is not announced in browse mode.

Adriani90 commented 4 years ago

I don't know exactly why this is not part of the virtual buffer used by NVDA, it seems element count in general is not used in browse mode but only in focus mode. @michaelDCurran is there are specific reason why NVDA treats this in focus mode and browse mode differently?

gencay commented 3 years ago

resurrecting this thread to see if this is a feature or a bug with NVDA browse mode @michaelDCurran

Adriani90 commented 4 months ago

I think there is no way we can programatically count these elements in browse mode if theyr count is not exposed via accessibility API. @jcsteh is this correct?

jcsteh commented 4 months ago

The count is exposed. Browse mode is just choosing not to use it.

Whether to do that is tricky. Imagine reading navigation bars on the web in screen layout if we reported element counts:

list with 3 items link Home 1 of 3 link About 2 of 3 link Download 3 of 3

That is ridiculously verbose. The key point is that content is more likely to be read continuously in browse mode, whereas in focus mode, users tend to navigate and ignore suffix information more readily.

Adriani90 commented 4 months ago

Maybe it makes sense to enable reporting of count elements in browse mode only when pressing the quick nav key? I can imagine this could be useful for checkboxes, radio buttons, tabs, menu itens and list items. People can now assign quick nav keys for menus and tabs as well.

jcsteh commented 4 months ago

NVDA treats quick nav like focus for the most part, so this seems reasonable to me from a UX perspective.