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

minutes: UAAG Teleconference 2010-08-26 [draft]

From: Gregory Rosmaita <gregory.rosmaita@gmail.com>
Date: Thu, 26 Aug 2010 15:00:48 -0400
Message-ID: <AANLkTi=grjKRyP9Qt7qiLQ4A4JKM-np8O9eUAMCYcmm-@mail.gmail.com>
To: w3c-wai-ua@w3.org
aloha!

minutes from the 26 August 2010 User Agent Accessibility Guidelines
Working Group Teleconference are available as hypertext from:

http://www.w3.org/2010/08/26-ua-minutes.html

as an IRC log from:

http://www.w3.org/2010/08/26-ua-irc

and as plain text following my signature -- many thanks to GregL
who did the vast bulk of the actual minuting...

please report any errors, corrections, mis-attributions,
clarifications, and the like by replying-to this announcment
on-list...

note, as well, that the following action items were assigned at the
2010-08-26 telecon:


   * ACTION-433: jallan to word smith
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq6 for 3.6.1
   * http://www.w3.org/2010/08/26-ua-minutes.html#action01
   * http://www.w3.org/WAI/UA/tracker/actions/433

   * ACTION-434: jeanne to update document for 3.6.2 with the edits from
   Greg in results of
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq7
   * http://www.w3.org/2010/08/26-ua-minutes.html#action02
   * http://www.w3.org/WAI/UA/tracker/actions/434

   * ACTION-435: Gregory - propose SC and intent for 3.6.3 based on WBS
   survey and feedback to list
   * http://www.w3.org/2010/08/26-ua-minutes.html#action03
   * http://www.w3.org/WAI/UA/tracker/actions/435

   * ACTION-436: jallan rewrite 3.1.4 based on comments
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq9 and
   comments here
   * http://www.w3.org/2010/08/26-ua-minutes.html#action04]
   * http://www.w3.org/WAI/UA/tracker/actions/436

   * ACTION-437: jeanne change in 3.11.1 'content focus' to 'keyboard
   focus'
   * http://www.w3.org/2010/08/26-ua-minutes.html#action05
   * http://www.w3.org/WAI/UA/tracker/actions/437

   * ACTION-438: Greg to create another intent example for 3.11.1 that
   talks through what happens when the UA displays a Web page for the
   first time. That is, focus is on the document as a whole so pressing
   Space scrolls, pressing tab move to the first focusable element, etc.
   * http://www.w3.org/2010/08/26-ua-minutes.html#action07
   * http://www.w3.org/WAI/UA/tracker/actions/438

   * ACTION-439: jeanne to replace intent of 2.1.1. to include Assistive
   technologies often use a combination of methods to get information
   about, and manipulate, a user agent's user interface and the content
   it's rendering. These methods include DOMs, accessibility APIs such as
   MSAA or JAA, general-purpose platform APIs such as those used to
   determine a window's title, application-specific APIs that...
   * http://www.w3.org/2010/08/26-ua-minutes.html#action08
   * http://www.w3.org/WAI/UA/tracker/actions/439


     _________________________________________________________________

                                   - DRAFT -

       User Agent Accessibility Guidelines Working Group Teleconference

26 Aug 2010

Agenda
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0052.html

   See also: IRC log http://www.w3.org/2010/08/26-ua-irc

Attendees

   Present
          AllanJ, Greg, Gregory_Rosmaita, Jan, Jeanne, Kim

   Regrets
          MarkkuH, KFord, PLauke

   Chair
          Jim_Allan

   Scribe
          Greg, oedipus

Contents

     * Topics
         1. UAAG Review of PF Keyboard Access Requirements
         2. Writers Meeting Survey#2
            http://www.w3.org/2002/09/wbs/36791/20100802-2/
         3. 3.6.3
         4. Writers Meeting Survey#3
            http://www.w3.org/2002/09/wbs/36791/20100802-3/
     * Summary of Action Items
     _________________________________________________________________

   <trackbot> Date: 26 August 2010

   <oedipus> agenda adendum request: UAAG Review of PF Keyboard Access
   Requirements
   (http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements)

   <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

