Ticket #1760 (closed defect: fixed)

Opened 6 months ago

Last modified 4 months ago

ARIA jQuery Tabs: keyboard nav conflict ENTER/SPACE on tabs does not make tab active

Reported by: kevinchao89 Owned by:
Priority: minor Milestone: 2011.3
Component: Browse mode Version: development
Keywords: Cc:
Operating system: Blocked by:
Blocking:

Description

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.

Change History

comment:1 in reply to: ↑ description ; follow-ups: ↓ 2 ↓ 3 Changed 5 months ago by jteh

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?

comment:2 in reply to: ↑ 1 Changed 5 months ago by parham

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.

comment:3 in reply to: ↑ 1 Changed 5 months ago by jteh

  • Status changed from new to closed
  • Resolution set to fixed
  • Operating system Windows 7 deleted
  • Milestone set to 2011.3

Replying to jteh:

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

Done in changeset:main,4718.

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.

comment:4 Changed 4 months ago by kevinchao89

Thanks! Excellent! Confirmed fixed: snapshot main-4720.

Note: See TracTickets for help on using tickets.