See also: IRC log
<scribe> scribe: Gregory_Rosmaita
<scribe> scribeNick: oedipus
chair+ Jim_Allan
JA: no regrets logged
... additional agenda requests?
JB: recent changes in AU stuff -
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
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