- From: Gregory Rosmaita <gregory.rosmaita@gmail.com>
- Date: Thu, 26 Aug 2010 15:00:48 -0400
- 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