W3C WBS Home

Results of Questionnaire UAWG Writers' Meeting followup #3

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: w3c-archive@w3.org, jeanne@w3.org

This questionnaire was open from 2010-08-04 to 2010-09-17.

5 answers have been received.

Jump to results for question:

  1. Proposal 2.1.1 Platform Accessibility Architecture
  2. Proposal for 2.1.2 Name, Role, State, Value, Description
  3. Proposal for 2.1.3 Accessible Alternative
  4. Proposal for 2.1.4 Programmatic Availability of DOMs
  5. Proposal for 2.1.5 Write Access
  6. Proposal for 2.1.6 Properties
  7. Proposal for 2.1.7 Timely Communication

1. Proposal 2.1.1 Platform Accessibility Architecture

See 2.1.1 Platform Accessibility Architecture Intent, Examples and Related Resources.

Summary

ChoiceAll responders
Results
Accept the proposal 1
Recommend changes (see comments field) 3
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group 1

Details

Responder Proposal 2.1.1 Platform Accessibility ArchitectureComments 2.1.1
Jan Richards Recommend changes (see comments field) Maybe a bit less MS specific in the intent itself.
"Where ever"=>Wherever
Greg Lowney Recommend changes (see comments field) 1. The Intent paragraph does not describe the intent of the SC: it adds notes but no explanation as to why UA should support the API listed, the benefit this produces for the user, or the relationship between the API in the 2nd sentence and the "accessibility features" listed in the 1st sentence. The current juxtaposition makes it sound like the API is there to support "accessibility features" in the operating system, which implies built-in tools but not third-party assistive technology.

2. In the example, note that the developers only need to do this explicitly if they're intentionally NOT using standard system controls (which would support the API automatically).
Kelly Ford Neutral - will accept the consensus of the group We can put this in but the next public draft needs to ask for feedback specifically here.
Markku Hakkinen Recommend changes (see comments field) I wonder if it is better to say "accessibility features and support for Assistive Technologies".

Change to:
Computers, including many smart phones, have accessibility features and support for Assistive Technologies built into the operating system.
Kimberly Patch Accept the proposal

2. Proposal for 2.1.2 Name, Role, State, Value, Description

See 2.1.2 Name, Role, State, Value, Description Intent, Examples and Related Resources.

Summary

ChoiceAll responders
Results
Accept the proposal 2
Recommend changes (see comments field) 2
The proposal needs more discussion (see comments field) 1
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder Proposal for 2.1.2 Name, Role, State, Value, DescriptionComments 2.1.2
Jan Richards Accept the proposal
Greg Lowney Recommend changes (see comments field) 1. I suggest rewriting the intent as:

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:
* 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".)
* Role (the type of component in a generic sense, such as button, checkbox, alert, heading, etc.)
* State (whether the component is disabled, hidden, busy, etc.)
* 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)
* Description (user instructions about the component)."

2. It read "Description (user instructions about the component)" and while I'm not sure about other API, in MSAA the Description attribute gives a textual description of the element's visual appearance rather than "user instructions". If we include Description among the required attributes, we have to find a meaning that works for all platform architectures.

3. In MSAA 2.0, the Description attribute is considered optional. That is, it's only appropriate for a subset of components. Therefore making it *required* by this SC may inappropriate or problematic.

4. I think this could really benefit from examples from the user's perspective, showing how the steps taken by UA to comply provide actual benefit to users of assistive technology.
Kelly Ford Accept the proposal
Markku Hakkinen Recommend changes (see comments field) 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.
Kimberly Patch The proposal needs more discussion (see comments field)

3. Proposal for 2.1.3 Accessible Alternative

See 2.1.3 Accessible Alternative Intent, Examples and Related Resources.

Summary

ChoiceAll responders
Results
Accept the proposal 2
Recommend changes (see comments field) 2
The proposal needs more discussion (see comments field) 1
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder Proposal for 2.1.3 Accessible AlternativeComments 2.1.3
Jan Richards Accept the proposal
Greg Lowney Recommend changes (see comments field) 1. This SC is not about "when circumstances do not allow direct accessibility to some items in the user agent" as the current Intent says. Rather, it's about "when a user interface component cannot be made compatible with assistive technology by adding support for an accessibiltiy API". And the solution is not to provide "an accessible option that will let them complete their task." I suggest something like:

"Users who rely on assistive technology need to be able to carry out all tasks provided by the user agent, just like everyone else. When a particular user interface component cannot support for the platform accessibiltiy architecture, and thus can't be made compatible with assistive technology, the user agent should let the user achieve the same goal using another component that IS fully accessible."

Kelly Ford The proposal needs more discussion (see comments field) Them in the last sentence should be change to the user or some other specific reference. but in general I'm fine with this.
Markku Hakkinen Recommend changes (see comments field) Change "yar" to "yaw"
Kimberly Patch Accept the proposal

4. Proposal for 2.1.4 Programmatic Availability of DOMs

See 2.1.4 Programmatic Availability of DOMs Intent, Examples and Related Resources.

Summary

ChoiceAll responders
Results
Accept the proposal 3
Recommend changes (see comments field) 2
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder Proposal for 2.1.4 Programmatic Availability of DOMsComments 2.1.4
Jan Richards Accept the proposal "It is the user agents"=>"It is the user agent's"
Greg Lowney Recommend changes (see comments field) 1. The Intent paragraph's sentence "It is the user agents responsibility to expose all relevant content to the platform accessibility api. Alternatively, the user agent must respond to requests for information from APIs." do not go with this SC. Consider rewriting as something like: "Therefore the user agent is responsible for making all of its DOMs, which are normally available to scripts, plug-ins, and add-ons, also available to assistive technology software."