UAAG Review of PF Keyboard Access Requirements

   <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

   <oedipus>
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0058.html

   <oedipus> Requirement 1: A device independent means to activate an
   access command.

   <oedipus> Requirement 2: Ability for an author to define a default
   access command mapping, and for a user to override the default
   mapping.

   <oedipus> Requirement 3: Access commands should default to focus
   behaviour, ability for authors to specify whether the default
   behaviour focuses or activates the target, and for a user to overwrite
   any author specified or default behaviour.

   <oedipus> Requirement 4: Ability for an author to provide a
   description for an access command assignment.

   <oedipus> Requirement 5: Ability to specify the target elements that
   will respond to an access command, based on their id reference.

   <oedipus> Requirement 6: Ability to specify target elements in terms
   of their role, or implied ARIA semantics for the role if not
   overridden by ARIA.

   <oedipus> Requirement 7: Ability to specify a custom order for cycling
   through multiple objects attached to a single access command.

   <oedipus> Requirement 8: As long as the document is loaded in the
   browser, user agents must be able to return the user to their previous
   place in the navigation sequence.

   <oedipus> Requirement 9: Access command mappings should be available
   at the beginning of the document.

   <oedipus> proposed first draft of "Access Element: Enabling Generic
   Document Accessibility"
   http://lists.w3.org/Archives/Public/www-archive/2010May/att-0020/acces
   s-element-20100519.html

   <inserted> SCRIBENICK: Greg

   Gregory posted a list of 9 requirements that PF has gathered for HTML5
   keyboard access features.

   Before these are taken to accessibility task force, they want to
   ensure that UA's more recent work is reflected in the requirements.

   <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

   Kim asks if UA's "direct access to any element" should be included;
   Gregory thinks item 5 would cover that.

   Originally HTML5 had no accesskey or tabindex, so PF asked them to
   consider use of the access module, which was rejected.

   A new proposal has too much complexity, such as author defined
   pseudo-cascade of access keys without any guidance on how to handle
   the cascade.

   Gregory offered to serve as a conduit to the HTML accessibility task
   force.

   Jim points out that UA work applies to both UA UI and content, whereas
   currently the list is only addressing content.

   <AllanJ> gl: the lines between the UI and content interfaces get
   blurry

   Greg points out that there is no clear distinction between content and
   UI anymore, as they're often implemented by the same code.

   Gregory would like to treat them the same, but the HTML5 working group
   may not approve of that approach.

   <oedipus> thanks, y'all

   <oedipus>
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0058.html

