W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2008

Corrected Draft Minutes: UA WG Weekly Telecon 2008-07-31

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Thu, 31 Jul 2008 21:11:28 +0100
To: w3c-wai-ua@w3.org
Message-Id: <20080731200934.M96306@hicom.net>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:52:01 GMT