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

Dear WCAG WG:

Thank you for considering EOWG's comments on the May 2007 Draft of WCAG 2.0[1]. We find several sections much easier to understand, especially the Introduction and the Conformance sections.

EOWG accepts your resolution of our comments numbered 2, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17, 18, 24, and thus these are not included below.

For the remaining comments, see our replies below.

Please note that given the 2-week turn-around time for our replies, they do not necessarily represent the consensus of all the active participants in EOWG and individuals from EOWG may provide additional feedback.

Regards,
Shawn Henry, EOWG Chair
For EOWG http://www.w3.org/WAI/EO/

[1] http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Nov/0038.html

>----------------------------------------------------------
>Comment 1: LC-1001: definition of assistive technology
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0405.html
>(Issue ID: 2270)
><...>
>Response from Working Group:
>
>We have accepted the substance of your suggestions, with some wording
>tweaks. The definition now reads:
>
>     hardware and/or software that acts as a user agent, or along with
>a mainstream user agent, to provide services to meet the requirements
>of users with disabilities that go beyond those offered by the
>mainstream user agents
<...>

EOWG reply on Comment 1 LC-1001 definition of assistive technology:
The definition overall is now much clearer; however:
- we find the use of "services" in the definition and in note 1 is confusing, and we recommend instead using "input and output," or "functionality"
- we recommend removing the last "the" so it reads: "...go beyond those offered by mainstream user agents"

>----------------------------------------------------------
>Comment 3: accessibility-supported technologies
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0408.html
>(Issue ID: 2273)
>----------------------------
>Original Comment:
>----------------------------
>
>1. [conformance section] EOWG feels that the goal for the section on
>accessibility supported technologies should be that the average developer
>should be able to read the section and understand the concept; understand
>the importance of the concept; and understand that one should be able to go
>to a list of accessibility supported technologies.
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>The new language should be closer to this goal.  This is technical
>though and difficult to make clear.  If there are specific suggestions
>for wording, please forward for consideration.

EOWG reply on Comment 3 accessibility-supported technologies:
It looks like most of this has been moved to Understanding; which some in EOWG strongly support. We may have additional comments on the wording in Understanding later.

One minor thing we note in the WCAG 2.0 document: The first part of the Conformance section still says, "This section...  It also explains what it means for Web content technologies to be accessibility-supported..." -- while it is mentioned here, it is really explained in Understanding now.

>----------------------------------------------------------
>Comment 4: use accessibility-supported technologies
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0408.html
>(Issue ID: 2274)
>
>2. [conformance section] Explain clearly & simply, as part of the
>introductory paragraph, that some technologies support assistive
>technologies, and that these are the ones that one should use.
>
>Response from Working Group:
>
>The Introduction section was moved to Understanding WCAG, but
>'accessibility supported' is mentioned in the introductory sentence
>(all there is) and then clearly explained in conformance requirement
>#6 which follows shortly after.

EOWG reply on comment #4:
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."

>----------------------------------------------------------
>Comment 5: web technologies
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0408.html
>(Issue ID: 2275)
>
>3. [conformance section] In the first paragraph of "accessibility support
>of web technologies" please add "Web" in front of the two uses of
>"technologies" that do not currently have any other descriptor, so as to
>clearly separate reference to the authors' (Web) technologies from
>reference to the users (assistive) technologies. We suggest that this
>differentiation be checked throughout the document.
>
>Response from Working Group:
>
>They now say  "Web content technology"

EOWG reply on Comment 5 web technologies:
Thanks for the changes. You missed some in Note 4 and in Note 5.

>----------------------------------------------------------
>Comment 14: All of Level 3 not required?
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0408.html
>(Issue ID: 2284)
>
>2. [referencing] If maintaining that all of Level 3 should not be
>required, a better explanation is needed for why this is so.
>
>Response from Working Group:
>
>We recommend that Level AAA not be required for general web content.
>It is possible for some types of Web pages and Web sites to conform to
>all Level AAA success criteria. If the requirement were only applied
>to such content, it would be an appropriate requirement.
>
>However, since it will be impossible for some types of Web pages to
>meet this level of conformance, requiring it for general content will
>exclude some kinds of functionality from being provided on the web.

EOWG reply on Comment 14 All of Level 3 not required?:
Thank you, the revised Appendix A provides a satisfactory explanation. <http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20071102/appendixA.html>
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 http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20071102/conformance.html#uc-levels-head

>----------------------------------------------------------
>Comment 19: distinction between blinking and flashing still isn't clear
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0408.html
>(Issue ID: 2289)
>
>17. [guideline 2] The difference between 2.2.2 (blinking) and 2.3.1
>(flashing) is not clear even with the links to definitions, as the
>definitions are mutually self-referencing and seem just like different
>degrees of the same thing. Either differentiate more in the SC themselves,
>or combine them.
>
>Response from Working Group:
>
>We have added a definition for flash and clarified the difference
>between flash and blink both in the definitions and (in longer form)
>in the understanding document

EOWG reply on Comment 19 distinction between blinking and flashing still isn't clear:
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:
- Include plain language description and/or examples of blinking, flashing, and the distinction between them.
- For the flash definition, start with a more easy to understand definition and put the technical specifics after that.
- For the blink definition, provide a self-contained definition, rather than defining it only in relation to flash.
- Put the simple language in the definitions themselves as possible, or at the least in a note with the definition in /TR/WCAG20 doc.
- For the both definitions, link to more explanation and/or examples of each and of the distinction, e.g., something like the new Note in Understanding (Note: In some cases, what we refer to as “blinking” and what we refer to as “flashing” may overlap slightly. We are using different terms for the two because...)

