W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > January to March 2008

Re: EOWG's replies to WCAG WG resolutions of EOWG comments on May 2007 Draft of WCAG 2.0

From: Shawn Henry <shawn@w3.org>
Date: Fri, 11 Jan 2008 11:24:45 -0600
Message-ID: <4787A65D.90200@w3.org>
To: public-comments-wcag20@w3.org
Cc: "EOWG (E-mail)" <w3c-wai-eo@w3.org>

Dear WCAG WG,

Thank you for considering our comments on previous drafts of WCAG 2.0. Below are replies to the comments you sent on 11 December 2007 (archived at http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/). They are grouped in two sections: Need additional followup, EOWG accepts resolution.

Need additional followup:

Comment 4: use accessibility-supported technologies
http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0174.html

EOWG comment:
We are concerned that the following sentence is still difficult to parse: "Any information or functionality that is implemented in technologies that are not accessibility supported must also be available via technologies that are accessibility supported." Particularly, the phrasing of "accessibility supported technology" throughout is a difficult construct.
We suggest that using the phrase "technologies with accessibility support" may facilitate comprehension here, and possible everywhere that the current phrase "accessibility supported technologies" is used. Such replacement here would yield:
"Any information or functionality that is implemented in technologies without accessibility support must also be available via technologies with accessibility support."

WCAG reply:
Accessibility-supported is a descriptor that we use in many places and is defined in the glossary. It is a bit awkward to get used to at first but it is a critical concept and term for WCAG 2.0. Your rephrasing makes for an easier to read sentence but the concept is lost as a defined descriptor.

EOWG reply, Jan 2008: OK, we agree with having it as a defined descriptor. However, do need to correct the grammar. Change "supported" to "supporting" and hyphenate so it's: accessibility-supporting technologies.

---

Comment 19: distinction between blinking and flashing still isn't clear
http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0176.html

EOWG comment:
1. EOWG still feels like the distinction between blinking and flashing in WCAG 2.0 is difficult to ascertain, the definitions did little to help, and the specific technical language turned off some. While we realize you need precision in the technical specification, we encourage you to work on making these more approachable and easier to understand.
Please consider: ...
2. We assume that the word "flash" should be linked to its definition in the text of 2.3.1 and 2.3.2.

WCAG reply: We have changed the definitions to be technically accurate but easier to understand.

Current wording in WCAG 2.0:
* blink - switch back and forth between two visual states in a way that is meant to draw attention 
Note: See also flash (It is possible for something to be large enough and blink brightly enough at the right frequency to be also classified as a flash).
* flash - a pair of opposing changes in relative luminance which may cause seizures in some people if it is large enough and in the right frequency range
Note 1: See general flash threshold and red flash threshold for information about types of flash that are not allowed.
Note 2: See also blink.

EOWG reply, Jan 2008: EOWG does not feel that these definitions are adequate to clarify the distinction necessary for testability. Some specifics:

- As we understand it, the need to define blinking and flashing as distinct from each other in the context of the WCAG SC is whether or not the blinking/flashing is likely to cause seizures, versus just being distracting. You currently have this as part of the flash definition; how about adding that to the blink definition. For example, "blink - switch back and forth between two visual states in a way that is not likely to cause seizures"

- For the blink definition, we suggest deleting "in a way that is meant to draw attention" because the authors intentions cannot be determined by an outside party.

- Minor: The word used in the SC is "blinking" but the word in the glossary is "blink".

- The word "flash" is still not linked to its definition in the text of 2.3.1 and 2.3.2, and is not linked anywhere in the main part of the guidelines. Is this an error or is there a reason?

---

Comment 23: Please clarify [SC 3.1.4]
http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0180.html

EOWG Comment:
EOWG still finds this SC unnecessarily difficult to understand; the definition adds confusion and complication, and does not clarify the SC.
EOWG strongly suggests simplifying SC 3.1.4 to: "The expanded form or meaning of abbreviations is available." or "The expanded form or meaning of abbreviations is available to users."