2. In the Intent's first paragraph, the dichotomy between "accessibility APIs" and "native platform APIs" is false, as accessibility APIs may be implemented as native platform APIs. I think what was meant was probably "accessibility APIs such as MSAA or JAA, general-purpose platform APIs such as those used to determine a window's title, and application-specific APIs that are typically used as a last resort when an application does not make all information available through the former means."

"Like other software, 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 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. Because DOMs routinely provide fine-tuned and therefore much richer capabilities than the other methods, exposing its DOMs to assistive technology is an extremely important part of AT compatibility."

3. Example 1 should be deleted because it is not relevant to this SC, as it argues for exposing all information through the DOM, not for exposing the DOM to assistive technology (which is the point of this SC). Plus, it is generally impossible to "expose all information from all DOMs to the platform accessibility API" for the reason I described above: the very reason we want DOMs exposed to AT is because they provide a much more finely-tuned, richer, and more powerful interface than platform accessibility APIs. In the end this seems to be instructions for the AT.

4. The second example needs a lot of cleanup. Saying "the transition between DOMs is seamless and transparent to the user" is meaningless since DOMs are not normally visible to the user. Similarly, the sentence about keyboard access is unrelated to this SC and so just confuses things. I think the point you’re trying to make is that when assistive technology is providing the user with a view of all the content, using information it gathers through these various DOMs, it should be able to make the transition between them invisible to the user.

5. I'd add an example that is actually relevant to this SC, namely showing how AT uses a DOM to benefit the user. "Kasandra is using a screen reader as she browses the Web. When a sentence is read to her, she suspects that some of it might be in italics, so asks the screen reader to read it aloud indicating changes in font. Because font information is not included in the platform accessibility API, the screen reader accesses the DOM exposed by the browser, and from that is able to determine which phrases are italicized, bolded, and so forth."
Kelly Ford Accept the proposal
Markku Hakkinen Recommend changes (see comments field) Change (missing apostrophe):

"It is the user agent's responsibility..."
Kimberly Patch Accept the proposal

5. Proposal for 2.1.5 Write Access

See 2.1.5 Write Access Intent, Examples and Related Resources.

Summary

ChoiceAll responders
Results
Accept the proposal 3
Recommend changes (see comments field) 2
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder Proposal for 2.1.5 Write AccessComments 2.1.5
Jan Richards Accept the proposal
Greg Lowney Recommend changes (see comments field) Content is fine, but the style of the examples (essentially examples within examples) doesn't match that used most commonly. Consider changing to be more like the rest, e.g. change "A volume control slider in a media player can be set directly to the desired value, e.g. the user can speak 'Volume 35%'." to "When the user says the phrase 'Volume 35%' their speech input utility can programmatically set the value of the volume slider to 35%, rather than having to use trial and error by simulating mouse clicks or arrow presses to try to find the 35% point."
Kelly Ford Accept the proposal
Markku Hakkinen Recommend changes (see comments field) change programatic to programmatic as needed.
Kimberly Patch Accept the proposal

6. Proposal for 2.1.6 Properties

See 2.1.6 Properties Intent, Examples and Related Resources.

Summary

ChoiceAll responders
Results
Accept the proposal 2
Recommend changes (see comments field) 2
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

(1 response didn't contain an answer to this question)

Details

Responder Proposal for 2.1.6 PropertiesComments 2.1.6
Jan Richards Accept the proposal
Greg Lowney
Kelly Ford Recommend changes (see comments field) Proposed change to intent:

Intent of Success Criterion 2.1.6:
These properties are used by assistive technology to create alternative views of the user agent user interface and rendered content as well as allowing the user to interact with these items.
Markku Hakkinen Recommend changes (see comments field) change: "... to provide alternative means..." (remove allow)
Kimberly Patch Accept the proposal

7. Proposal for 2.1.7 Timely Communication

See 2.1.7 Timely Communication Intent, Examples and Related Resources.

Summary

ChoiceAll responders
Results
Accept the proposal 4
Recommend changes (see comments field)
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

(1 response didn't contain an answer to this question)

Details

Responder Proposal for 2.1.7 Timely CommunicationComments 2.1.7
Jan Richards Accept the proposal BTW: I notice the names throughout. Are they linked to personas? That might make sense. The EC AEGIS project developed some: http://www.aegis-project.eu/index.php?option=com_content&view=article&id=63&Itemid=53
Greg Lowney
Kelly Ford Accept the proposal
Markku Hakkinen Accept the proposal
Kimberly Patch Accept the proposal

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Jim Allan <jimallan@tsbvi.edu>
  3. Eric Hansen <ehansen@ets.org>
  4. Wayne Dick <wayneedick@gmail.com>
  5. Peter Parente <pparent@us.ibm.com>
  6. Simon Pieters <simonp@opera.com>
  7. Takeshi Kurosawa <kurosawa-takeshi@mitsue.co.jp>
  8. Alan Cantor <alan@cantoraccess.com>
  9. Jeanne F Spellman <jeanne@w3.org>
  10. Simon Harper <simon.harper@manchester.ac.uk>
  11. he wen <rockywen@tencent.com>
  12. Henny Swan <hswan@paciellogroup.com>
  13. Shaohang Yang <shaohang.ysh@alibaba-inc.com>

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.127 2015-02-04 08:52:34 carcone Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)