Writers Meeting Survey#2 http://www.w3.org/2002/09/wbs/36791/20100802-2/

   <oedipus> http://www.w3.org/2002/09/wbs/36791/20100802-2/results

   <oedipus> 3.6.1 configure text
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.html#gl-text-config

   <oedipus> for 3.6.1 i intended to propose: "In order to better suit
   individual visual needs, some users will need to increase the size of
   the text, change the font in which the text is rendered and/or change
   the background-and-foreground color combinations in order to make the
   text usable by that user."

   Here's the existing draft wording:

   3.6.1 Configure Text: The user can globally set the following
   characteristics of visually rendered text content, overriding any
   specified by the author or user agent defaults (Level A):

   * (a) text scale (i.e., the general size of text) ,

   * (b) font family, and

   * (c) text color (i.e., foreground and background).

   * Intent of Success Criterion 3.6.1:

   There are many types of low vision, with different needs for font
   size, font resolution, and color contrast. Some users want to reduce
   the font size to decrease the need to scroll the content.

   * Examples of Success Criterion 3.6.1:

   o Lee has low vision from albinism and has difficulty with screen
   resolution and brightness. She changes all text to 16 pt Palatino
   font, with white text on a black background. The serif Palatino font
   has character spacing that resolves better for her vision. The white
   on black reduces glare.

   <AllanJ> ACTION: jallan to word smith
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq6 for 3.6.1
   [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action01]

   <trackbot> Created ACTION-433 - Word smith
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq6 for 3.6.1
   [on Jim Allan - due 2010-09-02].

   <oedipus> 3.6.2. Preserve Distinctions
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.html#gl-text-config

   General agreement on the proposed change adding to Intent: ", and
   because some content may be authored in a way that would make it
   difficult or impossible to understand when if font distinctions were
   hidden."

   <oedipus> plus 1 to proposed change

   <oedipus> 3.6.2. Preserve Distinctions

   <jeanne> ACTION: jeanne to update document for 3.6.2 with the edits
   from Greg in results of
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq7 [recorded
   in http://www.w3.org/2010/08/26-ua-minutes.html#action02]

   <trackbot> Created ACTION-434 - Update document for 3.6.2 with the
   edits from Greg in results of
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq7 [on Jeanne
   Spellman - due 2010-09-02].

3.6.3

   Current draft wording:

   3.6.3 Option Range: The range of options for each text characteristic
   includes at least (Level A):

   * (a) the range offered by global preference settings supported by the
   operating environment (i.e configured though the Control Panel or
   System) utility, or

   * (b) if no such utility is available, the range supported by the
   conventional APIs of the operating environment for drawing text.

   * Intent of Success Criterion 3.6.3:

   Users need to be able to access the full range of text characteristics
   that the operating system supports. The full range may be determined
   by the operating environment (as determined by the settings). If
   platform does not provide a range of text characteristics in the
   control panel, then whatever text characteristics are supported by
   drawing programs for that operating environment,...

   scribe: must be made available to the user.

   * Examples of Success Criterion 3.6.3:

   o Browser A supports only 3 font sizes: Small, Medium, and Large. Lee,
   who has low vision, needs to use a font size of 16 pt, which is
   between the medium and large sizes. Browser A provides an option to
   override the 3 font sizes with the operating system font range, so
   that Lee can select the 16 pt font size she needs.

   <oedipus> 3.6.3. Option Range
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.html#gl-text-config

   <oedipus> http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq8

   Jan points out the SC is about range (min to max), but the example is
   about number of increments, which is a separate issue.

   <oedipus> GL: most graphical OSes DON'T have limited set of font sizes
   they support - no difficulty in UA UI interface offering small or
   large

   (That is, *don't* have a limited set of font sizes they support.)

   Thus there is no technical difficulty for UA to offer an extremely
   wide range of options for font size.

   <oedipus> fine tune control (by increment) - relative control (max min
   and preset increments) ?

   Jim: The SC doesn't provide any specific requirements for size range,
   other than what the platform supports.

   Jeanne: knows of no research on minimum range requirements.

   We need to decide if it sufficient to require a range, without
   addressing increments within that range.

   <oedipus> GL: jan pointed out that example discusses increments -
   haven't heard anyone formally say put in an SC for this

   <oedipus> fine tune control (by increment) - relative control (max min
   and preset increments) ?

   Is it acceptable for UA to offer only very small and very large, for
   example, without anything in between?

   <oedipus> user control (enter point size) fine tune control (increase
   by supported increments) relative control (max, min, preset
   increments)

   Consensus seems to be that it would be unacceptable to have, for
   example, just Tiny, Normal, and Huge.

   <oedipus> user control (enter point size) fine tune control (increase
   by supported increments) relative control (max, min, preset
   increments)

   <oedipus> user control (user decides precisely what setting), fine
   tune control (increase or decrease by supported increments), relative
   control (gross manipulation: max to min, preset increments)

   If we only change the Intent and Examples, but leave the SC as is,
   then the normative requirements would still be met with very minimal,
   unfriendly options (such as just Tiny, Normal, Huge). It sounds like
   we want to redo the SC.

   <oedipus> ACTION: Gregory - propose SC and intent for 3.6.3 based on
   WBS survey and feedback to list [recorded in
   http://www.w3.org/2010/08/26-ua-minutes.html#action03]

   <trackbot> Created ACTION-435 - - propose SC and intent for 3.6.3
   based on WBS survey and feedback to list [on Gregory Rosmaita - due
   2010-09-02].

   <oedipus> 3.1.4. Rendering Alternateive (Enhanced) Intent
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.html#gl-access-alternative-content

   <oedipus> GL: looks like mostly editorial; although felt that intent
   restated SC instead of explaining user benefit;

   <AllanJ> 3.1.4 Rendering Alternative (Enhanced): Provide the user with
   the global option to configure a cascade of types of alternatives to
   render by default, in case a preferred type is unavailable. If the
   alternative content has a different height or width, then the user
   agent will reflow the viewport. (Level AA) * Intent of Success
   Criterion 3.1.4: For a give piece of non-text content...

   <AllanJ> ...the author may have provide one or several alternatives.
   For example, an image may have different versions based on resolution,
   `alt text' (@alt) or a link to a long description (@longdesc). A video
   may have bandwidth alternatives, caption files in different languages,
   audio descriptions in different languages. There may be others. The
   user is able to choose which item(s) to render by...

   <AllanJ> ...default, and specify the order of the cascade of
   alternatives to be rendered if the author did not provide a type of
   alternative. * Examples of Success Criterion 3.1.4: o Mary has a
   learning disability. She finds looking at images on a webpage very
   distracting. Mary would like to see all images rendered in the
   following order. First, for images with long descriptions have...

   <AllanJ> ...the long description rendered in place of the image. If
   the long description does not exit, she wants the `alt text' to be
   rendered. If neither is available, Mary wants the file name rendered.
   Added functionality would allow Mary to right click (context menu) on
   an image to list and select the rendering of the available
   alternatives (thumbnail, original size, full screen,...

   <AllanJ> ...low...

   <oedipus> GL: for given piece of content -- example says "user" -
   doesn't express to user what is required/constitutes success

   <AllanJ> ...resolution, high resolution, alt text, long description,
   file name) o @@ Editors' Note: where do we put the ability for the
   user to individually pick an image and have the image displayed. It
   should not have to be an all or nothing. o Juan is hard of hearing. He
   wants to always see video on the page. Also, Juan would like the
   Spanish language track used if available,...

   <AllanJ> ...along with Spanish captions as a default. If these are not
   available, he wants to see the video with English audio and captions.
   If no captions are available Juan wants the the video and English
   audio. Added functionality would allow Juan to right click (context
   menu) on an video to list and select the rendering of the available
   alternatives (still image, caption languages,...

   <AllanJ> ...audio languages, audio-description languages)

   <oedipus> GL: intent misses point; intent should be written in 2 parts

   <oedipus> GL: should state why users with disabilities need and not
   describe functionality

   I think the Intent should be rewritten to start with and emphasize why
   users with disabilities need this functionality, which is mostly
   obscured by the current text.

   <oedipus> GL: when X happens, is a problem, here is how to get around
   it; users often need to do Y in order to accomplish task Z

   <oedipus> GL: problem is this, here is solution

   <oedipus> GL: intent paragraph good information, just not presented
   correctly

   <AllanJ> ACTION: jallan rewrite 3.1.4 based on comments
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq9 and
   comments here [recorded in
   http://www.w3.org/2010/08/26-ua-minutes.html#action04]

   <trackbot> Created ACTION-436 - Rewrite 3.1.4 based on comments
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq9 and
   comments here [on Jim Allan - due 2010-09-02].

   The rest of my comments were purely editorial/wordsmithing.

   <oedipus> General 3.11. Intent
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.html#gl-focus-mechanism

   <oedipus> JA: take intent of 3.11.1 and merge with GL 3.11 and say
   that is good for all and add examples for specific SC?

   <oedipus> GL: do we need to repeat stuff for every SC? do you need to
   read 3.11 in order to understand 3.11.1 -- could just be a simple link
   back to GL

   <oedipus> GL: each intent start with or end with "see GL x.x for a
   general introduction to mechanisms"

   The Intent of each SC in 3.11 could start or end with a sentence such
   as "See the Intent for Guideline 3.11 for an introduction to the
   concept of focus mechanisms and their importance."

   <oedipus> plus 1 to Greg's suggestion

   <oedipus> JA: need something new, or move part to intent of GL?

   That is, factor out all the common Intent material that applies to
   every SC in 3.11, move that into the Intent for Guideline 3.11, and
   for the Intent for 3.11.1 just put a very narrow discussion of what
   makes this SC different from the others in this section.

   <inserted> scribenick: oedipus

   JS: could link to 3.11.1 in resources -- keep 3.11 as overall intro
   and then have 3.11.x link to 3.11

   GL: no intent for GL, but only SC?

   JS: want intents for all GLs

   <inserted> scribenick: Greg

   Jeanne we should have Intent paragraphs for all or none of the
   Guidelines, but be consistent.

   <inserted> scribenick: oedipus

   GL: as long as referenced, doesn't matter where it is, info needs to
   be linked;
   ... 3.11.1 talks about things that aren't part of 3.11 -- cursors
   aren't part of req for 3.11 -- content focus may or may not have
   visual indicator (cursor)
   ... 3.11.1 says need at least 1 kind of focus

   JA: doesn't say has to be visible

   GL: need to review all focus definitions -- are they complete?

   KP: should be in there

   JA: "need to find HREFs and fix them" -- all defs of cursors, and
   similar appear before that anchor; don't talk about content focus
   ... no "content focus" in list

   KP: content focus is keyboard focus

   GL: whether content pane or menu, takes focus; at other times does
   not; focus in dialog box ontop of a menu, active focus on menu; close
   menu, inactive focus on menu

   JS: explainatory chart at beginning of focus section
   ... input focus and keyboard focus most common; also pointer focus
   ... sometimes want to specify active or inactive focus

   GL: maybe need a new focus section?

   JS: should be "at least 1 keyboard focus "

   GL: haven't normalized all of the defined terms

   JA: operationally, this is the outline around an active element in
   viewport that is keyboard focused/active focused; talking specifically
   about enabled elements -- if have page with enabled elements, focus
   must be provided so user knows what can act upon

   GL: has to be concept if there are elements that can take kbd input,
   UA has to know which element receives event if key invoked
   ... does imply "focus being on something" like first input field

   <AllanJ> ACTION: jeanne change in 3.11.1 'content focus' to 'keyboard
   focus' [recorded in
   http://www.w3.org/2010/08/26-ua-minutes.html#action05]

   <trackbot> Created ACTION-437 - Change in 3.11.1 'content focus' to
   'keyboard focus' [on Jeanne Spellman - due 2010-09-02].

   JA: def of "point of regard" is "AT-focus" -- AT keeps track of where
   one is going, but doesn't necessarily show on screen; keyboard focus,
   UA has to know which actionable item will receive action or input

   GL: was "keyboard focus in content"

   KP: we changed all these -- what happened to that version?

   JS: 23 August 2010 draft

   KP: focus defs all correct in 2010-08-23 draft

   http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100823.ht
   ml

   <AllanJ>
   http://www.w3.org/WAI/UA/2010/ED-IMPLEMENTING-UAAG20-20100823/

   KP: made other edits requested by GL

   trackbot, close action-437

   <trackbot> ACTION-437 Change in 3.11.1 'content focus' to 'keyboard
   focus' closed

   action-437: OBE (reviewing wrong draft - fixes in 2010-08-23 draft)

   <trackbot> ACTION-437 Change in 3.11.1 'content focus' to 'keyboard
   focus' notes added

   <Greg> I'll write an example for 3.11.1 that talks through what
   happens when the UA displays a Web page for the first time. That is,
   focus is on the document as a whole so pressing Space scrolls,
   pressing tab move to the first focusable element, etc.

   <AllanJ> ACTION: GregL to create another intent example for 3.11.1
   that talks through what happens when the UA displays a Web page for
   the first time. That is, focus is on the document as a whole so
   pressing Space scrolls, pressing tab move to the first focusable
   element, etc. [recorded in
   http://www.w3.org/2010/08/26-ua-minutes.html#action06]

   <trackbot> Sorry, couldn't find user - GregL

   <AllanJ> ACTION: Greg to create another intent example for 3.11.1 that
   talks through what happens when the UA displays a Web page for the
   first time. That is, focus is on the document as a whole so pressing
   Space scrolls, pressing tab move to the first focusable element, etc.
   [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action07]

   <trackbot> Created ACTION-438 - Create another intent example for
   3.11.1 that talks through what happens when the UA displays a Web page
   for the first time. That is, focus is on the document as a whole so
   pressing Space scrolls, pressing tab move to the first focusable
   element, etc. [on Greg Lowney - due 2010-09-02].

Writers Meeting Survey#3 http://www.w3.org/2002/09/wbs/36791/20100802-3/

   http://www.w3.org/2002/09/wbs/36791/20100802-3/results

   <Greg> Current wording:

   <Greg> 2.1.1 Platform Accessibility Architecture: Support an platform
   accessibility architecture relevant to the operating environment.
   (Level A)

   <Greg> * Intent of Success Criterion 2.1.1:

   <Greg> Computers, including many smart phones, have accessibility
   features built into the operating system. Some well-known APIs for the
   Windows operating system are: MSAA, iAccessible2, UIAutomation,
   [more]. Where ever technically possible, support the existing
   accessibility APIs.

   <Greg> * Examples of Success Criterion 2.1.1 :

   <Greg> o Browser A is developing a new user interface button bar for
   their Microsoft Windows product. The developer codes a call to the
   MSAA API for the functionality.

   proposal 2.1 1.
   http://www.w3.org/2002/09/wbs/36791/20100802-3/results#xq1

   ->
   http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.ht
   ml#guide-AT-access 2.1.1. Platform Accessibility Architecture

   note: IA2 is IAccessible2, not iAccessible2

   http://a11y.org/ia2-spec

   ATK/AT-SPI (accessible toolkit/assistive technology service provider
   interface) should be mentioned http://a11y.org/atspi

   <Greg> "Assistive technologies often use a combination of methods to
   get information about, and manipulate, a user agent's user interface
   and the content it's rendering. These methods include DOMs,
   accessibility APIs such as MSAA or JAA, general-purpose platform APIs
   such as those used to determine a window's title, application-specific
   APIs that are typically a last resort when an application does...

   <Greg> ...not make all information available through the former means,
   and hard-coded heuristics. It is the user agent's responsibility to
   make the necessary information and facilities available through the
   appropriate corresponding means. Platform accessibility API is
   particularly important because it provides common functionality across
   all (or at least all well behaved) applications running on...

   <Greg> ...the platform, reducing the amount of special-casing the
   assistive technology has to implement for each of the hundreds of
   applications it supports..."

   <AllanJ> AX-API accessibility API for Mac

   IA2 dev in harmony with AT-SPI dev

   sounds good

   ->
   http://accessibility.linuxfoundation.org/a11yspecs/atspi/adoc/a11y-dom
   -apis.html Accessibility and DOM API Comparisons

   <AllanJ> ACTION: jeanne to replace intent of 2.1.1. to include
   Assistive technologies often use a combination of methods to get
   information about, and manipulate, a user agent's user interface and
   the content it's rendering. These methods include DOMs, accessibility
   APIs such as MSAA or JAA, general-purpose platform APIs such as those
   used to determine a window's title, application-specific APIs that...
   [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action08]

   <trackbot> Created ACTION-439 - Replace intent of 2.1.1. to include
   Assistive technologies often use a combination of methods to get
   information about, and manipulate, a user agent's user interface and
   the content it's rendering. These methods include DOMs, accessibility
   APIs such as MSAA or JAA, general-purpose platform APIs such as those
   used to determine a window's title, application-specific APIs that...
   [on Jeanne Spellman - due 2010-09-02].

   <AllanJ> ...are typically a last resort when an application does...
   ...not make all information available through the former means, and
   hard-coded heuristics. It is the user agent's responsibility to make
   the necessary information and facilities available through the
   appropriate corresponding means. Platform accessibility API is
   particularly important because it provides common functionality
   across...

   <AllanJ> ...all (or at least all well behaved) applications running
   on... ...the platform, reducing the amount of special-casing the
   assistive technology has to implement for each of the hundreds of
   applications it supports

   http://www.w3.org/2002/09/wbs/36791/20100802-3/results#xq2

   <Greg> Current wording:

   <Greg> 2.1.2 Name, Role, State, Value, Description: For all user
   interface components including the user interface, rendered content,
   generated content, and alternative content, make available the name,
   role, state, value, and description via an platform accessibility
   architecture. (Level A)

   <Greg> * Intent of Success Criterion 2.1.2:

   <Greg> The information that assistive technology requires is the

   <Greg> o Name (component name)

   <Greg> o Role (purpose, such as alert, button, checkbox, etc)

   <Greg> o State (current status, such as busy, disabled, hidden, etc)

   <Greg> o Value (information associated with the component such as, the
   data in a text box, the position number of a slider, the date in a
   calendar widget)

   <Greg> o Description (user instructions about the component).

   <Greg> For every component developed for the user agent, pass this
   information to the appropriate accessibility platform architecture or
   application program interface (API). Embedded user agents, like media
   players can pass Name, Role, State, Value and Description via the
   WAI-ARIA techniques.

   ->
   http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.ht
   ml#guide-AT-access 2.1.2 Name, Role, State, Value, Description

   GL: suggested minor rewrite of paragraph

   <Greg> 1. I suggest rewriting the intent as:

   <Greg> Some assistive technology (such as speech recognition or macro
   utiliies) interacts with software on the user's behalf, and some (such
   as screen readers) need to conveys information about it to the user.
   To do this effectively, it needs the following information about each
   component of the user agent user interface or rendered content:

   <Greg> * Name (the brief name by which the user or documentation would
   refer to the component, e.g. for a button labeled "OK" the name would
   be "OK".)

   <Greg> * Role (the type of component in a generic sense, such as
   button, checkbox, alert, heading, etc.)

   <Greg> * State (whether the component is disabled, hidden, busy, etc.)

   <Greg> * Value (information associated with the component such as the
   data in a text box, the position number of a slider, or the date in a
   calendar widget)

   <Greg> * Description (user instructions about the component)."

   sounds good

   markuu's comment on 2.1.2 "change: Name (accessible name or label for
   the component) -- Rationale: simply stating "component name" might
   lead one to think SysGridView32 may be a valid component name."

   plus 1

   <Greg> No objections to the proposed rewrite of Intent.

   GL: description should be taken out of required list due to ambiguity
   of what means for diff standards -- non-existent in some

   <Greg> In my Intent rewrite I merely copied the previous definition of
   Description, but my 2nd and 3rd comments are about how that's actually
   problematic.

   http://www.w3.org/WAI/PF/aria/roles#Properties

   <Greg> If the definition of Description as user instructions is from
   ARIA, and we require it, does that mean every element needs to be
   marked up with user instructions?

   5.2.7.2. Description Computation An accessible description may be
   computed by concatenating the text alternatives for nodes pointed to
   by an aria-describedby attribute on the current node.

Summary of Action Items

   [NEW] ACTION: Greg to create another intent example for 3.11.1 that
   talks through what happens when the UA displays a Web page for the
   first time. That is, focus is on the document as a whole so pressing
   Space scrolls, pressing tab move to the first focusable element, etc.
   [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action07]
   [NEW] ACTION: GregL to create another intent example for 3.11.1 that
   talks through what happens when the UA displays a Web page for the
   first time. That is, focus is on the document as a whole so pressing
   Space scrolls, pressing tab move to the first focusable element, etc.
   [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action06]
   [NEW] ACTION: Gregory - propose SC and intent for 3.6.3 based on WBS
   survey and feedback to list [recorded in
   http://www.w3.org/2010/08/26-ua-minutes.html#action03]
   [NEW] ACTION: jallan rewrite 3.1.4 based on comments
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq9 and
   comments here [recorded in
   http://www.w3.org/2010/08/26-ua-minutes.html#action04]
   [NEW] ACTION: jallan to word smith
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq6 for 3.6.1
   [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action01]
   [NEW] ACTION: jeanne change in 3.11.1 'content focus' to 'keyboard
   focus' [recorded in
   http://www.w3.org/2010/08/26-ua-minutes.html#action05]
   [NEW] ACTION: jeanne to replace intent of 2.1.1. to include Assistive
   technologies often use a combination of methods to get information
   about, and manipulate, a user agent's user interface and the content
   it's rendering. These methods include DOMs, accessibility APIs such as
   MSAA or JAA, general-purpose platform APIs such as those used to
   determine a window's title, application-specific APIs that...
   [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action08]
   [NEW] ACTION: jeanne to update document for 3.6.2 with the edits from
   Greg in results of
   http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq7 [recorded
   in http://www.w3.org/2010/08/26-ua-minutes.html#action02]

   [End of minutes]
     _________________________________________________________________
Received on Thursday, 26 August 2010 19:01:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:39 UTC