Draft Minutes of DHTML Subteam Meeting 29 June 2007

aloha, all!

apologies to participants whose participation i didn't log, and for 
any misattributions or mistakes in the minutes -- as usual, send 
corrections to wai-xtech@w3.org by replying to THIS emessage.



                                   - DRAFT -

                      DHTML Subteam Meeting 29 June 2007

29 Jun 2007

   See also: [2]IRC log


          becky_gibson, tim_??_from_google, tom_w_(AOL), earl_johnson,
          gregory_j._rosmaita, jon_r._gunderson

          Tom Wlodkowski

          oedipus, Gregory J. Rosmaita


     * [3]Topics
     * [4]Summary of Action Items

   <oedipus> Agenda 1: Discuss additional comments on tab panel.

   <oedipus> Agenda 2: Keyboard behaviors for tree views.

   <oedipus> Agenda 3: Discussion of radio buttons (time permitting) The
   issue of radio buttons was raised on the last call.

   <oedipus> TW: tabpanel?

   <oedipus> Becky: escape dangerous if a delete - people instinctivly
   try escape

   <oedipus> TW: retain context menu, should there be a shortcut key to
   make it happen

   <oedipus> Becky: both

   <oedipus> TW: have a context menu only way to do this, right?

   <oedipus> Becky: talked about this in dojo - context menu somewhat

   <oedipus> JG: ARIA property deletable

   <oedipus> Becky: please provide info

   <oedipus> TW: have to have context menu- might want to close, not
   delete - could be session based - lot of issues around task

   <oedipus> Becky: how does close differ from delete?

   <oedipus> TW: in radio application - today don't use; 2 weeks later do

   <oedipus> Becky: add back

   <oedipus> JG: restore all tabs perhaps needs to be added to tabpanel -
   store all tabs, store deleted tab - delete this tab, but keep title

   <oedipus> Becky: more in implementation-shouldn't require restore; UI
   issue -- pizza application - don't llike meat, get rid of meat tab,
   never want to see again

   <oedipus> TW: context menu not discoverable; tabpanels with tabs being
   taken out of the panel - no property to communicate focus - haspopup
   role for ARIA - shift-F10 or some keycombo to invoke it - have delete
   work when not discoverable strange to me

   <oedipus> Becky: fear is don't have indication deleted - focus just
   guiven to something else - context menu get focus on tab, has popup,
   hit keycombo, going to delete and give focus to

   <oedipus> GJR: bidirectional communication needed between app and AT

   <oedipus> Becky: deleted ok, but not contextmenu - delete in style
   guide except have to have context menu

   <oedipus> Earl: how about instead of delete, something closer to what
   would perform on desktop window; alt-4 dismisses window; control-F4
   might perform corallary action of dismissing tab; don't know if delete
   field good for dismissing a tab;

   <oedipus> TW: good point - removing tab; might say, we allow
   implementation of a keystroke, but today, only way anyone knows about
   keystroke is context menu - deletable or closeable, whatever called
   still going to have context menu

   <oedipus> Earl: define delete as action, now in style guide?

   <oedipus> TW: control-F4 better

   <oedipus> Becky: can we catch that; can't catch all keystrokes in

   <oedipus> TW: counterpropose that instead of delete use keycombo

   <oedipus> JG: control should be on each tab

   <oedipus> Earl: does control-F4 close window in FireFox?

   <oedipus> JG: closes tab by default in FireFox; control-PageDown

   <oedipus> Becky: can catch onkeypress but not onkeydown for Control
   PageDown and Control PageUp

   <oedipus> JG: Firefox or IE or both

   <oedipus> JG: using keypress to capture control pageup control

   <oedipus> Becky (investigating as speaking): don't think i can catch

   <oedipus> Becky: with onkeypress goes away

   <oedipus> JG: keycode for F4?

   <oedipus> Becky: can't catch it; trying to stop event

   <oedipus> Becky: only issue is can we catch it or not

   <oedipus> TW: options other than DELETE - CTRL+F4 a possibility, have
   to get comments on that - what we are saying is context menu and
   keyboard shortcut combo fine - great if had property so didn't have to
   use context menu, but maybe that's phase 2

   <oedipus> Becky: need to update test - not currently including F4

   <oedipus> RESOLVED: more due dilligence required to determine

   <oedipus> RS: find ideal keystrokes for BrowserX? or universal

   <oedipus> JG: did capture F4 onkeypress in firefox - keycode 115

   <oedipus> Earl: will browser folks change key sequences

   <oedipus> JG: consensus is that if in tabpanel, and conflicts with
   browser keystroke, tabpanel takes precedent

   <oedipus> TW: widget wins, but where we know there are known conflicts
   with browsers, will try to define non-conflicting keys

   <oedipus> Becky: last meeting control pageup and control page down

   <oedipus> JG: control+shift+?

   <oedipus> TW: conflicts with browser tab shifting

   <oedipus> Earl: control tab must be the one -- needs to be stressed in
   style guide;

   <oedipus> TW: if widget wins, then can use Control+PgUP and
   CTR+PgDown; style guide difficult because of implementation problems;
   if widget wins, can take all desktop widgets across the board; find
   out when can't capture keys, then avoid use

   <oedipus> Earl: review where headed?

   <oedipus> TW: widget wins, but where there are inherent keystroke
   conflicts, should avoid using them

   <oedipus> TW: moved to next mutually supported keystrok

   <oedipus> Earl: do we consider the browser is still the question

   <oedipus> JG: can't have best practices guide that outlines strategies
   that don't work

   <oedipus> Becky: what if entire page is tabpanel - how will user get

   <oedipus> JG: tab out of page

   <oedipus> TW: 2 pages loaded - one tabpanel, one newsarticle; can
   control-tab between 2 pages, what happens?

   <oedipus> Becky: wouldn't be able to capture tabpanel widget in

   <oedipus> TW: would break browser experience; know broken in that
   regard; can't have both scenarios supported, so we do need to define
   widget so supports conventional desktop widget behaviors if possible;
   if already used for legitimate purpose, need alternate such as CTR
   PgUp and CTR PgDown

   <oedipus> GJR: 3 levels of granualarity - at, ua, widget

   <oedipus> JG: are menus the fallback

   <oedipus> GJR: not necesarily

   <oedipus> JG: browser going to win some places not in others; more
   ecclectic in terms of people's knowledge

   <oedipus> Earl: conteragrument - model used / learned to interact with
   browser now better than desktop

   <oedipus> JG: application winning provides user with opportunity to do
   something; can always get out of a document by requesting new URI; if
   browser wins

   <oedipus> GJR: three tiered - widget, at, browser

   <oedipus> JG: those who can't use mouse with sight;

   <oedipus> can't minimize - mouseclicks - can't avoid - style guide
   needs to recommend what we believe is best, running into a world where
   learning curve is steep to begin with

   <oedipus> Earl: thought just came to mind, might make job easier and
   curves less if browser pane acts like desktop apps - but then run into
   browser problems - need a toggle to find an application - like JAWS'
   virtual cursor mode, web application navigation mode - webpane then
   acts like desktop; UA has multiple tabs open could toggle out of
   application navigation mode, switch to native apps navigation mode,
   then reenter application navigation role either automatically o

   <oedipus> TW: enable appllication keyboard control would inherit
   desktop behaviors for widget

   <oedipus> Earl: widgets that are like traditional desktop widgets, if
   user could interact with the dojo widget in the same way they interact
   with desktop widgets; problem conflicts with browser - like control
   tab needed within UA UI; current scenario, always have to consider how
   browser acts - toggle that puts you into application navigation mode
   so that the browser content wins, when using control tab would act on
   dojo tabpane widget, but not UA tab pane, if want to w

   <oedipus> Becky: know what has focus know what has control, but don't
   know who's controling

   <oedipus> Becky: don't know if a HTML button element or a dojo widget

   <oedipus> Earl: good point; mixture of widgets and standard HTML

   <oedipus> Becky: similar to going in and out of virtual buffer mode;
   have to be out of virtual buffer mode to interact with widgets in
   screen-reader, now adding same issue for sighted keyboard user -- need
   the concept of a buffer

   <oedipus> Earl: strike my prop, then

   <oedipus> Becky: ARIA property only goes on body - for SR forces into
   virtual buffer need to go in and out of buffer

   <oedipus> application inside IFrame -- don't have control over what
   developers going to do; not going to get all devs to follow one
   solution, what need to be mindful of is if come up with best
   practices, hopefully implementors going to say we can do this

   <oedipus> JG: this is the right way to do it -- that's the ah-hah we
   need to get from devs; makes most sense; don't know if can do

   <oedipus> Earl: does browser win or no?

   <oedipus> JG: if i am web app dev i want my app to win, not UA; that's
   my persepective as developer; make it easier for me, not UA dev

   <oedipus> ??: not sure can move forward with style guide in this

   <oedipus> Becky: most devs don't even care what keyboard does; doesn't
   enter thought proccess for the most part; their app wins because they
   are using a mouse - can go anywhere and activate anything with mouse

   <oedipus> ??: browser must win for now

   <oedipus> TW: toggle between tabpanels and UI tabs - disclaimer for
   keystrokes - could prevent ability of users to change focus / web page
   in BrowserX version y, Browser Y version x

   <oedipus> Earl: whatever way is done first time will be way done
   perpetually; best practice no sense if browser wins - if let win now,
   will win forever

   <oedipus> TW: is there a way through here - control tab controlshift
   tab works on JAWS example today, when focus not in widget overrides

   <oedipus> JG: can't see how can't have web app win in this situation

   <oedipus> RS: is it our option that widget wins?

   <oedipus> JG: can't get keystroke, can't cancel; if process keystroke
   according to W3C DOM, can cancel

   <oedipus> RS?: is possible for us to programmatically win

   <oedipus> Becky: in most cases

   <oedipus> TW: confused - going round in a circle

   <oedipus> Becky: last week decided specific keystrokes

   <oedipus> Becky: concerned about being trapped in widget; especially
   if tabpanel only thing on page;

   <oedipus> TW: if trapped on widget, should be able to arrow out -
   maybe can start to explore widget winning

   <oedipus> Earl: let's go back to browser not winning

   <oedipus> GJR: agree

   <oedipus> TW: agree

   <oedipus> TW: if browser doesn't win, can use control-tab and
   control-shift-tab; tree left and right to expand/collapse

   <oedipus> GJR: good, if as earl says, reuse keyboard behaviors for
   desktop widgets as much as possible, lessens gradient of steepness of
   learning curve

   <oedipus> TW: what do we need with tree?

   <oedipus> Becky: left arrow twice, you can end up on parent

   <oedipus> Becky: on my wiki, not on ARIA wiki; al gilman has action

   <oedipus> Becky: open, then go to next visible node; only ONE tab
   active in tree, and that is current focus

   <oedipus> Earl Johnson needs to leave call

   <oedipus> TW: tab key moves to tree, next tab moves away, when tree
   has focus, left and right arrows should expand/collapse

   <oedipus> TW: what about radio button issue?

   <oedipus> JG: default behavior of UA when radio button not explicity

   <oedipus> Becky: detect browser and then deliver what is UA's default;
   input radio button with style overlay; firefox doesn't think needs
   change -- opened bug, and was closed; follow ID model - more code to
   implement - need either a group widget or have to go through all
   widgets that have siblings with same id so know how to treat siblings;

   <oedipus> TW: best practice: tab into group of radio buttons then tab

   <oedipus> JG: have radiogroup role in ARIA; way i've been implementing
   radio button is first tab to it give radio group container focus, then
   select something, focus moves to selection

   <oedipus> Becky: for dojo, have to create seperate widget or generate
   a group

   <oedipus> JG: dojo implementation choice in ARIA

   <oedipus> Becky: in general have to generate group on the fly (don't
   want to create new element user doesn't have placeholder for) -- have
   a radio button widget, widget manufacturer sees 3 widgets with same
   id, generate a DIV to contain group - difficult to do when interacting
   with someone's pre-set styles; forcing creation of radio grouping

   <oedipus> JG: ARIA says only if not using standard markup, then do
   this, if not, doesn't apply

   <oedipus> JG: my radio button doesn't follow firefox or ie, uses ARIA
   to give radiogroup focus; since there is a radiogroup role, it works
   and makes more sense to use role information, rather than call from UA

   <oedipus> TW: if has ARIA role, radio button groupings should be tab
   navigatable, internally use arrow keys to move between choices, tab to
   next grouping

   <oedipus> JG: using radiogroup at all in dojo?

   <oedipus> Becky: let browser do it

   <oedipus> TW: summarize: consensus on tabpanel - when on focus in
   tabtitle right and left arrow keys move across, tab move you into tab
   area; control-tab and control-shift-tab will work as expected

   <oedipus> Becky: want up and down arrow

   <oedipus> GJR: look at UI behaviour of foobar2000 (www.foobar2000.org)

   <oedipus> TW: delete - keyboard shortcut (delete or control-F4) -
   should propose Control+F4 because you are closing, not deleting and is

   <oedipus> RESOLVED: tree right and left arrows as in OS - right
   expanding node left collapsing node, left again goes to parent; once
   expanded node navigation through up and down keys;

   <oedipus> Becky: just needs to be added to WAI Wiki

   <oedipus> TW: tab into radiogroup, move through buttons with up and
   down arrows, tab takes to next actionable element

   <oedipus> TW: issues for call in 2 weeks?

   <oedipus> JG: menus - in particular pulldown menus

   <oedipus> Becky: some stuff on wai-xtech about menus

   <oedipus> TW: look at both types of pulldowns

   <oedipus> JG: combo boxes and multiple selectino combo box

   <oedipus> TW: put on agenda for next week

   <oedipus> scribe: oedipus

   <scribe> scribe: Gregory J. Rosmaita

   scribnick: oedipus

Summary of Action Items

   [End of minutes]

    Minutes formatted by David Booth's [5]scribe.perl version 1.128
    ([6]CVS log)
    $Date: 2007/06/29 17:16:25 $

Found Scribe: oedipus
Inferring ScribeNick: oedipus
Found Scribe: Gregory J. Rosmaita
Scribes: oedipus, Gregory J. Rosmaita


   1. http://www.w3.org/
   2. http://www.w3.org/2007/06/29-xtech-irc
   3. http://www.w3.org/2007/06/29-xtech-minutes.html#agenda
   4. http://www.w3.org/2007/06/29-xtech-minutes.html#ActionSummary
   5. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   6. http://dev.w3.org/cvsweb/2002/scribe/

Received on Friday, 29 June 2007 17:24:50 UTC