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

ARIA Tabs not accessible as forms controls #10432

Closed
n-chardon opened this issue Oct 28, 2019 · 7 comments · Fixed by #10438
Closed

ARIA Tabs not accessible as forms controls #10432

n-chardon opened this issue Oct 28, 2019 · 7 comments · Fixed by #10438

Comments

@n-chardon
Copy link

n-chardon commented Oct 28, 2019

ARIA Tabs are not accessible using the shortcut "F" or in the lists of form fields.

Steps to reproduce:

Open in either Chrome or Firefox the following page :
https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-1/tabs.html

Actual behavior:

Tabs are not accessible using the shortcut "F" or in the lists of form fields

Expected behavior:

Tabs are focused with the "F" key and are listed in the form fields

System configuration

NVDA installed/portable/running from source:

NVDA installed

NVDA version:

2019.2.1

Windows version:

Windows 10 version 1803 - OS Build 17134.1069

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

Firefox 69.0.3 64 Bits (FR-fr locale)
Chrome Version 77.0.3865.120 (Official build) (64 bits) (FR-fr locale)

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? If so, please report their behaviors.

No

@LeonarddeR
Copy link
Collaborator

I think this makes sense. Marking this good for new dev. The places to be are:

  • Gecko_ia2._searchableAttribsForNodeType
  • mshtml._searchableAttribsForNodeType
  • UIABrowseModeDocument._iterNodesByType

@JulienCochuyt
Copy link
Collaborator

JulienCochuyt commented Oct 29, 2019

I already have a few things ready in this scope. I might try to file a PR quite soon.
My concern is not much technical (the implementation is, as you wisely noted, quite simple) but rather ergonomic: Tab headers and panels are quite specific controls/containers.

For one thing, we believe (here at Accessolutions) that, despite past counter-arguments, tab panels should be considered as containing-regions: (shift+)comma would move to their boundaries, but navigating in/out-side of them would also be announced.

Also, we'd need to have a way to announce the current tab when in a panel.
We've thought about adding the info to what is reported by NVDA+tab, but this would limit to cases where the focus can indeed go inside.
For WebModules, we usually add this info to what is reported by NVDA+t, but many could argue this is just a hack.

Related: How should we handle moving from inside the panel back to the selected tab header?
If we stick on "f" for tab headers, we could consider to target the selected tab rather than the first/last.
Then, a solution could be: first press shift+comma to move to the beginning of the panel then press shift+f to reach the selected header.

What do you think?

@n-chardon
Copy link
Author

n-chardon commented Oct 29, 2019

In JAWS, all tabs are exposed via the "F" shortcut; but the selected one is not announced (which is an issue). Since tab selection behaves like radio button selection, I think each tab should be accessed via the "F" key, like with radio buttons: wether the current tab is selected should also be announced.

@JulienCochuyt
Copy link
Collaborator

In JAWS, all tabs are exposed via the "F" shortcut; but the selected one is not announced (which is an issue). Since tab selection behaves like radio button selection, I think each tab should be accessed via the "F" key, like with radio buttons: wether the current tab is selected should be announced.

I'm glad you mention radio buttons, as I feel there handling can at times be problematic too.
Quick nav considers all items, while tab only stops at the first/last one.
I really feel that tab headers lists and radio buttons groups should both be handled by quick-nav as a whole: When jumping to the whole, the selected item if any should IMHO be the one we reach.
When there are numerous elements in the list, it can be tedious if not error prone to find the selected one - especially as we do not currently have a quick-nav toward it.
Tab headers lists are easier to handle in that respect than radio buttons groups are as, if i'm not wrong, there always ought to be a selected tab header within the list.

Please also see #9227 (comment) for related considerations.

@JulienCochuyt
Copy link
Collaborator

Pushed for now PR #10438 that only includes tab headers when quick navigating by form fields with "f".
Let's already do that and consider the rest on dedicated threads.

@n-chardon
Copy link
Author

Thank you for the quick changes! As far as I am concerned, it is just what I wanted. Many thanks!

@nvaccessAuto nvaccessAuto modified the milestone: 2020.4 Oct 13, 2020
@kara-louise
Copy link

Would it be possible to also have a key in browse mode to jump to the next/previous tab? I'm not sure which key would make sense as T, A and B are already assigned. Maybe Y as it's central and currently unassigned by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants