- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Fri, 29 Jun 2007 13:24:37 -0400
- To: wai-xtech@w3.org
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.
gregory.
-------------------------------------------------------------------------
[1]W3C
- DRAFT -
DHTML Subteam Meeting 29 June 2007
29 Jun 2007
See also: [2]IRC log
Attendees
Present
becky_gibson, tim_??_from_google, tom_w_(AOL), earl_johnson,
gregory_j._rosmaita, jon_r._gunderson
Regrets
Chair
Tom Wlodkowski
Scribe
oedipus, Gregory J. Rosmaita
Contents
* [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
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
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
References
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