<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 discoverable

<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 available

<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 browser;

<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 possibility

<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 pagedown

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

<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 keystrokes

<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 out?

<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 firefox

<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 button

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

<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 context

<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 item

<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 pre-checked

<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 out

<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 catchable

<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

This is scribe.perl Revision: 1.128  of Date: 2007/02/23 21:38:13  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

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

WARNING: No "Topic:" lines found.

Present: becky_gibson tim_??_from_google tom_w_(AOL) earl_johnson gregory_j._rosmaita jon_r._gunderson
Got date from IRC log name: 29 Jun 2007
Guessing minutes URL: http://www.w3.org/2007/06/29-xtech-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report