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 jQuery Tabs: keyboard nav conflict ENTER/SPACE on tabs does not make tab active #1760

Closed
nvaccessAuto opened this issue Sep 7, 2011 · 4 comments

Comments

@nvaccessAuto
Copy link

Reported by kevinchao89 on 2011-09-07 02:37
Firefox Nightly 9.0a1 (2011-09-06) and NVDA Main Snapshot 4634

Firefox: http://hanshillen.github.com/jqtest/#goto_tabsdemo-3
2 to go to H2 Tabs, RIGHT/LEFT ARROW to switch among tabs, which does not work, must use pass-through;
ESC to switch to browse mode, ENTER on tab, ESC to switch to browse mode, navigate to next heading, compare focused tab vs selected tab, and notice that nothing was selected;
UP ARROW to tabs, SPACE on tab, ESC to switch to browse mode, navigate to next heading, compare focused tab vs selected tab, and notice that nothing was selected.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh (in reply to comment description) on 2011-09-15 07:28
Replying to kevinchao89:

2 to go to H2 Tabs, RIGHT/LEFT ARROW to switch among tabs, which does not work, must use pass-through;

Is this part of the bug you're reporting? If so, this is correct behaviour: browse mode is meant to browse documents. You should be using focus mode to interact with controls like this using their own keystrokes. This is why enter switches to focus mode; see below.

ESC to switch to browse mode, ENTER on tab, ESC to switch to browse mode,

When you pressed enter, it switched to focus mode and indicated this. This is because NVDA treats this as a control for which proper interaction should be done in focus mode, just as it does for editable text fields, lists, etc. We can change this behaviour to allow enter to activate tabs like we do for radio buttons. I'm not sure whether this is desirable, given the common desire to interact with a tab control using focus mode. Thoughts?

@nvaccessAuto
Copy link
Author

Comment 2 by parham (in reply to comment 1) on 2011-09-15 08:12
Replying to jteh:

When you pressed enter, it switched to focus mode and indicated this. This is because NVDA treats this as a control for which proper interaction should be done in focus mode, just as it does for editable text fields, lists, etc. We can change this behaviour to allow enter to activate tabs like we do for radio buttons. I'm not sure whether this is desirable, given the common desire to interact with a tab control using focus mode. Thoughts?

When using Google AdWords, switching to focus mode automatically happens when encountering tabs at the top of the page. I personally find this very, very annoying. Imagine how bad you would feel if you constantly had to switch to object navigation while browsing a window. Browse mode is only for browsing; focus mode is for interaction with controls. So, to the creator of the ticket, this is really not what you'd want. :-)

JTeh, I'm not slamming NVDA or anything. I know it's because AdWords, like Facebook, is dependant on AJAX, and this usually happens with NVDA while using AJAX-powered websites because Firefox responds slowly to navigation and the sudden change of focus usually activates focus mode. I don't think it's a -fixable- bug in NVDA (in the Google AdWords case) and I was using AdWords merely as an example.

@nvaccessAuto
Copy link
Author

Comment 3 by jteh (in reply to comment 1) on 2011-10-10 23:16
Replying to jteh:

We can change this behaviour to allow enter to activate tabs like we do for radio buttons.

Done in 91e7fd3.

I'm not sure whether this is desirable, given the common desire to interact with a tab control using focus mode.

Focus mode will still be used if the tab control gets focused some other way; e.g. pressing tab. You can still force focus mode using NVDA+space if desired.
Changes:
Milestone changed from None to 2011.3
State: closed

@nvaccessAuto
Copy link
Author

Comment 4 by kevinchao89 on 2011-10-11 10:09
Thanks! Excellent! Confirmed fixed: snapshot main-4720.

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

No branches or pull requests

1 participant