Difference between revisions of "Development:Planning:Focus Chain"
Jump to navigation
Jump to search
(→Issues with tab bar transversal: more conversation) |
(→Issues with content-area tabbing: note about the Gecko pref) |
||
Line 23: | Line 23: | ||
* ideally, even when a page has focusable elements, we should initially set focus to the entire page, not the first form element, so that arrow key scroll, etc., work | * ideally, even when a page has focusable elements, we should initially set focus to the entire page, not the first form element, so that arrow key scroll, etc., work | ||
*: doing that might help with the above | *: doing that might help with the above | ||
+ | * Camino hard-codes the pref value for focus in the content area ({{bug|316339}}, {{bug|277706}}) to "do the right thing" based on user expectation; we currently need to expose UI in the prefs to allow the user to select the [http://kb.mozillazine.org/Accessibility.tabfocus variety of tabbing option desired] ({{bug|277706}}). | ||
===With FKA enabled=== | ===With FKA enabled=== |
Revision as of 16:09, 18 May 2006
Draft of a Focus Chain to fix Bug 152987, Bug 198153, Bug 336949 and Bug 280963
All of these assume a start-point of the location bar, though in most real-world cases we focus the content area (or some part of the Manager) after loading the page/Manager. The chain should pick up from whatever element is focused in those cases, so that auto-focused chains and chains where the user puts focus somewhere behave the same, no matter the starting point.
Contents
Web pages
With FKA disabled
- Location bar (start)
- Search field (if not collapsed)
- Content area (actual initial focus)
- then follow Gecko pref for tabbing/focus within the content area, but don't loop inside the content area
- Location bar (end)
Shift-tab merely reverses the direction of travel.
Issues with content-area tabbing
- Getting from the toolbar to the content area
- smfr mentioned this as a problem; at one point sbwoodside worked around it, which worked but caused Bug 198153
- That no longer works at all; perhaps sbwoodside's hack broke at some point due to autocomplete/child window cleanup? [bet. 2004-06-01 and 2005-01-21]
- smfr mentioned this as a problem; at one point sbwoodside worked around it, which worked but caused Bug 198153
- don't loop in Gecko, which is part of the problem in the current bug
- right now, we don't have a way to tell Gecko where the end is so that we can get back out, if a page has form controls (or you Gecko-pref links); this only works when a page has no focusable elements
- Conrad says we need to do this
- right now, we don't have a way to tell Gecko where the end is so that we can get back out, if a page has form controls (or you Gecko-pref links); this only works when a page has no focusable elements
- ideally, even when a page has focusable elements, we should initially set focus to the entire page, not the first form element, so that arrow key scroll, etc., work
- doing that might help with the above
- Camino hard-codes the pref value for focus in the content area (Bug 316339, Bug 277706) to "do the right thing" based on user expectation; we currently need to expose UI in the prefs to allow the user to select the variety of tabbing option desired (Bug 277706).
With FKA enabled
- Location bar (start)
- Search field (if not collapsed)
- Toolbar buttons to the right of the search field (if any)
- Bookmark Bar first item (if Bookmark Bar is visible)
- Proceeds through the remainder of the Bookmark Bar items; upon reaching the bottom-rightmost item:
- Tab bar first tab (if Bookmark Bar is visible)
- Tab proceeds through the active tabs and down-arrow moves the focus into the content area
- 'or, since the OS tab behavior is different
- Arrows go left/right along the tab bar (activating each tab as you reach it) and tab takes you into the content area
- I think we should do this; it's "cleaner" and how the OS works (and Firefox, but not Safari)
- Content area (actual initial focus)
- follow Gecko pref for tabbing/focus within the content area, but don't loop inside the content area
- Leftmost toolbar button
- Location bar (end)
Shift-tab merely reverses the direction of travel.
Issues with tab bar transversal
- Where does the tab close button fit in the chain? (with either method of transversal)
- They're controls, but they're really not needed with Cmd-W
- Safari includes them, but BonEcho does not
- Window close globes are controls, too, but they're not FKA-focusable, either
- Decision: it doesn't belong in the chain at all
- If arrows cycle between tabs (like in the OS), we have OS consistency but the tab bar and the other toolbars behave differently from each other
- this is logical because 2 are toolbars and one is tabs, but will users realise that?
- AHIG:
- "Pressing the Tab key navigates between controls. Shift-Tab navigates in the reverse direction. The arrow keys provide navigation within controls. In list views, the Right Arrow and Left Arrow keys open and close disclosure triangles."
- If tab moves between tabs and down-arrow brings focus into the content area, shift-tab will still get you back from the content area to the tab bar, but breaks the parallelism
- I.e., normally tab goes one direction and shift-tab reverses; here down-arrow goes the one direction but shift-tab reverses
Issues with content-area tabbing
- See list above
Manager views
With FKA disabled
- Location bar (start)
- Search field (if not collapsed)
- into the Manager
- Manager search field (actual initial focus)
- Manager right (outliner) pane
- Manager left (Collectons) pane
- Location bar (end)
Shift-tab merely reverses the direction of travel.
With FKA enabled
- Location bar (start)
- Search field (if not collapsed)
- Toolbar buttons to the right of the search field (if any)
- Bookmark Bar first item (if Bookmark Bar is visible)
- Proceeds through the remainder of the Bookmark Bar items; upon reaching the bottom-rightmost item:
- Tab bar first tab (if Bookmark Bar is visible)
- See corresponding section in Web pages for order
- into the Manager
- Manager search field (actual initial focus)
- Manager right (outliner) pane
- Manager left (Collectons) pane
- New Collection menubutton
- New separator/folder/etc. menubutton
- Action menubutton
- Sort menubutton
- Leftmost toolbar button
- Location bar (end)
Shift-tab merely reverses the direction of travel.
Issues
- How do you access the menu in the search field (to select the filter type)?
- How do you access the column headings to change sort order or which field to sort upon?
- Or to resize them
- Some things just aren't (can't be) accessible here, just like you can't customize a Cocoa toolbar with a keyboard....
Assorted thoughts
i.e., why we're doing Manager focus this way
- AHIG:
- "In Roman systems, focus always begins at the first field that accepts keyboard input and follows a reading path from upper left to bottom right."
- "Pressing the Tab key navigates between controls. Shift-Tab navigates in the reverse direction. The arrow keys provide navigation within controls. In list views, the Right Arrow and Left Arrow keys open and close disclosure triangles."
- let's make it as useful as possible, while trying (but not religiously) to follow the HIG
- hwaara: are we talking initial focus or just tab order?
- ardissone: both, i think; "focus always begins"...
- ardissone: putting initial focus in the search field makes sense from a practical standpoint
- ardissone: it's hard to argue against that
- ardissone: the problem is, given where we locate that field, it make the subsequent order seem awkward
- ardissone: (at least in terms of getting back up to the toolbar)
- ...
- hwaara: for me the order is not that important, as long as search gets initial focus
- ardissone: if we do a search, then the user is going to want to use those results
- ardissone: so your current order makes sense
- ardissone: search -> outliner -> collections
- ardissone: maybe that's the determining factor, if we accept default focus is the mgr search field