Some background:
- "Then the wording used for the flash definition is weird... "a pair of opposing changes in relative luminance of 10% or more where the relative luminance of the darker image is below 0.80"
I really have no idea what that means." - http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0083.html
- http://www.w3.org/2007/11/16-eo-minutes#comment19

2. We assume that the word "flash" should be linked to its definition in the text of 2.3.1 and 2.3.2.

3. (Also we noted a little "typo" in 2.3.1 Three Flashes or Below Threshold: Web pages do not... where the word "do" is included with "Web page" in the link.)

>----------------------------------------------------------
>Comment 20: extend alternative to text to audio-only or video-only
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0408.html
>(Issue ID: 2290)
>----------------------------
>Original Comment:
>----------------------------
>
>18. [SC 1.2.1] Replace "multimedia alternative to text" with "audio and/or
>video alternative to text" since it is possible to gloss text w/ audio
>only, or w/ silent video only (for instance, sign language) or w/ audio &
>video together (e.g. video of talking head).
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>Thank you. Good suggestion.  we have replaced "multimedia alternative
>to text" with "audio and/or video alternative to text"
>
>and fixed the definition to read
>
>*audio and/or video alternative to text*
>     media that presents no more information than is already presented
>in text (directly or via text alternatives)
>
>     Note: an audio and/or video alternative to text is provided for
>those who benefit from alternate representations of text.  Audio
>and/or video alternative to text may be audio-only, video-only
>(including sign-language video), or audio-video.

EOWG reply on comment 20 extend alternative to text to audio-only or video-only:
This does not seemed to be changed consistently. http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/ has
- 1.1.1... (5) a media _alternative to text_
- 1.2.1... media is an _alternative to text_
- Glossary... audio and/or video alternative to text 

>----------------------------------------------------------
>Comment 21: semantics conveyed through presentation?
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0408.html
>(Issue ID: 2291)
>
>19. [SC 1.3.1] Most of us had no idea what this meant, and the few who did
>had difficulty explaining what the practical implications of this would be
>for content development. Do you mean "semantics conveyed through
>presentation?" Or is it the semantics about the relation between objects?
>Either one of these, or both, would be more understandable.
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>This success criterion speaks both to semantics conveyed through
>presentation, and semantics about relationships between objects. The
>wording has been carefully worked out to encompass this without being
>overly prescriptive. The Working Group did not arrive at alternate
>language that is more clear. The Understanding document provides more
>detail and examples to clarify the scope of this success criterion.

EOWG reply to Comment 21 semantics conveyed through presentation?:
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]

>----------------------------------------------------------
>Comment 22: Which page title?
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0408.html
>(Issue ID: 2292)
>----------------------------
>Original Comment:
>----------------------------
>
>20. [SC 2.4.2] Do you mean the title tag or the title that goes in the H1?
>Please clarify (even if in some non-HTML specific way).
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>To clarify the expected use of the page title, we have added the
>following to the Intent section:
>
>"User agents make the title of the page easily available to the user
>for identifying the page. For instance, a user agent may display the
>page title in the  window title bar or as the name of the tab
>containing the page."
>
>The sufficient techniques for SC 2.4.2 lists the use of the title
>element in HTML, but not the use of an H1 element. We do not believe
>that the use of an H1 element is sufficient by itself, since the
>heading may not be visible at all times. We have added an advisory
>technique;
>SEE ABOVE

EOWG reply on Comment 22 Which page title?:
This resolution does not address our comment for those people who do not know that the HTML title element is displayed in user agents. However, we did find the clarification by drilling down to the techniques example. Therefore, we accept closing this comment; however, we have an additional suggestion: Consider putting at the top levels "pointy brackets" around title, that is: <title>. Suggestions include:
- the technique H25: Providing a title using the <title> element (HTML)
- putting an example at the top of Understanding SC 2.4.2
- under Examples of Success Criterion 2.4.2 put at the top an example of <title...> in HTML

Rationale: In colloquial use, many people may call the <h1> the page title. Some people might not even know about the HTML title element. Putting <title> will clearly differentiate it from <h1> for those who know HTML. Putting it at the top levels will make it clear right away instead of making them drill down to the example in the technique.

>----------------------------------------------------------
>Comment 23: Please clarify
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0408.html
>(Issue ID: 2293)
>----------------------------
>Original Comment:
>----------------------------
>
>21. [SC 3.1.4] We debated this but could not agree on a common
>interpretation. Please clarify.
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>We believe that the definition of mechanism in the glossary and the
>explanation and examples in Understanding Success Criterion 3.1.4 are
>sufficient to understand what kinds of mechanisms might satisfy this
>success criterion. "Mechanism" covers both author-supplied
>functionality and user-agent or assistive-technology supplied
>functionality.

EOWG reply on Comment 23 Please clarify SC 3.1.4:
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."

"A mechanism for finding" seems unnecessary -- if it's not findable, it's not *available* to users. Indeed, the sufficient techniques clarify the different ways that abbreviations can be made available to users.

For background, see http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0078.html and http://lists.w3.org/Archives/Public/w3c-wai-eo/2007OctDec/0084.html

(We have an additional, lower priority suggestion: In Understanding SC 3.1.4, Examples of Success Criterion 3.1.4, move the third example to the top. Rationale: this is the easiest to understand, and easiest for both authors to implement and users to get in many cases.)

###

Received on Monday, 19 November 2007 23:54:50 UTC