w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire UAWG Survey for 13 January 2011
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 2011-01-11 to 2011-01-21.
4 answers have been received.
Jump to results for question:
- ACTION-481 - Rewrite 3.3.4 to remove 'benefit accessibility'
- ACTION-480 - Rewrite 3.3.2 to mirror ATAG
1. ACTION-481 - Rewrite 3.3.4 to remove 'benefit accessibility'
current
3.3.4 (former 5.3.4) Centralized View: There is a centralized view of all features of the user agent that benefit accessibility, in a dedicated section of the documentation. (Level AAA)
Proposed
3.3.4 Centralized View: There is a dedicated section of the documentation which presents a centralized of all features of the user agent necessary to meet the requirements of this document.. (Level AAA)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 2 |
| Recommend changes (see comments field) | 1 |
| The proposal needs more discussion (see comments field) | |
| Disagree with the proposal | 1 |
| Neutral - will accept the consensus of the group |
Details
| Responder | ACTION-481 - Rewrite 3.3.4 to remove 'benefit accessibility' | Comments 3.3.4 |
|---|---|---|
| Simon Harper | Accept the proposal | |
| Greg Lowney | Recommend changes (see comments field) | "a centralized of" should be "a centralized list of" or "a centralized list or description of". Or I suppose it could be "a centralized view of", although personally I don't like the term view in this context because it sounds interactive and/or visual. Could it be simplified by changing "There is a dedicated section...which presents" to "A dedicated section...presents"? Just an aside, would this mean that the accessibility section of a product's documentation needs to list the fact that it complies with standards for HTML, CSS, SVG, etc.? Of course, no user agent actually does fully comply with all those standards, so do we expect them to say they "substantially" comply with or implement them? |
| Jan Richards | Accept the proposal | |
| Markku Hakkinen | Disagree with the proposal | Can "this document" be replaced with the UAAG document title? Sometimes, when presenting guidelines as part of a class, for example, guidelines are presented out of the context of the document on a slide, "this document" may not be obvious (of course should be explained by instructor, but clear definition of "this document" shouldn't hurt). |
2. ACTION-480 - Rewrite 3.3.2 to mirror ATAG
current
3.3.2 (former 5.3.2) Document Accessibility Features: All user agent features that benefit accessibility are documented. (Level A)
Proposed
(this is a slight rewording of ATAG 4.2.1)
3.3.2 All features that are necessary to meet the requirements of this document (e.g. keyboard shortcuts, text search, etc.) are documented.
Current Intent of Success Criterion 3.3.2 (former 5.3.2) :
User agent documentation that includes listings and descriptions of features supporting or benefiting accessibility permits users to have access to a description of accessibility and compatibility features. This benefits all users with disabilities who may require assistance in identifying which accessibility features may be present or how to configure those features to work with assistive technology.
The user should be able to easily discover detailed information about the user agent’s adherence to accessibility standards, including those related to content such as HTML and WAI-ARIA, platform standards such as MSAA or JAA, and third-party standards such as ISO 9241-171, and should be able to do so without installing and testing the accessibility features.
Proposed Intent
User agent documentation that includes listings and descriptions of
features supporting or benefiting accessibility permits users access
to a description of accessibility and compatibility features. These
features fall into two groups:
(1) those which have been explicitly
created to aid accessibility, possibly in an attempt to follow
guidelines such as these; or
(2) those which assist accessibility but
emerge from other functionality not originally created for
accessibility purposes. Further, these accessibility benefits may be
explicit such as the ability to control the User Agent from the
keyboard; or implicit such as the ability to style a page based on a
user supplied style sheet.This benefits all users with disabilities
who may require assistance in identifying which accessibility features
may be present or how to configure those features to work with
assistive technology.
The user should be able to easily discover detailed information about the user agent’s adherence to accessibility standards, including those related to content such as HTML and WAI-ARIA, platform standards such as MSAA or JAA, and third-party standards such as ISO 9241-171, and should be able to do so without installing and testing the accessibility features.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 1 |
| 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 | ACTION-480 - Rewrite 3.3.2 to mirror ATAG | Comments 3.3.2 |
|---|---|---|
| Simon Harper | Accept the proposal | |
| Greg Lowney | Recommend changes (see comments field) | The proposed SC is fine, but I recommend the Intent section be reworked to use simpler sentences that would be far less imposing on the reader. For the first sentence is long, complex, and difficult to read, yet it really only says "Listing accessibility features gives the user descriptions of accessibility features", which essentially says nothing. Similarly, as the Intent section is not normative, there's no need to use long, technical terms such as "features supporting or benefiting accessibility" when "accessibility features" would do; if in doubt, we can link to the definition, or explain it in a way that doesn't clutter the main flow of the sentence. For example, how about something like: "Listing a product's accessibility features in a single place makes it much easier for users to find the features that can help them, especially if they didn't already know about those features or didn't know what they were called. At minimum list those features that directly contribute to meeting this standard, but it will be more helpful if you also list any additional features that are particularly useful for people with disabilities. Note that some of these features may have been added specifically for accessibility (e.g. the ability to force high contrast, or compatibility with assistive technology) while others may be mainstream features that happen to provide significant accessibility benefits (e.g. keyboard access, or the ability to provide a customized style sheet)." |
| Jan Richards | Recommend changes (see comments field) | I like everything except the last paragraph of the intent, which seems like a related but separate issue. |
| Markku Hakkinen | The proposal needs more discussion (see comments field) | Same as prior comment re "This document". Regarding Proposed Intent. Reword first sentence: User agent documentation that includes listings and descriptions of features supporting or benefiting accessibility permits users a common means to identify features available to support specific accessibility needs. |
More details on responses
- Simon Harper: last responded on 12, January 2011 at 09:24 (UTC)
- Greg Lowney: last responded on 12, January 2011 at 21:00 (UTC)
- Jan Richards: last responded on 13, January 2011 at 17:13 (UTC)
- Markku Hakkinen: last responded on 13, January 2011 at 17:27 (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