Re: Minutes of UA Teleconference of 14 August 2008

I saw a discussion that went from "currently visible" to "currently 
available" but I am not sure what is being  attempted with these two 
statements.  I understand why "currently visible" is out but it is not clear 
to me what "currently available" means.

Thanks!

----- Original Message ----- 
From: "Jeanne Spellman" <jeanne@w3.org>
To: "User Agent Working Group" <w3c-wai-ua@w3.org>
Sent: Thursday, August 14, 2008 3:49 PM
Subject: Minutes of UA Teleconference of 14 August 2008


Minutes:

IRC Log:

Action Items:

[NEW] ACTION: JA will consolidate the proposals and notes for
   Guideline 4.1.
Text of Minutes:

   [1]W3C

      [1] http://www.w3.org/

                                wai_ua

14 Aug 2008

   [2]Agenda

      [2] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0079.html

   See also: [3]IRC log

      [3] http://www.w3.org/2008/08/14-ua-irc

Attendees

   Present
          AllanJ, Jeanne, Simon_Harper, Mark_Hakkinen, Judy

   Regrets
          Alan_Cantor, Gregory_Rosmaita, Kelly_Ford, Jan_Richards

   Chair
          Jim_Allan_&_Judy_Brewer

   Scribe
          Jeanne_Spellman, Simon_Harper

Contents

     * [4]Topics
         1. [5]Charter Update
     * [6]Summary of Action Items
     _________________________________________________________



   <oedipus> i will be a little late to the meeting today - apologies -
   will join as ssoon as possible

   <AllanJ>
   [7]http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0050.ht
   ml

      [7] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0050.html

   <AllanJ> new combination
   [8]http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0090.ht
   ml

      [8] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0090.html

   <AllanJ> User has the option to have the keyboard commands for
   currently visible UI

   <AllanJ> or interactive CONTENT controls visually displayed in
   context or in a list.

   <AllanJ> Level A

   SH: concerns about "visible" UI

   JA: Understands your concern, but this has to do with interfaces
   where the accesskeys are not discoverable if you aren't using a
   screenreader. Many keyboard users don't use screenreaders.

   SH: What about an auditory browser that isn't using AT? We need to
   say that it should use the main interface technology of the browser.

   MH: In the old days, we provided a list of all the active UI keys,
   because the user could remap the keystroke. This worked visually and
   non-visually.
   ... Present a list of all the active key functions that are
   available and present them visually and to assistive technology.

   JB: It would be nice if it could be that simple, but let's assume
   that it can't be covered in one Success Criterion.

   <sharper> What about:

   <sharper> User has the option to have the keyboard commands for
   currently visible UI or interactive CONTENT controls presented in
   context or in a list, and using the main perceptual interface
   technology of the user agent.

   <sharper> OR

   <sharper> User has the option to have the keyboard commands for
   currently visible UI or interactive CONTENT controls presented in
   context or in a list, and using the main interface presentation
   technology of the user agent.

   JB: "in a list" is too vague.
   ... In the TEITAC discussion, it should be an OR relationship,
   either in context or embedded in the documentation somewhere. One is
   not a substitute for the other. '

   <AllanJ> Note: in context means next to the item, or an overlay (ala
   Office 2007).

   JB: There needs to be a contextual, by proximity display and not
   have to use a bunch of additional keystrokes. When a user has
   limited hand movement, it is important to have the shortcuts with a
   minimum of commands. It cannot require the user to navigate away and
   then return.

   <AllanJ> interactive CONTENT controls have direct UI keyboard
   commands (accesskey or

   <AllanJ> variation).

   <sharper> scribe Simon_Harper

   <sharper> scribe: Simon_Harper

   <sharper> scribenick: sharper

   <AllanJ> new wording: User has the option to have the keyboard
   commands for currently visible UI or interactive CONTENT controls
   visually displayed in context; e.g. next to the item or in an
   overlay.

   <AllanJ> sharper: how about a context menu list

   MH: Old software has a dynamic keylist

   <AllanJ> JB: needs to be very clear

   JB: How many keypresses to get this to work?

   MH: one keypress documented in the help.

   JB: need to get the form of words right

   MH: we need to think about the words? Could be a plug-in or some
   such?

   JB: everything up to 'control' is fine

   SH: could we use 'Dynamically presented'

   JB: The popular' underline solution' probably would not be
   considered Dynamic.

   MH: List comes in for people who have difficulty moving around the
   menus
   ... dynamic list would allow all, and hidden controls to be
   identified

   JB: How can we do it generically?

   JA: Remove 'visible'?

   <jeanne> scribenick:jeanne

   MH: In context, nearby or readily accessible

   <sharper> JB: People can misinterpret this option. Does not help.

   JB: Apart from this, is the proposal ok? We may need to research and
   come back to this. We need to check with the people who aren't here
   to get an idea of how to phrase this.

   MH: In the Guidelines, the requirement is that all shortcuts are
   available to an API.

   JA: We are trying to codify something that is simple in concept, but
   it is hard to write something that cannot be misconstrued in less
   than a paragraph.

   SH: A dynamic box suggests an active, connected structure or
   interface element.

   JA: the dynamic popup widget that Simon suggested. Mark's suggestion
   was that anything that could work would show up on the list.

   JB: We may be trying to solve the problem, instead we should
   emphasize"easily findable visually with one keystroke to activate"
   ... The principle is that you should be able to easily visually
   display, proximity of keystrokes
   ... 1. Visual display, 2. Easily discoverable, 3. Proximity of
   keystrokes to activate it.

   SH: Instead of "visual display" say "presentation".

   JB: But if it doesn't say visual, most developers will assume that
   having it available to Assistive Tech will suffice. That's not
   enough.

   <AllanJ> new wording, part 2:

   <AllanJ> User has the option to have the keyboard commands for
   currently visible UI or interactive CONTENT controls presented in a
   way that is easily discoverable without AT and easy to activate.

   MH: The key should be adjacent to the presentation of the menu item
   or command.
   ... This works well for visual interfaces, but we need to say that
   it is in close proximity in an audio presentation.

   JA: new proposal...
   ... User has the option to have the keyboard commands for currently
   visible UI or interactive CONTENT controls presented in a way that
   is easily discoverable without AT and easy to activate.
   ... an auditory browser could work the way JAWS does, where the key
   command is read right with the menu or link.

   <judy> jim: easy to discover/access in the presentation modality

   JA: It genericizes it. It assumes visable.

   <judy> jim: ...proximity in the presentation modality...

   SH: This is a good set of words. Maybe we can test it easily. Can
   the testing of this be automated?

   JB: We need this, because I have been in meetings with developers
   where a series of 15 keystrokes to invoke it -- especially opening
   menus, but for people with muscle diseases or spasticity it is very
   difficult.

   SH: Then say "activate with one keystroke"

   JB: I think this would help people with certain kinds of mobility
   disability a lot.
   ... A keystroke combination is going to be too difficult for the
   people with mobility disability.

   JA: There is a one key command that turns this on in the content or
   the user interface, then once it is turned on, then the other
   commands are all visible.

   <sharper> User has the option to have the keyboard commands for
   currently visible UI or interactive CONTENT controls presented in a
   way that is both easily discoverable without AT and can be activated
   within one keystroke.

   <mth> ...User has the option to have the keyboard commands for
   currently visible UI or interactive CONTENT controls presented in a
   way that is in close proximity to the control in the modality of
   presentation, easily discoverable without AT and easy to activate
   with a single keyboard command.

   JB: we need to have explanatory material and techniques for this.
   ... For a visual browser, this needs to be a visual mode, for an
   auditory browser, it must be an auditory mode,.

   User has the option to have the keyboard commands for currently
   available UI or interactive CONTENT controls presented in close
   proximity to the control in the modality of presentation; easily
   discoverable without AT; and easy to activate with a single
   keystroke.

   <sharper> User has the option to have the keyboard commands for
   currently available UI and interactive CONTENT controls presented
   that is: in close proximity to the control in the modality of
   presentation; easily discoverable without AT; and can be activated
   with one keystroke.

   User has the option to have the keyboard commands for currently
   available UI and interactive CONTENT controls be presented in close
   proximity to the control in the modality of presentation, easily
   discoverable without AT, and easy to activate with a single
   keystroke.

   User has the option to have the keyboard commands for currently
   available UI and interactive CONTENT controls be presented in close
   proximity to the control in the modality of presentation, easily
   discoverable without AT, and able to be activated with a single
   keystroke.

   JB: also include the note "For a visual browser, this needs to be a
   visual mode, for an auditory browser, it must be an auditory mode,."

   Resolved: User has the option to have the keyboard commands for
   currently available UI and interactive CONTENT controls be presented
   in close proximity to the control in the modality of presentation,
   easily discoverable without AT, and able to be activated with a
   single keystroke. with NOTE:For a visual browser, this needs to be a
   visual mode, for an auditory browser, it must be an auditory mode.

