- From: David Bolter <david.bolter@utoronto.ca>
- Date: Fri, 07 Nov 2008 14:34:27 -0500
- To: Joseph Scheuhammer <clown@utoronto.ca>
- CC: James Nurthen <james.nurthen@oracle.com>, "wai-xtech@w3.org" <wai-xtech@w3.org>, earl johnson <earlj.biker@gmail.com>
Joseph Scheuhammer wrote: >> > >> > * *Tab* >> > o When on an Accordion Header / Tab, each press of the tab key will >> > move the input focus in the following manner: >> > 1. ... >> > 2. Focus moves to the first interactive element in the Tab page >> > or accordion panel. If the accordion panel for the currently >> > selected accordion header is not visible pressing Tab will >> > cause the accordion panel to expand. >> > 3. ... >> > >> >> Specifically, if focus is on an accordion header, and the associated tabpanel is >> not shown (aria-expanded = false), a Tab keystroke will open the associated >> tabpanel, and move focus to the first focusable item therein. >> >> Note on terminology: "accordion" is a multi-selectable tablist; "tabbed pane" >> is a single-selectable tablist. >> >> After thinking about it, I don't think (2) above is right. When a sighted user >> hits Tab, they usually have some idea of where they are going to end up. They >> can see the next thing in the tab order. If the accordion tabpanel is closed, >> the expectation would be to navigate to the next focusable visible item in the >> tab order. Moving focus to something that is invisible would be jarring (even >> if it's made visible in the process). >> I agree on this point. If the user hits space and expands the panel first, fine, tab can then move to/within the panel, but not otherwise. cheers, David
Received on Friday, 7 November 2008 19:35:02 UTC