wai_ua

 

 

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

<AllanJ> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0050.html

<AllanJ> new combination 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> 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 http://www.w3.org/2008/08/14-ua-minutes.html#action01]