WCAG Reply: We have revised SC 3.1.4 to read as follows:
3.1.4 Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available. (Level AAA)

EOWG reply, Jan 2008: Accept, and request that WCAG WG considers further simplifying the wording in related SC. Note that while this is not a substantive issue, it is a significant issue in simplifying WCAG and limiting criticisms that it is unnecessarily complex.

We looked at all the SC with "A mechanism is available" type phrasing and wondered if any could be simplified, for example,
- Take it out of SC 3.1.4 altogether, so it's: "The expanded form or meaning of abbreviations is available."
- In 3.3.4 instead of "A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission." more simply and directly: "Users can review, confirm, and correct information..."

Here are the others:
1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume which can be set to be a different level from the system volume level.
1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: ...
2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
2.4.9 Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general.
3.1.3 Unusual Words: A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon.
3.1.4 Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available.
3.1.6 Pronunciation: A mechanism is available for identifying specific pronunciation of words where meaning is ambiguous without knowing the pronunciation.
3.2.5 Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes.
3.3.4 Error Prevention (Legal, Financial, Data)...A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

-------

*EOWG accepts resolution*:

Comment 1: LC-1001: definition of assistive technology
http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0171.html
WCAG reply: We have accepted your suggestions.
EOWG reply, Jan 2008: Thanks, accepted.

Comment 3: accessibility-supported technologies
http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0173.html
WCAG reply: We modified the wording in the Conformance section to address this issue.
EOWG reply, Jan 2008: Thanks, accepted.

Comment 14: All of Level 3 not required?
http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0175.html
EOWG Comment: Thank you, the revised Appendix A provides a satisfactory explanation... However, we are concerned that this is important information that people may not find, as many people likely will not read Appendix A. Consider repeating it elsewhere or putting a link to it in a place where it is likely to be see by all  -- perhaps with "Understanding Levels of Conformance" at...
WCAG reply: Thank you. We have added this note to "Understanding Levels of Conformance": "It is not recommended that Level AAA conformance ever be required for entire sites as a general policy because it is not possible to satisfy all Level AAA success criteria for some content."
EOWG reply, Jan 2008: Thanks, accepted.

Comment 20: extend alternative to text to audio-only or video-only
http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0177.html
EOWG Comment: This does not seemed to be changed consistently. http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/ has...
WCAG reply: We have changed the glossary to match the links in the SC (Media alternative to text).
EOWG reply, Jan 2008: Thanks, accepted.

Comment 21: semantics conveyed through presentation?
http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0178.html
EOWG Comment: We debated the scope of SC 1.3.1 and what is meant by "information". There was some concern that the wording in the SC is more broad than the requirements of the sufficient techniques. All of the sufficient techniques deal with structure, and perhaps what one might call relationships. And none of the sufficient techniques address information other than structure or relationships. Therefore, it was not clear what other "Information" (a very broad term) is covered with this SC. This SC seems to cover only Structure and relationships...
Some in EOWG had specific use cases where we couldn't tell the applicability of this SC. They will submit those separately. [ACTION: Liam & Wayne]
WCAG reply: It is difficult to list all the ways that information can be conveyed through presentation and then pose techniques for avoiding them. As a result you will find these in the failures section rather than the sufficient techniques section.
EOWG reply, Jan 2008: Closed in EOWG. Deferred to individuals, rather than continue in EOWG.

Comment 22: Which page title?
http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0179.html
EOWG Comment: ...we have an additional suggestion: Consider putting at the top levels "pointy brackets" around title, that is: <title>...
WCAG reply: We have add a new (first) example to Understanding SC 2.4.2 that explicitly describes the use of the <title> element.
EOWG reply, Jan 2008: Thanks, accepted.

###

~Shawn for EOWG <http://www.w3.org/WAI/EO/>


-----
Shawn Lawton Henry, W3C Web Accessibility Initiative (WAI)
about: http://www.w3.org/People/Shawn/
phone: +1-617-395-7664
e-mail: shawn@w3.org
Received on Friday, 11 January 2008 17:25:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 10:33:47 GMT