- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Thu, 31 Jul 2008 21:11:28 +0100
- To: w3c-wai-ua@w3.org
please ignore the previous minutes announcement - it contained a copy
and paste error - here is the announcement and the minutes -- apologies
to all for any inconvinience... g.
aloha, all!
minutes from today's UAWG meeting are available at:
http://www.w3.org/2008/07/31-ua-minutes.html
an IRC log is also available at:
http://www.w3.org/2008/07/31-ua-irc
3 action items were logged at today's call:
1. ACTION: Kelly, Jan, and Jim - develop replacement for list of
specific commands for WG review [recorded in
http://www.w3.org/2008/07/31-ua-minutes.html#action01]
2. ACTION: Kelly - draft more definitive fact-based opinion from IE
developers [recorded in
http://www.w3.org/2008/07/31-ua-minutes.html#action02]
3. ACTION: Gregory - wordsmith user configuration, persistence and
override GL [recorded in
http://www.w3.org/2008/07/31-ua-minutes.html#action03]
and WG members are asked to PLEASE REVIEW jim's on-list proposals:
Keyboard trap:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0051.html
Proposal for Placement of keyboard items
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0050.html
as well as JA's current proposal "Guideline 4.1 Ensure full keyboard
access"
http://www.tsbvi.edu/technology/uawg/thrashing.htm
which was the topic of much of today's conversation
as usual, please log any corrections, comments, misattributions or
clarifications by replying-to this announcement on-list
thank you,
gregory.
- DRAFT -
User Agent Accessibility Guidelines Weekly Call
31 Jul 2008
Agenda
See also: IRC log
Attendees
Present
+1.512.233.aaaa, Alan, Gregory, Jan, Jeanne, Jim, Judy, Kelly,
Simon
Regrets
Chair
Judy_Brewer
Scribe
Gregory_Rosmaita
Contents
* Topics
1. Regrets, agenda requests, comments?
2. 2. Focused Keyboard discussion
3. Level AA
* Summary of Action Items
_________________________________________________________________
<scribe> scribe: Gregory_Rosmaita
<scribe> scribeNick: oedipus
chair+ Jim_Allan
Regrets, agenda requests, comments?
JA: no regrets logged
... additional agenda requests?
JB: recent changes in AU stuff -
2. Focused Keyboard discussion
for reference: http://www.tsbvi.edu/technology/uawg/thrashing.htm
JA: level A items 4 and 5, level AA item 1
... did 1 to 3 last week
... number 4 - direct keyboard command (Level A)
... all items on list are used elsewhere in UAAG2 - "allow user to
configure this..." this should be available..." -- 4 pins it down as a
requirement
"Direct keyboard commands can be used to activate the following
important functions (list) Level A
move content focus to the next/previous enabled element in document
order
activate the link designated by the content focus
open search function, search again
increase/decrease the scale of rendered text
increase/decrease global volume
stop/pause/resume and navigate efficiently audio and
animations,including video and animated images
next/previous history state (i.e., forward/back)
enter a URI for a new resource
add a URI to favorites (i.e., bookmarked resources)
view favorites
reload a resource
interrupt a request to load or reload a resource
navigate forward and backward through rendered content by
approximately the height of the viewport
(n) for user agents that render content in lines of (at least) text:
move the point of regard to the next and previous line
"
KF: 2 comments: 1) needs to be a comma clause saying what user agent
supports - if don't have 1 of these features? (2) is it possible in
operating environment
... good list, but what happens if new features arise - list is
static, world is not
JB: yes
KF: example - almost every UA has a search box; could be other
features - function of UA or OS?
... need to differentiate between UA and OS
... recommendation: remove global volume item from list
SH: reword slightly - "important functions, including..." - make
non-exclusive list
KF: how is list derived and was it discussed?
JA: yes - particular one for adjusting global volume - UAAG2 GL 3.8
from old UAAG1 1.7 1.8 - audio browser-centric; voice
output/self-voicing app needs user control from within app
... function of user agent and platform - if not self-voicing, don't
need to cover global volume adjustment
JS: application bar
AC: embedded elements with volume control (video embedded in web page
with widget) - would that widget's volume control need to be
adjustable
JA: player another UA, so flash player needs to put in adjustable
volume; parent UA probably unaware of embedded player functions
KF: global volume or application volume - how deeply do we want to dig
in this list?
JB: appreciate your broaching this, kelly; one possibility is to pick
2 to discuss can then try to extrapolate from concerns arising out of
2 we discuss
... one thing running through my head is question of: should this list
be in some other document that is not normative and static; might be
far worse - potentially asking people to conform or build software
that may not be stable; dev's perspective, that is worse, but presents
dilemma either way; think haven't found right approach for particular
needs
JA: might be overkill; original were somewhere else in guidelines;
provide user ability to do x, y, and z; this particular one says
functions addressed elsewhere in document, but have to provide direct
keyboard command for function; that was original intent for these 14
items; all have specific guideline that refers to specific function;
listed all in one place to say not enough to provide function but must
provide keyboard command
... could add keyboard requirements to the 14 individual GLs
JB: could say "for every thing at such-and-such a level" - want to
genericize
SH: are we saying that these things should be included and should have
keyboard commands or if functionality in UA, use theese keyboard
commands
JR: are these all things UA has to have with keyboard function, or
have to have keyboard support if included and think is second
JA: agree with that
SH: integrate into other checkpoints; might be good things to offer
explicitly when functionality defined
<Jan> JR: AU: If the authoring tool includes any of the following
functions, authors can enable key-plus-modifier-key (or single-key)
access to them
JB: i don't get a lot from having specific list of items - kind of
direct keyboard access that i've been trying to articulate in document
is more general principles
... concern: list might include a lot but may also leave out a lot -
want to genericize - anything that is active command needs direct
keyboard support
... list very fixed in time and seems different from all other GLs
JA: dilemma - UAAG1 and UAAG2 have 13 separate GLs to say "have to
offer x functionality" and this one says this functionality has to
have keyboard command
AC: equal a11y problem - browser features that are "needed" today
aren't on list (plug ins or extensions)
JR: did quick search - could move somewhere else
<Zakim> oedipus, you wanted to ask if can have meta-guideline "all
functionalities provided by a User Agent must enable
key-plus-modifier-key or single key access to them
AC: danger! danger!
... not sure that "everything" is true - things that can be gotten to
by going through menu (especially if not used often) - functions used
every day need keyboard
GJR: menus may be too onerus, a lot of chrome available by default
JR: alot that can't be done by direct key
JB: what is criteria for what is most important?
KF: if have top-level features try to have direct hotkey access to
features; other dev goal is "if you can do with mouse wiht one click,
should be able to do at most with 5 keystrokes"
... end goal is all top-level stuff key-bound
JA: UAAG1 a lot of checkpoints about changing font size, searching
within page, moving focus backwards and forwards; essential features
the group thought in 1998-2002 were important - genesis of 13 GL
checkpoints; ported to this list because already levelA or level AA
... conformance claim can say "our UA doesn't do search" - so don't
conform to that GL, but that is origin of list
KF: example: reading this GL what was meant in 1998 was search web
content (find on page/document); today, have search box that launches
web search automatically - should that have direct hot key access
... not just the naming of what you want, new feature added to UA now
considered a must have
JB: Jan tying to reqs i've been raising; req i've been raising was
less that a specific keyboard command has to be available for
everything, but findability is a parmount concern
... more classic - ought to be direct keyboard way to do everything,
but agree with AC's point about not commonly used features
... why this list? wouldn't stand up as set of requirements - is there
a principle that separates them from other things
JA: have GLs that say "you must do this";
JB: can we then say "for anything at Level A, make sure a direct
keyboard command for that
JR: used to be the case, but not requirements in document for
"favorites/bookmarks"
JA: to address Judy's comment, sounds fuzzy - more work for developer
JB: could either enumerate in TECHS doc, or list in UAAG2 itself, but
need to ensure list is updated;
... concern about being static, but if principle is "these are things
that are level A" if do 2.1 and need to drop and add, can just change
one place in document
JA: not going to be picked up by developers
JB: suggest we move on from this fairly soon
KF: in addition to list, GLs implicit - design principles wouldn't be
encouraged by this; point to encourage/require "sufficient" keyboard
use (as few keystrokes as possible); not setting parameters for number
of key strokes -- very testable for conformance
... or do we just say "you should go in this direction" and leave to
notes and techniques
... if Level A feature or function needs single hot key
JR: support what Kelly said; don't want to go through P1 things;
usability of keyboard; moving to address bar not P1, but needs useable
keyboard shortcut; also agree that need principle as to whay here
AC: so important for keyboard access can't give devs an out on
keyboard support; big difference between barely useable, and usable
JB: for higher priority functions identified as A, should apply
principle of "efficient keyboard support" defining number of
acceptable keystrokes
JR: proposal is: what is used on daily basis - enter URI in address
bar - basic, but not P1/Level A requirement, just feature of tool;
example of keyboard hotkey that isn't a P1
JA: think should take to list - 3 people sub-committee to thrash out
on list?
JB: may want competing versions
... might be critical mass that want to ditch list of specific
commands
... who would like to ditch list
KF: yes
JR: yes
JB: yes
SH: yes
AC: keep list
GJR: half-and-half
JB: Alan will be a quality control to ensure we can win him over
JA: several points: 1) efficient keyboard use - x number of keystrokes
... 2) need keystrokes for all Level A
... 3) need to identify key features not explicitly addressed as
keyboard accessible
... still need critical mass of people - volunteers for changing list?
JR: would like to hear from Kelly
KF: accept
JS: wouldlike to help, but on vacation
JB: group will go ahead and then review
JR: will work with Kelly on this
AC: should sit in on this
JB: could do on email list or have 3-way call
AC: on holiday for next 2 weeks
KF: didn't do other action item (not complete, anyway)
... send something to list, members can kick around, can set up a
conference call via MS facilities
JB: just need dedicated effort
<scribe> ACTION: Kelly, Jan, and Jim - develop replacement for list of
specific commands for WG review [recorded in
http://www.w3.org/2008/07/31-ua-minutes.html#action01]
JA: recognized content (accesskey) unrecognized content (scripting) -
"User has the option to configure the keyboard processing order (UI,
extensions, recognized content (Access key, AT), unrecognized content)
Level A"
JB: nested set of parentheticals that makes hard to parse
JA: opinions?
... user defines processing order
JB: is level A?
JA: yes
JB: thought proposing change?
JA: wanted thoughts before proposals
... did not exist in UAAG 1.0
GJR: supports the principle at Level A
KF: oppose at level A - level A should be inform user so knows what is
happening; challange is technically, is hard to do
JA: current operation is the reverse: UA applies scripts, then
accesskeys, then UI
KF: depends - something we struggle with alot
... in favor of concept, but not in favor of it as Level A
JR: second kelly on this; pretty intrusive thing - accessibility
implications on both sides
JB: what is use case for not doing this?
JR: depends on how you perceive UA - UA operating content, or
accessing GMail which happens to be running in a UA - do you want
GMail over IE?
KF: what we are asking is "let user decide"
... 2 concerns: 1) usability perspective: most users just want to
press a key and have an action executed
JB: understood
KF: mechanism, though is important
JA: key thing from Kelly and Jan is "user presses key and wants right
thing to happen"
... originally came up with this to fit accesskey - what does user
want to happen?
... trade-offs
KF: right thing will happen as best as possible, or user has way to
get out of it;
... accesskey to document first - other ways to get to UI commands
GJR: sequential keying (alt then press key) and simultaneous keying
(alt plus key)
<Zakim> oedipus, you wanted to say that ARIA dropped attribute
"templateid" would be a solution for this content verus UI cascade
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0017.html
KF: somewhat familiar with templateid, but has limitations
GJR: some small engineering problems that would need to be solved
JA: proposal to remove configure and state "UA needs to document
processing order, so user knows what to expect"
KF: no, just drop to level 2 (AA)
JR: that's my thought too - drop to level 2
JB: concern: if this is something that as currently worded would be
show-stopper for some implementors, and change to double A, then we
are saying we are ok without working out the conflict, need and
feasibility; have problem with not being able to aim for double A
... rather better define user need and developer feasability
... no strong case for this to be level A
GJR: thinks this is a Level A
JB: may need to sort issues out before assigning a level to it
JA: additionally, this proposal came from user agent dev, commenting
that current UA serves strict first - hit keystroke, trapped by script
but UA has no idea key trapped until script passes on; dev said should
be other way around UA handle, if can't do hand down to script - just
one developer's perception
KF: can't just focus on script - widgets, embedded objects all can
interfere
... can't agree with making Level A without more consultation with MS
developers
JB: may not have right wording yet
JA: that's what i hear - configure option
KF: today, based on what we do and is technically possible, user has a
work-around - turn off scripting
GJR: that is FAR too draconian (turning off scripts)
JA: don't have depth to investigate - perhaps should throw to PF
AC: as user don't want to have to turn off scripts to perform normal
functions on a page
KF: dealt with this a lot -
<scribe> ACTION: Kelly - draft more definitive fact-based opinion from
IE developers [recorded in
http://www.w3.org/2008/07/31-ua-minutes.html#action02]
JB: anyone else want to take action item on this?
... anyone want to tweak wording or wait until get feedback
JA: wait for feedback
Level AA
text: "User override of all UI and recognized content keyboard
controls with session persistence Level AA "
AC: no verb
JR: unspoken "there is"
JA: "user can" or "allow user to override"
JB: checking others - "user can override..."
"User can override of all UI and recognized content keyboard controls
with session persistence (Level AA)"
JB: need to break down
GJR proposal; "For keyboard controls with session persistence, the
user should be able to override all UI and recognized content keyboard
controls."
JB: flip - recognize content keyboard controls for recognized content
JA: thought was 2 parts to UA - application part (UI) and content area
... want to be able to override or remap keyboard controls if
interferes with AT or physically incapable
<Judy> User can override all user interface and keyboard controls for
recognized content with session persistence.
JA: second part (content): accesskey defined for key not on keyboard
or keybingind conflict
GJR: do we have definition of recognized content?
JB: does UI apply to controls (all user interface and keyboard
controls?)
JA: keyboard controls in UI and keyboard controls in content
JR: keyboard commands rather than controls
... "User can override keyboard commands for UI. User can override
keyboard commands for recognized content."
GJR: definition of "recognized content"?
<Judy> User can override all keyboard commands for user interface and
recognized content with session persistence.
JA: in glossary - content recognized by UA
AC: what is session persistence? permanant or one-off
JR: persistence between sessions?
JA: think so
<sharper> Is this any better?
<sharper> User can override all keyboard commands used for controlling
both the User Interface and recognised content.
<Judy> User can override all keyboard commands for user interface and
recognized content with persistence between sessions.
<sharper> User can override all keyboard commands used for controlling
both the User Interface and recognised content.
JA: persistence refers to content area - site specific, can be saved
for next time access site
JB: not there yet, and dont' think will get there in next 5 minutes
... Simon, yours leaves out session persistence
<sharper> ; and this override is maintained between sessions.
JB: session persistence - once agree what is - need to get into right
place in sentence; make sure that sentence would work without any of
the stuff in the middle
<Judy> User can override [...] with persistence between sessions.
GJR: model is how UAs handle cookies - session only, always for this
site, never
JB: user can then select or configure whether want configuratgion
overrides to last between sessions
GJR: right
JB: for UI commands and recognized content
AC: User can configure keyboard interface of UA to ..."
JB: user can set configurations that persist between sessions
<Judy> User can set configurations that persist between sessions for
keyboard commands for user interface and recognized content.
<Judy> User can set configurations that persist between sessions for
both keyboard commands for user interface and recognized content.
<Judy> wrong
<Judy> User can set configurations that persist between sessions for
keyboard commands for both user interface and recognized content.
<Judy> User can set configurations that persist between sessions for
keyboard commands for both user interface and recognized content.
<Judy> sorry
GJR friendly ammendment: Users SHOULD have the choice of applying
specific configurations for a specific site, for the duration of a
particular sesion, in the same manner that a user can control cookie
collection
<Judy> User can [override and ...]configurations that persist between
sessions for keyboard commands for both user interface and recognized
content.
<scribe> ACTION: Gregory - wordsmith user configuration, persistence
and override GL [recorded in
http://www.w3.org/2008/07/31-ua-minutes.html#action03]
<Alan> User can override default keyboard commands...
JB: can everyone comment on Jim's proposals?
... AC, JS will be away, but everyone else should review:
http://www.tsbvi.edu/technology/uawg/thrashing.htm
http://www.w3.org/WAI/UA/2008/keyboardProposals20080714.html
Summary of Action Items
[NEW] ACTION: Gregory - wordsmith user configuration, persistence and
override GL [recorded in
http://www.w3.org/2008/07/31-ua-minutes.html#action03]
[NEW] ACTION: Kelly - draft more definitive fact-based opinion from IE
developers [recorded in
http://www.w3.org/2008/07/31-ua-minutes.html#action02]
[NEW] ACTION: Kelly, Jan, and Jim - develop replacement for list of
specific commands for WG review [recorded in
http://www.w3.org/2008/07/31-ua-minutes.html#action01]
[End of minutes]
_________________________________________________________________
Received on Thursday, 31 July 2008 20:12:04 UTC