IRC log of xtech on 2007-06-29

Timestamps are in UTC.

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