16:07:10 RRSAgent has joined #xtech 16:07:11 logging to http://www.w3.org/2007/06/29-xtech-irc 16:07:12 becka11y has joined #xtech 16:07:26 meeting: DHTML Subteam Meeting 29 June 2007 16:07:45 chair: Tom Wlodkowski 16:07:58 JRG has joined #xtech 16:08:33 Agenda 1: Discuss additional comments on tab panel. 16:08:37 Agenda 2: Keyboard behaviors for tree views. 16:08:42 Agenda 3: Discussion of radio buttons (time permitting) The issue of radio buttons was raised on the last call. 16:08:52 TW: tabpanel? 16:09:08 Becky: escape dangerous if a delete - people instinctivly try escape 16:09:23 TW: retain context menu, should there be a shortcut key to make it happen 16:09:31 Becky: both 16:09:46 TW: have a context menu only way to do this, right? 16:10:03 Becky: talked about this in dojo - context menu somewhat discoverable 16:10:13 JG: ARIA property deletable 16:10:20 Becky: please provide info 16:10:52 TW: have to have context menu- might want to close, not delete - could be session based - lot of issues around task 16:11:02 Becky: how does close differ from delete? 16:11:17 TW: in radio application - today don't use; 2 weeks later do 16:11:20 Becky: add back 16:11:50 JG: restore all tabs perhaps needs to be added to tabpanel - store all tabs, store deleted tab - delete this tab, but keep title available 16:12:27 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 16:13:27 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 16:16:12 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 16:16:25 GJR: bidirectional communication needed between app and AT 16:17:16 Becky: deleted ok, but not contextmenu - delete in style guide except have to have context menu 16:18:27 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; 16:19:24 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 16:19:37 Earl: define delete as action, now in style guide? 16:19:47 TW: control-F4 better 16:20:01 Becky: can we catch that; can't catch all keystrokes in browser; 16:20:20 TW: counterpropose that instead of delete use keycombo 16:20:35 JG: control should be on each tab 16:20:53 Earl: does control-F4 close window in FireFox? 16:21:19 JG: closes tab by default in FireFox; control-PageDown possibility 16:21:45 Becky: can catch onkeypress but not onkeydown for Control PageDown and Control PageUp 16:21:57 JG: Firefox or IE or both 16:22:35 JG: using keypress to capture control pageup control pagedown 16:22:51 Becky (investigating as speaking): don't think i can catch it 16:23:03 Becky: with onkeypress goes away 16:23:08 JG: keycode for F4? 16:23:27 Becky: can't catch it; trying to stop event 16:23:41 Becky: only issue is can we catch it or not 16:24:30 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 16:24:45 Becky: need to update test - not currently including F4 16:25:15 RESOLVED: more due dilligence required to determine keystrokes 16:25:38 RS: find ideal keystrokes for BrowserX? or universal 16:25:55 JG: did capture F4 onkeypress in firefox - keycode 115 16:26:06 Earl: will browser folks change key sequences 16:26:38 JG: consensus is that if in tabpanel, and conflicts with browser keystroke, tabpanel takes precedent 16:27:22 TW: widget wins, but where we know there are known conflicts with browsers, will try to define non-conflicting keys 16:27:39 Becky: last meeting control pageup and control page down 16:27:52 JG: control+shift+? 16:28:04 TW: conflicts with browser tab shifting 16:28:28 Earl: control tab must be the one -- needs to be stressed in style guide; 16:29:28 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 16:29:37 Earl: review where headed? 16:30:00 TW: widget wins, but where there are inherent keystroke conflicts, should avoid using them 16:30:10 TW: moved to next mutually supported keystrok 16:30:25 Earl: do we consider the browser is still the question 16:30:42 JG: can't have best practices guide that outlines strategies that don't work 16:30:55 Becky: what if entire page is tabpanel - how will user get out? 16:31:04 JG: tab out of page 16:31:26 TW: 2 pages loaded - one tabpanel, one newsarticle; can control-tab between 2 pages, what happens? 16:31:39 Becky: wouldn't be able to capture tabpanel widget in firefox 16:32:47 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 16:34:52 GJR: 3 levels of granualarity - at, ua, widget 16:35:32 JG: are menus the fallback 16:35:40 GJR: not necesarily 16:36:02 JG: browser going to win some places not in others; more ecclectic in terms of people's knowledge 16:36:25 Earl: conteragrument - model used / learned to interact with browser now better than desktop 16:37:25 JG: application winning provides user with opportunity to do something; can always get out of a document by requesting new URI; if browser wins 16:37:35 GJR: three tiered - widget, at, browser 16:38:34 JG: those who can't use mouse with sight; 16:39:26 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 16:41:22 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 16:41:42 TW: enable appllication keyboard control would inherit desktop behaviors for widget 16:44:24 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 16:44:46 Becky: know what has focus know what has control, but don't know who's controling 16:45:02 Becky: don't know if a HTML button element or a dojo widget button 16:45:14 Earl: good point; mixture of widgets and standard HTML components 16:46:00 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 16:46:06 Earl: strike my prop, then 16:46:38 Becky: ARIA property only goes on body - for SR forces into virtual buffer need to go in and out of buffer 16:47:28 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 16:48:02 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 16:48:09 Earl: does browser win or no? 16:48:38 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 16:48:52 ??: not sure can move forward with style guide in this context 16:49:37 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 16:49:51 ??: browser must win for now 16:50:57 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 16:51:25 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 16:51:58 TW: is there a way through here - control tab controlshift tab works on JAWS example today, when focus not in widget overrides 16:52:09 JG: can't see how can't have web app win in this situation 16:52:17 RS: is it our option that widget wins? 16:52:44 JG: can't get keystroke, can't cancel; if process keystroke according to W3C DOM, can cancel 16:52:54 RS?: is possible for us to programmatically win 16:53:05 Becky: in most cases 16:53:12 TW: confused - going round in a circle 16:53:22 Becky: last week decided specific keystrokes 16:53:40 Becky: concerned about being trapped in widget; especially if tabpanel only thing on page; 16:55:06 TW: if trapped on widget, should be able to arrow out - maybe can start to explore widget winning 16:55:16 Earl: let's go back to browser not winning 16:55:18 GJR: agree 16:55:21 TW: agree 16:56:05 TW: if browser doesn't win, can use control-tab and control-shift-tab; tree left and right to expand/collapse 16:56:57 GJR: good, if as earl says, reuse keyboard behaviors for desktop widgets as much as possible, lessens gradient of steepness of learning curve 16:57:14 TW: what do we need with tree? 16:57:31 Becky: left arrow twice, you can end up on parent 16:57:46 Becky: on my wiki, not on ARIA wiki; al gilman has action item 16:58:15 Becky: open, then go to next visible node; only ONE tab active in tree, and that is current focus 16:58:41 Earl Johnson needs to leave call 16:59:05 TW: tab key moves to tree, next tab moves away, when tree has focus, left and right arrows should expand/collapse 16:59:12 TW: what about radio button issue? 16:59:33 JG: default behavior of UA when radio button not explicity pre-checked 17:01:17 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; 17:01:34 TW: best practice: tab into group of radio buttons then tab out 17:02:19 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 17:02:52 Becky: for dojo, have to create seperate widget or generate a group 17:03:04 JG: dojo implementation choice in ARIA 17:04:22 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 17:04:49 JG: ARIA says only if not using standard markup, then do this, if not, doesn't apply 17:05:45 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 17:06:19 TW: if has ARIA role, radio button groupings should be tab navigatable, internally use arrow keys to move between choices, tab to next grouping 17:06:27 JG: using radiogroup at all in dojo? 17:06:33 Becky: let browser do it 17:08:37 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 17:09:34 Becky: want up and down arrow 17:09:54 GJR: look at UI behaviour of foobar2000 (www.foobar2000.org) 17:10:34 TW: delete - keyboard shortcut (delete or control-F4) - should propose Control+F4 because you are closing, not deleting and is catchable 17:11:30 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; 17:11:41 Becky: just needs to be added to WAI Wiki 17:12:06 TW: tab into radiogroup, move through buttons with up and down arrows, tab takes to next actionable element 17:12:16 TW: issues for call in 2 weeks? 17:12:26 JG: menus - in particular pulldown menus 17:12:38 Becky: some stuff on wai-xtech about menus 17:12:48 TW: look at both types of pulldowns 17:13:12 JG: combo boxes and multiple selectino combo box 17:14:10 TW: put on agenda for next week 17:15:00 present: becky gibson, tim ?? from google, tom w (AOL), earl johnson, gregory j. rosmaita, jon r. gunderson 17:15:20 scribe: oedipus 17:15:27 scribe: Gregory J. Rosmaita 17:15:31 scribnick: oedipus 17:15:43 rrsagent, set logs world-visible 17:15:58 rrsagent, create minutes 17:15:58 I have made the request to generate http://www.w3.org/2007/06/29-xtech-minutes.html oedipus 17:16:12 rrsagent, format minutes 17:16:12 I have made the request to generate http://www.w3.org/2007/06/29-xtech-minutes.html oedipus 17:16:20 rrsagent, publish minutes 17:16:20 I have made the request to generate http://www.w3.org/2007/06/29-xtech-minutes.html oedipus 17:18:11 rrsagent, please part 17:18:11 I see no action items