W3C WBS Home

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:

  1. ACTION-481 - Rewrite 3.3.4 to remove 'benefit accessibility'
  2. 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

ChoiceAll 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

ChoiceAll 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 ATAGComments 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

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. Kelly Ford <kelly.ford@microsoft.com>
  6. Peter Parente <pparent@us.ibm.com>
  7. Simon Pieters <simonp@opera.com>
  8. Takeshi Kurosawa <kurosawa-takeshi@mitsue.co.jp>
  9. Alan Cantor <alan@cantoraccess.com>
  10. Jeanne F Spellman <jeanne@w3.org>
  11. Kimberly Patch <Kim@redstartsystems.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


Completed and maintained by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.123 2013-09-26 09:46:56 dom Exp $. Please send bug reports and request for enhancements to dom@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)