241105 - Alt; Ctrl-Tab should enable keyboard access to the first toolbar

Status: NEW

(Core :: DOM: UI Events & Focus Handling, enhancement, P5)

Description

[timeless]

This is parity w/ msoffice (2k+) and visual studio (7+?).

Here's a spec (based on devenv7.1):

1. Alt
1' File menu item is focussed
2. Tab
2' Next menu item is focussed (Edit)
3. Left
3' Previous menu item is focussed (File)
4. Shift-Tab
4' Previous menu item is focussed [wrapping around] (Help)
5. Right
5' Next menu item is focussed [wrapping around] (Help)
6. Down
6' Menu drops down (File), and first item in menu is selected (New)
7. Right
7' Cascading menu opens (New>), and first item in menu is selected (Project)
8. Left
8' Cascading menu closes, and parent menu item is selected (New)
9. Up
9' Previous menu item is selected [wrapping around] (Exit)
10. Escape
10' Menu collapses leaving selection on parent item (File)
--important bits follow--
11. Ctrl-Tab
11' First item in "next"(A) toolbar is selected (New>)
12. Down
[New happens to have a submenu similar to File>New]
12' Menu expands and first menu item in menu is selected (New Project)
13. Right
13' Next button is selected (Add New Item) - this item happens to be disabled. I
suspect it's selectable so that screen readers can tell the user what it is and
that it's disabled.
14. Shift-Tab
14' Previous button is selected (New>)
15. Left
15' Previous button is selected [wrapping around] (this is the customize toolbar
chevron like creature)
16. Enter
16' Submenu displays and first menu item is selected (Add or Remove Buttons v)
-- note that chevron orientation matters --
17. Down
17' Sub menu expands and first menu item is selected
18. Ctrl-Tab
18' First item in "next"(A) toolbar is selected (Start)
19. Enter
19' Button triggers.

*A. the order of toolbars in ctrl-tab/ctrl-shift-tab doesn't seem to make sense
to me. It doesn't match the "order on screen" or in the toolbar list.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.