w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
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:
- Proposal 2.1.1 Platform Accessibility Architecture
- Proposal for 2.1.2 Name, Role, State, Value, Description
- Proposal for 2.1.3 Accessible Alternative
- Proposal for 2.1.4 Programmatic Availability of DOMs
- Proposal for 2.1.5 Write Access
- Proposal for 2.1.6 Properties
- 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
| Choice | All 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 Architecture | Comments 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
| Choice | All 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, Description | Comments 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
| Choice | All 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 Alternative | Comments 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
| Choice | All 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 DOMs | Comments 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
| Choice | All 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 Access | Comments 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
| Choice | All 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 |
Details
| Responder | Proposal for 2.1.6 Properties | Comments 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
| Choice | All 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 |
Details
| Responder | Proposal for 2.1.7 Timely Communication | Comments 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
- Jan Richards: last responded on 5, August 2010 at 15:18 (UTC)
- Greg Lowney: last responded on 26, August 2010 at 06:22 (UTC)
- Kelly Ford: last responded on 26, August 2010 at 14:48 (UTC)
- Markku Hakkinen: last responded on 26, August 2010 at 15:52 (UTC)
- Kimberly Patch: last responded on 26, August 2010 at 17:31 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project