W3C home > Mailing lists > Public > wai-xtech@w3.org > October 2007

DHTML StyleGuide Minutes 2007-10-05

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Fri, 5 Oct 2007 20:48:57 +0100
To: wai-xtech@w3.org
Message-Id: <20071005194531.M72760@hicom.net>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:43 GMT