TW: biggest agenda item is accordion
EJ: assuming people have had a chance to look over updated specification
EJ: also, BeckyG's response
EJ: main areas that are updated; look-over from logical point of view; then Becky's comments, or jump right into Becky's comments
EJ: let me start with an overview of what has changed since last time i brought draft to group
EJ: initial accordion presentation had a high tab confidence -- could use tab to get through all accordion components; no accordion role in sun projects, so no key sequences, preference closer to arrow keys move from tab to tab, tab key gets one into tabpane, if press tab again and no focus, take one out of tab component; changed spec to make arrow keys when focus on pane header, will move user from paneheader to paneheader opening up each's pane content
EJ: arrow keys to move from pane to pane; tab used to get into contents of pane, as well as get out of accordion component itself
EJ: tried to keep close to user experience for tabpane
EJ: questions?
TW: good summation
AG: unlikely to get this role as a separate role into FireFox 3; reason for this in sense that is hard to train people to do model sites -- going to have sites that do real stuff and use this technology to make accessible; want to find out if we can do something that looks and acts like an existing role and property relationship or is there a major gap between accordion and tabs that AT has to know
AG: what's difference and how does user learn difference? can we do with text in labels, or does it need to be machine-communicable stuff that AT announces as widget type X or Y
EJ: don't know that I'm advocating for an accordion role; only difference between accordion role and tabpane is fact that one can have multiple accordion panes open, rather than just one
AG: difference?
EJ: need to have key sequences to open that up; Becky caught that -- way to toggle panes closed as well as open; ENTER different -- Becky?
BG: problem: how do you markup? how to communicate that need to press ENTER to open accordion -- don't do with tabpanel because only 1 can be opened at a time; should we put a state on it, expanded or allowed? separate from key-pressing through title; can we add state to panel?
AG: there is an expanded state
BG: don't think allowed in tab, though
AG: used in trees -- expanded state and multi-selectable; would have to create collection of accordion pane panels -- pane headers
TW: multiple open panes seems disoriented -- use case?
EJ: selection of different types of tools; multiple content areas
TW: what are you doing when pane open - tab limited to only that pane?
EJ: yes; would constrain input focus to those things contained in pane content; collection of TAB navigable elements in pane, TAB until reach last TAB-navigable pane, then leave collection
TW: tab through all open panes?
BG: difference is that arrow would still take from title to title -- some of them would be open
TW: when TAB inside open paneA -- TAB to last element in paneA, what is expected behavior?
BG: next pane header
EJ: yes
BG: then arrow between headers
TW: but panes are open -- can i jump between paneA and paneB -- want to move through content, not first have to go to title; tabpanel returning to panel makes sense, but if multiple accordion panels open simultaneously
BG: want to hear switched panes
TW: can get headers matched up with act itself
BG: going to be quite a long time before screen readers going to support that
AG: are we going to get "owns" implemented? pane header could say that it owns the accordion pane, so when move from pane to another, would check to get the label information from pane header; part of the design -- been engineered for that; working on getting screen readers to do that
RS: could use control to get there, too
TW: control + tab?
AG: like tree structure relationship
RS: also have labelledby -- gets info
TW: why not navigate like a tree? if can open multiple panes -- accordion vertical, tabpanes horizontal -- would be RightArrow and LeftArrow to expand and collapse; if then TAB through elements - go to pane title and have shortcut to get to other open panes -- why using tabpanel as analogy instead of tree?
BG: dojo did it as tabpanel because we only allow 1 open at a time; part of tabpanel
AG: could do with treegrid
BG: another thing dojo doesn't have, but could is menu on titlebar; when navigating from bottom of one pane to another, tab to title, another tab take you to menu and another tab to get into contents; if used CONTROL + F10 might cause conflict -- where would focus be when open with keyboard
TW: my perspective: consumer site developers wouldn't use accordion widget; average user has a lot to encounter and figure out and remember; need to streamline navigation; introducing a lot of keystrokes, so many conflicts between UA and AT -- how many keystrokes left?
BG: one reason to always put focus into title bar, then hit CONTROL + F10 which is standard open menu command
EJ: if want contextual menu, where would focus be -- where popup menu activates, right? wherever focus is, if something attached to it, won't go anywhere
BG: implies allowing context menu only on panel
EJ: don't think so
TW: up and down arrow keys to navigate panels - right to expand
DE: trade-off
BG: dojo tab panel can be vertical or horizontal -- can use left and up or right and down; if can't see, would hear TAB and use left and right, those who can see will want up and down keys
BG: if mark as tree, go with left and right
EJ: that would mean eliminating use of TAB
BG: DownArrow once expanded takes one into content
AG: should take you to next peer (tree item)
DE: down arrow to get into tree items
EJ: seems more complicated than tabpane model
RS: plan to have expand all key assignment for all grids?
BG: doesn't help navigate within accordion to get to contents
EJ: right now, a TAB; if a tree, would have to be an arrow; DonE and TomW's concerns valid, but think need to work on streamlining accordion specific keystrokes; when introduce tree, seems more complicated than taking away the TAB
RS: have each be drop-down buttons and then group them; drop-down, move into container (accordion) with dropdown button
BG: how would user know?
RS: tab goes from button to button
TW: need to communicate to user
RS: ok, popup more accurate than dropdown
BG: popups all have menus
RS: what goes into windows -- help?
EJ: menu type action first
AG: multiple open at once -- creating pallet by opening and keeping open
EJ: usage similar; different context, different set of tools
EJ: a lot like complex grid or tree grid operation -- subgrids that collapse; can put anything in accordion pane, so can have sub-structure if needed
EJ: down does one thing and right another or is down and right synonymous and TAB to move between panels
EJ: : if have multiple panes open and start tabbing? tab will get you out of component once got to end of pane content; if have multiple open, tab can get info from accordion header
DE: instead of tabbing between content in pane, what if treated pane as vertical menu; even if links, could move through -- tab through open panes and title bar, arrows get one through content; on title bar, treat as vertical -- can arrow keys be used to limit amount of tabbing
BG: a lot of work; tabindex issues; if have pane that is live loading dynamically with new content, big performance hit;
BG: capture keystrokes, know order of all focusable items in pane to explicitly set focus for next
AG: inside tabpanel, keys work like expect in UA; don't linearize into menu
EJ: answer is if i keep pressing tab, going to end up tabbing through every single tab-navigatable component before i can get out of panel
EJ: pane content arrow key navigable
TW: stock quotes could be mix of something, but not going to have articles in accordion pane
AG: don't see that at all; what would you use, windows and split-screens; 3 documents each in a panel, want to keep what is merging into one open pane, and comments from others in other panes; each area want to rewrite opens new selection for readers; scrolling through documents -- could be arbitrary tabs between multi-selectable regions
EJ: the issue at the moment is tabpanel only can select one
TW: how do i close from middle of content
EJ: go to header and hit enter
AG: 2 steps -- pop up to header and move to next
BG: can move to another without closing first?
EJ: Control UpArrow to escape
TW: used by screen readers (at least JAWS) to read paragraph
EJ: can turn that off
BG: used ALT + UpArrow -- could capture without conflict
EJ: next question: does specific AT rip out specific keybindings?
EJ: question brings up another thing -- how do you get out of starting point quicker; if in pane content, keep using LeftArrow, then TAB to get out of component; would actually take you to next pane level
BG: header on accordion itself adds to confusion -- not extant in tabpanels; have panes and header for all panes
EJ: : node in a sense a header too
BG: no, just first pane -- last active pane or tab is put into tab order
EJ: have to give focus to something to expand it
BG: button, too, right
EJ: yes
EJ: don't see headers as real problem; control of another region -- 2 widgets -- one placed first has "expandall" "collapseall" -- controls accordion/pane -- should get users info necessary to know what is going on
BG: tab to accordion header from first active
EJ: yes
TW: if in title pane, but in container's top layer, how to determine all available choices
EJ: widgets should communicated this
BG: thought we were arrowing through title of each individual pane with RightArrow and LeftArrow
AG: buttons in top level of global header
EJ: global header is accordion header -- would use TAB
BG: might mark as toolbar
TW: arrow across tab titles
BG: this is a header that goes above all -- may have buttons -- expandall, collapseall, etc.
EJ: could be buttons or menu
EJ: Becky has good idea
TW: second layer accordion content titles and pane titles -- why not take layer 1 and merge with layer 2 -- what is available via top header other than expandall/collapse all
BG: may have menu -- such as "set time zone" -- a dropdown menu
TW: if develop web app for time zone, couldn't i put in second layer
AG: cognitive problem -- if can see "tableness" can take that action
EJ: conceptually orthogonal
EJ: time check - 15 minutes left - how to wrap up; make top arrowkey navigable, tab down to pane level, then arrow through pane content, if want to jump into one, use TAB or ENTER; focus would stay on pane header -- if hit enter twice, will collapse it
EJ: tab only way to get focus to pane content
TW: JRG or GJR -- comments?
GJR (via IRC): I'm on mute
TW: how do you know to expand whole thing?
EJ: through a global function
RS: no role for that -- need role for that type of group
EJ: key sequences attempted to keep close to tabpane model; difference is ENTER to toggle open/close pane; tried to make similar to tabpanel
AG: control to open -- label on button tells one what has been done; in accordion header, expandall and collapseall examples of functions, not bound to hot-keys, can be inside pane and expand/collapse
EJ: developer can put expand all and contract all wherever wants to
AG: have to have widget -- same way that ChrisB registers hotkeys so can be explained to user
TW: can someone provide an example coded up with top level arrowable and second level tab-able?
EJ: will have basic example with which i can check out keyboard navigation -- will put online too; once have that out, work with subteam -- hope to have simple prototype by next meeting
TW: want example to allay lingering concerns -- maybe when can interact with something, can determine right implementation
EJ: accordion header top level; title and contents second and third layer?
TW: yes
PROPOSED RESOLUTION: global header and accordion content title areas navigable like treebar; once open move through open pane
EJ: let me think more about having multiple panes open
RS: sounds like need a different role for this thing, right?
EJ: hoping that tabpane will be close enough with additional markup to make clear not a tabpane, but accordion pane
RS: user will want to have key sequences identified; without telling them accordion, may not know all of this
TW: have to get idea of 3 layers and tying them together
AG: matter of what user will expect from certain key, or told that are in a special mode and use navigation conventions for that mode
AG: can we provide a key that goes from anywhere in pane content to header for that pane; TAB not only way to go between layers; way to go up without TAB?
TW: only way to get away from widget may involve a LOT of tabbing
RS: going to be discussing on ARIA call on monday morning (10am EDT) -- can EJ, DE, and TW attend?
TW: drag-n-drop on same level as accordion
RS: nothing new except cut-and-paste to clipboard which is different
TW: discussion about drag and drop?
RS: on ARIA Best Practices wiki
RS: good feedback from EarlJ that i folded into Best Practices document
[JRG leaves]
AG: EJ, you and Rich will work on that?
EJ: yes; thanks for feedback
TW: touch base monday?
EJ: monday good