- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Fri, 5 Oct 2007 20:48:57 +0100
- To: wai-xtech@w3.org
aloha!
a hand-encoded a hypertext version of the minutes from today's meeting
has been archived in the www-archive depository, attached to an
explanatory post -- the direct URI for the minutes is:
http://tinyurl.com/23mtw9
a lynx snapshot of the minutes follows:
--------------------------------------------------------------------------
DHTML Subteam Meeting
5 October 2007
QUICK LINKS (skip)
[Agenda] [Attendance] [Minutes]
_________________________________________________________________
Agenda for 5 October 2007 meeting
1. Continue discussion about Accordion behavior (based on Earl's
posts to wai-xtech)
2. Review Menu after Becky reviews her notes
3. Tabindex and Focus as a discussion is recommended by Becky.
4. Context Help and use cases like prolog.
5. AXS Library
+ consult Chris Blouch's proposal to reserve of some keyboard
space just for web applications
6. Drag-n-Drop
Attendance
_________________________________________________________________
Attendance:
Tom Wlodkowski (TW/chair)
Chris Blouch (CB)
Don Evans (DE)
Becky Gibson (BG)
Al Gilman (AG)
Jon Gunderson (JRG)
Earl Johnson (EJ)
Gregory J. Rosmaita (GJR/scribe)
Rich Schwerdtfeger (RS)
regrets: Chris Blouch
_________________________________________________________________
Minutes: DHTML StyleGuide Call, 21 September 2007
TOPIC 1: Accordion Key Navigation
For Reference:
1) agenda for 2007/10/05 DHTML Subteam Meeting
2) EarlJ's Accordion Keynav Spec
+ BeckyG's Comments on Accordion Keynav Spec
3) EarlJ's Drag-n-Drop Use Cases
+ BeckyG's comments on Drag-n-Drop Use Cases
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
_________________________________________________________________
* meeting adjourned at 16:59 UTC, 2007/10/05
* next meeting: 2007/10/19
Valid XHTML 1.0! (check for yourself!)
Hand-Constructed Using Valid CSS 2.0
Received on Friday, 5 October 2007 19:49:09 UTC