- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 28 Feb 2008 14:20:21 -0600
- To: "'WAI-ua'" <w3c-wai-ua@w3.org>
http://www.w3.org/2008/02/28-ua-minutes.html
W3C
- DRAFT -
WAI UA
28 Feb 2008
Agenda
See also: IRC log
Attendees
Present
Regrets
Chair
Jim ALlan
Scribe
Jan
Contents
* Topics
1. 1. Review New Editor's draft
2. Displaying key commands
* Summary of Action Items
<oedipus> jan, FYI: the second nested heading under "Status of this
Document" at
<oedipus>
http://www.w3.org/WAI/UA/2008/WD-UAAG20-20080220/WD-UAAG20-20080220.html
<oedipus> refers to ATAG, rather than UAAG...
/me re: reference to ATAG...I see one spot "Editor's Draft of ATAG 2.0"...
<oedipus> .me yeah, that's the one
<scribe> Scribe: Jan
<oedipus>
http://accessibility.linux-foundation.org/a11yweb/presentations/csun2008/sli
des/opena11y/index.html
1. Review New Editor's draft
GR: Bit more than half way through it...
... Only thing noticed was ATAG ref out of place
KF: Done once and 25% of way through again
<oedipus> JR: Jim and i met for 2 intense days of edits; produced proposed
text to bring back to group -- reorganized things into 5 principles:
<oedipus> 1) follow applicable standards and conventions
<oedipus> JR: follow-up principle a bit different from other WAI GL docs
<oedipus> JR: not much to say at high level -- need to go through and get
consensus on structure and flow -- trying to move a public working draft;
shifted things without changing sens (tried to)
<oedipus> JA: couple of issues that made our brains sweat, but that may have
had to do with the time of day at which they were addressed
<oedipus> JA: KF or GJR have issues that leapt out at you?
JA: Any issues that jumped out?
KF: Nothing makes me say "oh my gosh"
<oedipus> KF: nothing that made me stop and pause on first read; second read
more detailed and slower
GR: Flows really well
... Not done UA review of HTML5 yet...
... Easier with new structure...
... Can't promise before April
JA: Suggest posted new addition to list about keyboard support
JB: Appreciated work on it
... From TEITAC seems like this will be very complicated
... But great if we could get something into draf
... Great if could go out before or during CSUN
... Would also like to do cursory walkthrough of proposed doc
<oedipus> FYI: Keyboard Access Functional Specification, Release Candidate
2: http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-rc2.html
Displaying key commands
<oedipus> and
http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-gta-rc2.html
JA: In UAAG1.0 covered by 1.1 and 11.1...
... But its a pain to hunt through when they are distributed
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0049.html
JB: Term distributed confuses the issue
... Explicitly looking for "visual"
... Some people fixated on programmatic route to these
... Realizing not a lot of orientation to needs of people with physical
disabilities but sight...
... Use case....person with limited movement ...hard to move from keyboard
back and forth to mouse
... Another case: head pointer, head mouse users
... Concerned that back in UAAG1 there was an option to have it distributed
... THat is basis for looking at things differently from here, TEITAC,
ISO...
<oedipus> GJR: related to issue PF been wrestling with -- trying to get
programmatic access not only to AT or a11y API, but to base operating system
-- use OS' native renderer to play aural cues (including ACSS) and to
trigger "show sounds" or "sound sentry" events, as well as getting a UA to
provide a summary of X in document (where X is accesskey assignments,
tabindex, number of forms, etc.)
KF: Scenarios are valid...can imagine even more
... Today there is feeling that accessibility=prog access=screen reader
JB: Real problem that some people in field couldn't picture the scenarios
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0049.html
<oedipus> GJR: would like to update "how people with disabilities use the
web"
<oedipus> JR: wasn't happy with what i sent, so let me explain
<oedipus> JR: idea is to split the following
4.1.5 Available Keystrokes: The user can always determine available binding
information in a centralized fashion (e.g., a list of bindings) or a
distributed fashion (e.g., by keyboard shortcuts listed in user interface
menus) for the following: @@11.1,11.2@@
(a) user interface "chrome" and extensions (including any user re-mappings),
and
(b) content keybindings that the user agent can recognize.
<oedipus> JA: link in IRC to new one JR talking about old one
<oedipus> JR: old one restatement of UAAG1 -- explaining what is different
<oedipus> JR: example access key in HTML
<oedipus> JR: have to show user keys from 1) chrome, 2) extensions to
chrome, 3) derrived from content (accesskey binding need to be shown to
user)
<oedipus> JA: things might be done in something outside the DOM and UA knows
nothing about them so can't make req on UA
<oedipus> JR: now, to the new stuff in the email (subj line is Re: agenda)
<oedipus> JR: split into 2 -- one for chrome and one for content
<oedipus> KF: hold on -- first one -- what are you trying to get them to do
-- help file or something else?
<oedipus> JR: help file
<oedipus> JB: number of issues -- maybe should note things to discuss, hear
proposal
<oedipus> JR: menu items with shortcut keys as well as shortcut keys for
buttons or other interactive items would be in UA UI
<oedipus> KF: hold on -- available by default, or keyboard binding in
tooltip ok?
<oedipus> JR: option user sets - most appriate for that user -- could
underline on pressing alt
<oedipus> JR: shortcut keys available programmatically for all input
<oedipus> JB: relationship with 4.1.x
<oedipus> JR: content keyboard commands -- don't make sense unless content
being rendered
<oedipus> JB: access keys?
<oedipus> GJR: tabindex order
<oedipus> JR: all of that
<oedipus> JR: all keyboard commands that are currently available (content
sensitive)
<oedipus> JR: keyboard trap addressed -- if not easy to tab out of, user can
query what are my keyboard options, would bring up list of all possible
actions, one would be leave trap
<oedipus> KF: trap?
<oedipus> JR: standard navigation won't get you back into document
<oedipus> JA: old flash an example
<oedipus> JB: back to beginning of proposed rewording?
<oedipus> JA: sure
<AllanJ> GR: also a problem with some CAPTCHA grabbing keyboard focus and
not letting it go
<oedipus> JB: not technical issue, but interprative -- when JA and JR and i
spoke about this already being coverred in UAAG 1.0 and i responded that it
wasn't clear -- need to have worded as transparently as possible, so users
can understand what is being described -- could we remonve chrome from the
defnintion/first bit
<oedipus> JA: ok with that
<oedipus> JB: just "available shortcut keys"
<OedipusWrecked> JB: second: notify may be confusing term -- current option
C is where is most relevant, but not exactly correct --- available
programmatically; on others display or inform --- notify creates consusion
upfront and might bias interpretation -- want displaying visual indication
without anyone having to do anything to UI
<OedipusWrecked> JA: UUAG 1 -- provide info to user about current input
configurations
<OedipusWrecked> JB: front half good
<OedipusWrecked> JA: in place of "notify"?
<OedipusWrecked> JB: worth trying
<OedipusWrecked> KF: item C --
<OedipusWrecked> JA: finish 1 first
<OedipusWrecked> KF: come back to it
<OedipusWrecked> JB: looking at it phrase by phrase -- "provide information
to the user about shortcut keys" then could mention "chrome" as long as
links to definition
<OedipusWrecked> JR: what info other than shortcut keys
<AllanJ> KF: if I invent new UA, then need to faclitate the revealing of
shortcuts to users
<AllanJ> ...if you have extensibility mechanism, this must be considered.
<AllanJ> in 4.1.5.a need centeralized listing (help file), but extensions
won't be documented in base UA helpfile
<AllanJ> JR: remove 'extensions' prevent word clutter.
<AllanJ> JR: add conformance claim about extensions
<oedipus> JB: indicate work for all 3 environments
<oedipus> JA: works
<oedipus> JR: any is important -- may not have shortcut keys available
<oedipus> JB: came up in TITAC -- would solve problem
<oedipus> KF: one point -- cover all the time, but need to state user agent
may not know about shortcut keys added by an extensions -- UA extension
mechansim has to facillitate this action
<oedipus> JA: discussions way back when, when peter was still on call
working on orca, if something plugs into FF through XUL, becomes part of UA
and UA is congnizant of it
<oedipus> KF: what if browser x comes out tomorrow, is a huge success, but
doesn't learn or have knowledge of extension capabilities
<oedipus> KF: if information not there, can't be magically obtained -- if
building UA with extensibility mechanism, this HAS TO BE CONSIDERED
<oedipus> JR: could say "conforming extensions" or say "user agent/tool plus
any extensions you add onto it for purposes of conformance"
<oedipus> KF: follow-up under point A have to list all shortcut keys --
can't do that in help file if using toolbar extension, for instance -- could
suck up all shortcut keys -- need to discuss
<oedipus> JR: lets take out extensions -- word clutter if add "and
extensions" to everything we say -- add verbiage to conformance section
(user agent + extensions)
<oedipus> JR: have to change A
<oedipus> JA: need another GL or ckeckpoint dealing specifically with
extensions or modular add-ons -- stick all odd little bits into that --
don't do if don't extend or modularize
<oedipus> JR: like that idea -- good place to target
<oedipus> KF: extensions make a lot of interesting challanges
<oedipus> JA: and add a lot of functionality
<oedipus> JB: have to flag that issue prominently if going to publish as
FPWD
<oedipus> JB: can we mark that and park it under continued?
<oedipus> JB: on A, issue want to raise first is that this doesn't belong
first, but last in list of 3 items; might be arguments for it to be at diff
priorty level than other 2
<oedipus> JB: in addition to issues of usefulness there are also technical
issues as to feasibility; 2 diff kinds of interpretations and fears in
developers: no definition of what a centralized listing meant (everyone had
their own, mnostly idiosyncratic opinion)
<oedipus> JB: some in help menu, some on product web site
<oedipus> JA: ugh
<oedipus> JB: yes, -- also how to aggregate listings with extensions from
thirdparties -- how do you document that
<oedipus> JB: one list or a reliable place for users to go
<oedipus> JB: brad hodges at AFB said what is most useful is a reliable
place to go to in the help for the user agent that has a direct link to the
most up-to-date aggregation of documentation
<oedipus> JB: wanted to point out that this isn't as simple as stating
"listing of shortcut keys" -- also technical problems with third-party
extensions, OS shortcuts, etc.
<oedipus> JB: another ascpect misunderstandings of importance -- for someone
with limited or no use of hands and need visual indication in UI without
having to hunt with hands, is useless except when someone is attempting to
become a speed user -- for someone with cognative disaiblity (particularly
learning or retention area) this is a level 1 -- even if being coached
<oedipus> JB: regardless, that is a P1 for cognative, but not satisfactory
for those with limited hand movement and those useing screen readers
<oedipus> JR: if don't want to look through menus and trawl serval layers
deep - how are you going to expse?
<oedipus> JB: in FF, want to use "find in this page" which has mulitple
choices in it -- can have nested options and a ... and the keyboard shortcut
next to primary command
<oedipus> JR: still have to go to edit menu, then...
<oedipus> JB: no, if alt-b in FF, opens bookmarks
<oedipus> JR: ok if distributed as long as path is keyboard perceptable and
accessible
<oedipus> JB: yes, been saying that from the beginning; UAAG 1.0 says by
item or sequential access -- sequential access breaks down in many use cases
<oedipus> JR: downArrow downArrow downArrow is sequential
<oedipus> JB: can do a lot with arrows, but when went onto mac for 6 weeks
killed my hands -- only 50% keyboard shortcuts -- tried everything i could,
but had to get up to speed on 10 diff apps on new OS -- simply impossible in
a work sitation
<oedipus> KF: opera's behavior for ACCESSKEY press keycombo and displays all
access keys
<oedipus> KF: could press one key, and if a product is built correctly,
should be able to generate a "show me everything i can do" dialog
<oedipus> JB: need to do a lot of looking through stuff
<oedipus> JB: ArrowKey navigation extremely keying intensive -- really an
undue and inefficient burden -- if engineered right way, can be
autogenerated and listed in menu
<oedipus> JR: depends upon one's keyboards (doOver versus hunting for key)
<oedipus> JB: on screen keybaords?
<oedipus> JR: that's where i got the concept
<oedipus> JR: KF made good point -- context sensistive listing on the fly
"what can i do now" is what i tried to capture and why i divided the point
<oedipus> KF: is there a product that does what you want today?
<oedipus> JB: windows
JB: Looking for direct visual discoverability
KF: And windows is acceptable
<AllanJ> JR: beyond direct Visual discoverability
<AllanJ> GR: use keyboard to move with keyboard same as mouse user does
<AllanJ> JR: problem with DVD, for all keys. if a user with mouse does one
click, but takes three keys for keyboard user
<AllanJ> JR: need to get wording right to explain clearly
<AllanJ> JB: some menus have direct access, others must arrow
<AllanJ> GR: see Keyboard Access Functional Specification, Release Candidate
2: http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-rc2.html
GR: Earl Johnson working on thias
<AllanJ> Displaying key commands and
http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-gta-rc2.html
<AllanJ> GR: to be released before CSUN
JB: Is this cooked?
GR: Pretty much
... Meeting tomorrow ... then we need an IPR policy
JA: Looks like rewrite of older stuff StickyKeys etc
GR: Will be released as a Release Candidate
... Will bring up "visual indicator" up on call tomorrow
JB: Even have place to put it...display state
JA: THey are talking about hardware in some places
... May be ok
GR: Something seems to be missing from conversation
... OK here are hardware reqs, now we neeed HCI software ones
<scribe> ACTION: JR to Reformulate visual display of key commands proposal
[recorded in http://www.w3.org/2008/02/28-ua-minutes.html#action01]
<AllanJ> JR: UAAG says user OS conventions.
<AllanJ> if the OS does not provide something, should the UA do it anyway.
JR: just going to say...
<AllanJ> have to make your own custom controls accessible
JR: follow platform but if you don't want to you have to do the hard work
yourself
Summary of Action Items
[NEW] ACTION: JR to Reformulate visual display of key commands proposal
[recorded in http://www.w3.org/2008/02/28-ua-minutes.html#action01]
Received on Thursday, 28 February 2008 20:22:15 UTC