Pressing alt+upArrow on combo box in focus mode bounces back to focus mode if cursor not within combo box

[nvaccessAuto]

Reported by kevinchao89 on 2011-06-30 13:01
Firefox 7.0a1 (2011-06-29) and NVDA Snapshot 4511

http://www.html5accessibility.com/tests/form-test.html

There are a few issues with how NVDA works with html5 form controls.

Datalist: TAB to it or ARROW and ENTER to enter focus mode, arrow to value, and try to switch to browse mode (requires several presses of ESC, where it should require one)

Radiobutton: R to it, status is unchecked, ENTER on it will change to checked (NVDA reports it correctly), but pressing ENTER on it again will not change value to unchecked.

Combobox: C to Combobox, NVDA will read "Select Element, Combobox";
UP ARROW to "type='color'";
DOWN ARROW to combobox;
ALT+DOWN ARROW to expand;
DOWN ARROW to next value;
ALT+UP ARROW to close combobox (NVDA will force combobox to expand) ;
Will have to try ALT+UP ARROW two more times (total of three) to close combobox.
Arrow to it, Expand with ALT+DOWN ARROW, DOWN ARROW to an item, close with ALT+UP ARROW (NVDA will force combobox to expand again)
have to close it several times.

[nvaccessAuto]

Comment 1 by jteh (in reply to comment description) on 2011-06-30 23:47
Replying to kevinchao89:

Datalist: TAB to it or ARROW and ENTER to enter focus mode, arrow to value, and try to switch to browse mode (requires several presses of ESC, where it should require one)

This is because the autocomplete list is a pop-up and isn't really part of the document. This is standard behaviour for such pop-ups, including browser context menus and autocompletes. The first press of escape closes the pop-up, returning you to the document. The second then gets picked up by NVDA.

Radiobutton: R to it, status is unchecked, ENTER on it will change to checked (NVDA reports it correctly), but pressing ENTER on it again will not change value to unchecked.

You can't uncheck a radio button. Once a radio button is checked, you can only uncheck it by selecting another radio button in the same group. This is how the control is designed.

Combobox: C to Combobox, NVDA will read "Select Element, Combobox";

UP ARROW to "type='color'";

DOWN ARROW to combobox;

ALT+DOWN ARROW to expand;

ALT+UP ARROW to close combobox (NVDA will force combobox to expand) ;

Confirmed. Changing summary to narrow scope to this issue with combo boxes.
Changes:
Changed title from "html5 form controls" to "Pressing alt+upArrow on combo box in focus mode bounces back to focus mode if cursor not within combo box"
Milestone changed from None to 2011.3

[nvaccessAuto]

Comment 2 by jteh on 2011-09-02 11:19
When you down arrow back to the combo box, your cursor is not actually on the combo box, but rather, on the text before it. This is why this problem occurs. Alt+downArrow should do nothing in this case, which is what I will implement.

[nvaccessAuto]

Comment 3 by jteh on 2011-09-04 21:35
Damn. Making alt+downArrow do nothing causes the menu bar to appear (because downArrow gets blocked but alt does not). I guess that means we need to move the virtual caret to the focused control instead or change the alt behaviour (though I'm not so keen on that). Thoughts, Mick?

[nvaccessAuto]

Comment 4 by mdcurran on 2011-09-04 23:24
Moving the virtual caret to the combo box is my preference, depending on how hard this is of course.

[nvaccessAuto]

Comment 5 by jteh (in reply to comment 4) on 2011-09-05 03:25
Replying to mdcurran:

Moving the virtual caret to the combo box is my preference, depending on how hard this is of course.

f8f2f5c
Changes:
State: closed

[nvaccessAuto]

Comment 6 by kevinchao89 on 2011-09-06 12:32
Excellent! Confirmed fixed in 4634. This is working very nicely! Thanks!

[nvaccessAuto]

Comment 7 by jteh on 2011-10-07 10:10
2f26412 removes the code introduced in f8f2f5c, as it is no longer required due to a62faa4.

[nvaccessAuto]

Comment 8 by kevinchao89 on 2011-10-08 19:49

This is because the autocomplete list is a pop-up and isn't really > part of the document. This is standard behaviour for such pop-ups, > including browser context menus and autocompletes. The first press of > escape closes the pop-up, returning you to the document. The second > then gets picked up by NVDA.

With first press of ESC closing popup and returning focus ot document, is there any reason that NVDA could not recognize this event change and switch to browse mode, and provide the sound indicating that this change took place? With current implimentation, it's not intuitive and if ESC is pressed rapidly, it could take more than 2 presses to return to browse mode.

Excellent! Confirmed fixed in 4715. original/main issue continues to work very nicely! Thanks!