Charter Update

   <judy>
   [9]http://www.w3.org/WAI/UA/2008/draft_uawg_charter_26jun08.html

      [9] http://www.w3.org/WAI/UA/2008/draft_uawg_charter_26jun08.html

   <AllanJ> brb

   <judy> 2008 4Q

   <judy> 2009 1Q

   1. [Draft] in the title

   2. Mission or scope doesn't say "interoperability with Assistive
   Technology". Add phrase "and interoperability with Assistive
   Technology" after the parenthetical phrase.

   3. 31 August 2011 Charter expiration date.

   4. Requirements document is already done, so add "update" for
   requirements document

   5. Milestone section. Techniques and Test materials should be
   removed from milestone chart, because they aren't Rec Track
   documents.

   6. Fix timeline coverage - convert to Quarter instead of Monthly
   dates.

   7. change date to:

   Q3 2008: publish new Working Draft of UAAG

   Q3 2009: last Call

   Q4 2009: Candidate Recommendation

   Q2 2010: Proposed Rec

   Q3 2010: Rec

   <scribe> ACTION: JA will consolidate the proposals and notes for
   Guideline 4.1. [recorded in
   [10]http://www.w3.org/2008/08/14-ua-minutes.html#action01]

Summary of Action Items

   [NEW] ACTION: JA will consolidate the proposals and notes for
   Guideline 4.1. [recorded in
   [11]http://www.w3.org/2008/08/14-ua-minutes.html#action01]

   [End of minutes]

Received on Sunday, 17 August 2008 22:56:15 UTC