Issue Disposition Report for the 03 November 2008 WCAG 2.0 Proposed Recommendation

This is the official Issue Disposition report for the 3 November 2008 WCAG 2.0 Proposed Recommendation. The table at the top summarizes the issues, and is followed by details for each issue. The summary table structure is:

Issue: The issue ID assigned, and a link to the details for that issue in the second section of the report.
Type: Categorizes type of comment - general comment, editorial, question, or typographical error)
Disposition: Indicates how the Working Group addressed the comment - accepted the change, did not accept, or partial/other, which means some of the comment was accepted, or the response was merely a clarification to the commentor
Acknowledgement: The reviewer's response to the disposition - none received, accepted, or did not agree.
Component: The part of WCAG 2.0 that was affected by this issue.

A database-driven view of this report is available which includes the ability to sort the columns. However, that version is not official. See also a brief summary of changes to WCAG 2.0 since Proposed Recommendation.

Total Issues: 23

The working group received responses indicating that the reviewer agrees with the actions taken for 10 issues, disagrees with the working group response to 1 issues, and has received no response from reviewers on 12 issues.

Summary

The primary focus of the Proposed Recommendation is to receive comments from the Advisory Committee. The WCAG Working Group also received some public comments. For clarity, comments from the two sources are presented separately here.

AC Comments

The following comments were received from the Advisory Committee.

Issue	Type	Disposition	Acknowledgment	Component
2688: Language of SC 1.4.5 unclear	comment	NOT ACCEPTED	none received	1.4.5 (Images of Text (Limited))
2689: Expand info required by 4.1.2	comment	PARTIAL/OTHER	none received	4.1.2 (Name-Role-Value)
2692: Statement of Partial Conformance	comment	NOT ACCEPTED	none received	Conformance
2693: require multiple platform support	comment	NOT ACCEPTED	none received	Conformance
2690: G10 should not be acceptable for SC 4.1.2	comment	NOT ACCEPTED	none received	General
2691: Understanding Accessibility Support needs updating	comment	ACCEPTED	none received	Understanding Conformance
2687: Style changer	comment	NOT ACCEPTED	reviewer agrees	Customization
2686: Too difficult	comment	PARTIAL/OTHER	reviewer agrees	General
2694: Changing Short Names to Make it Easier to Understand when GL 1.2 Success Criteria Apply	request	ACCEPTED	reviewer agrees	1.2
2696: Change contrast ratio from 5:1 to 4.5:1	proposal	ACCEPTED	reviewer agrees	1.4.3 (Contrast (Minimum))
2683: Understanding 2.4.1: misleading point?	question	PARTIAL/OTHER	reviewer agrees	2.4.1 (Bypass Blocks)
2684: Nested headings	comment	ACCEPTED	reviewer agrees	1.3.1 (Info and Relationships)
2685: validity	comment	NOT ACCEPTED	reviewer agrees	Guideline 4.1

Public Comments

The following comments were received as public comments and were also addressed by the WG during PR.

Issue	Type	Disposition	Acknowledgment	Component
2677: Low-power devices?	comment	NOT ACCEPTED	none received	General
2681: HTML Headings technique: duplicated	comment		none received	HTML/XHTML Techniques
2695: G14 and G122 color technique: duplicated	comment		none received	General
2697: Techniques duplicated / identical G126 and G185	comment		none received	General
2698: Include H69 as technique for 2.4.6	comment		none received	2.4.6 (Labels Descriptive)
2699: Clarify G167	comment		none received	General
2678: Group common failures as well as (good) techniques	comment	NOT ACCEPTED	reviewer agrees	Common Failures
2679: H28 only mentions one type of SUBMIT button	comment	ACCEPTED	reviewer agrees	HTML/XHTML Techniques
2682: H33 sufficient technique for 2.4.4?	comment	PARTIAL/OTHER	reviewer agrees	HTML/XHTML Techniques
2680: Technique H45 procedure description incomplete	comment	ACCEPTED	reviewer disagrees	HTML/XHTML Techniques

Details

Issue 2677: Low-power devices?

Issue Created: 17 Nov 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Nov/0002.html (Public Comment)
Component: General
Disposition: NOT ACCEPTED (No response from reviewer)

Original Comment	Response from Working Group
1. Does WCAG 2.0 still include the aim of user-agent independence that WCAG 1.0 had? 2. Are there some simple statements that I can cite in order to encourage webmasters to support cheap low-power devices? Generally such devices do not execute scripting and do not contain proprietary technology like Flash. The main document seems too vague and impractical at first glance and I'm somewhat concerned by the non-obvious definition of "web page" to include AJAX applications and movies. 3. Finally, how have our previous comments on the Candidate Recommendation been addressed in the new Proposed Recommendation? Proposed Change: 1. Reword the introduction to include the WCAG 1.0 phrasing, or note that WCAG 2.0 is no longer concerned with user-agent independence. 2. Introduce checkpoints similar to those from WCAG 1.0. 3. Offer a "comments search" which allows us to find threads from our past comments; and actually email commenters back.	1. WCAG 2.0 relies on the concept of accessibility-supported uses of technologies, that is, techniques used to meet success criteria must work with the users' browsers, user agents and assistive technologies. However, the WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported, since different environments will contain different sets of tools. 2. If cheap, low-power devices are included among the users' browsers and assistive technologies, then conforming content must use techniques that work with them. If they do not support technologies such as Javascript and Flash, then those technologies could not be relied upon. However, there is not an accessibility argument for supporting those specific devices. 3. The archives of the public comments list, http://lists.w3.org/Archives/Public/public-comments-wcag20/ , contains a search feature for searching the archives. The Working Group responded to your last comments in May, 2007 (see http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Nov/0085.html ).

Original Comment

Response from Working Group

1. Does WCAG 2.0 still include the aim of user-agent independence that WCAG 1.0 had?

2. Are there some simple statements that I can cite in order to encourage webmasters to support cheap low-power devices? Generally such devices do not execute scripting and do not contain proprietary technology like Flash. The main document seems too vague and impractical at first glance and I'm somewhat concerned by the non-obvious definition of "web page" to include AJAX applications and movies.

3. Finally, how have our previous comments on the Candidate Recommendation been addressed in the new Proposed Recommendation?

Proposed Change:
1. Reword the introduction to include the WCAG 1.0 phrasing, or note that WCAG 2.0 is no longer concerned with user-agent independence.

2. Introduce checkpoints similar to those from WCAG 1.0.

3. Offer a "comments search" which allows us to find threads from our past comments; and actually email commenters back.

1. WCAG 2.0 relies on the concept of accessibility-supported uses of technologies, that is, techniques used to meet success criteria must work with the users' browsers, user agents and assistive technologies. However, the WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported, since different environments will contain different sets of tools.

2. If cheap, low-power devices are included among the users' browsers and assistive technologies, then conforming content must use techniques that work with them. If they do not support technologies such as Javascript and Flash, then those technologies could not be relied upon. However, there is not an accessibility argument for supporting those specific devices.

3. The archives of the public comments list, http://lists.w3.org/Archives/Public/public-comments-wcag20/ , contains a search feature for searching the archives. The Working Group responded to your last comments in May, 2007 (see http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Nov/0085.html ).

Edit Issue (Last Edited: 2008-12-01 17:17:26)

Issue 2688: Language of SC 1.4.5 unclear

Issue Created: 02 Dec 2008
Source: AC Comment
Component: 1.4.5 (Images of Text (Limited))
Disposition: NOT ACCEPTED (No response from reviewer)

Original Comment	Response from Working Group
The language of guideline "1.4.5 Images of Text" isn't immediately clear and understandable - several readings were required. We suggest the editors consider rewording it - particularly the first phrase: "If the technologies being used can achieve the visual presentation..."	Thank you for your comment. We know that this is a hard one to read and took several passes at it. We do not know of a way to make it easier to read and still accurate. Without a candidate solution, we will be leaving this item as it was proposed.

Edit Issue (Last Edited: 2008-12-04 18:10:09)

Issue 2689: Expand info required by 4.1.2

Issue Created: 02 Dec 2008
Source: AC Comment
Component: 4.1.2 (Name-Role-Value)
Disposition: PARTIAL/OTHER (No response from reviewer)

Original Comment	Response from Working Group
I suggest that guideline "4.1.2 Name, Role, Value" should be expanded to include a larger set of information that is known to be needed by assistive technologies. Please see 3-U from the TEITAC report at http://www.access-board.gov/sec508/refresh/report/#7 for the list of information that should be provided by all user interface components delivered via the web (or for that matter in a stand-alone application).	SC 4.1.2 captures the information that was felt to be essential and applicable to all user interface components. Specific controls may need to expose additional information, as noted in Section 3-U, but we are concerned that if SC 4.1.2 includes a catalog of controls and their specific properties, it will rapidly become outdated. Because the responsibilities for this SC are split in varying ways between the user agent and the author, this is a particularly difficult area to make more precise. Adding new items to the requirements of SC 4.1.2 would require that we return the guidelines to working draft and go through the review stages again. We do not feel that the benefits of adding more (but still incomplete) information is worth the additional delay this would introduce. In future revisions of the WCAG 2.0 Understanding document, the Working Group plans to include references to the TEITAC documents.

Original Comment

Response from Working Group

I suggest that guideline "4.1.2 Name, Role, Value" should be expanded to
include a larger set of information that is known to be needed by
assistive technologies. Please see 3-U from the TEITAC report at
http://www.access-board.gov/sec508/refresh/report/#7 for the list of
information that should be provided by all user interface components
delivered via the web (or for that matter in a stand-alone application).

SC 4.1.2 captures the information that was felt to be essential and applicable to all user interface components. Specific controls may need to expose additional information, as noted in Section 3-U, but we are concerned that if SC 4.1.2 includes a catalog of controls and their specific properties, it will rapidly become outdated. Because the responsibilities for this SC are split in varying ways between the user agent and the author, this is a particularly difficult area to make more precise.

Adding new items to the requirements of SC 4.1.2 would require that we return the guidelines to working draft and go through the review stages again. We do not feel that the benefits of adding more (but still incomplete) information is worth the additional delay this would introduce.

In future revisions of the WCAG 2.0 Understanding document, the Working Group plans to include references to the TEITAC documents.

Edit Issue (Last Edited: 2008-12-04 18:10:09)

Issue 2692: Statement of Partial Conformance

Issue Created: 02 Dec 2008
Source: AC Comment
Component: Conformance
Disposition: NOT ACCEPTED (No response from reviewer)

Original Comment	Response from Working Group
In the "Statement of partial conformance - third party content", a better way to convey this would be to mirror the VPAT style "Supports with exceptions" -> specifically "Conforms with exceptions" and then go on to detail that the exceptions (may) be in 3rd-party content and/or user-provided content, which have not been verified. This change in emphasis better matches what the original author has done and verified, and also helps convey the fact that there may not in fact be any conformance problems (e.g. on a blog where no comments have been made, or where only confirming comments have been made, but which have not been verified).	It is not possible to "conform" without conforming. We are already concerned that people will interpret Statements of Partial Conformance as conformance claims. We think it would be even more misleading if we changed to "Conforms with exceptions". We were also very careful that Partial Conformance statements only permit exception for content that is outside of the author's control. A general "Conforms with Exceptions" statement also leaves the impression that the author can pick and choose what exceptions to make.

Original Comment

Response from Working Group

In the "Statement of partial conformance - third party content", a better
way to convey this would be to mirror the VPAT style "Supports with
exceptions" -> specifically "Conforms with exceptions" and then go on to
detail that the exceptions (may) be in 3rd-party content and/or
user-provided content, which have not been verified. This change in
emphasis better matches what the original author has done and verified,
and also helps convey the fact that there may not in fact be any
conformance problems (e.g. on a blog where no comments have been made, or
where only confirming comments have been made, but which have not been
verified).

It is not possible to "conform" without conforming. We are already concerned that people will interpret Statements of Partial Conformance as conformance claims. We think it would be even more misleading if we changed to "Conforms with exceptions".

We were also very careful that Partial Conformance statements only permit exception for content that is outside of the author's control. A general "Conforms with Exceptions" statement also leaves the impression that the author can pick and choose what exceptions to make.

Edit Issue (Last Edited: 2008-12-04 18:10:11)

Issue 2693: require multiple platform support

Issue Created: 02 Dec 2008
Source: AC Comment
Component: Conformance
Disposition: NOT ACCEPTED (No response from reviewer)

Original Comment	Response from Working Group
The normative definition of "accessibility supported" should also discuss multi-platform accessibility, in at least the same style as 2c -> e.g. if the content [such as an ActiveX control] is used within an organization that has standardized on a platform for which that content is designed and works. But for example, it should not be permissible to conform with WCAG if content is only accessible on a single platform.	Note 1 to the definition of accessibility supported says: Note 1: The WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".) We do not say how many platforms must be supported. There are closed environments that standardize on a single platform, and content that is supported only on that single platform could be accessibility supported in that environment. Such content could conform to WCAG, that is, the absence of support on a second platform does not disqualify it out of hand. Authors must understand the range of platforms, user agents, and assistive technology used by their audience to evaluate the level of accessibility support required. We hope that sources of accessibility support information can be developed to help authors with this task. In the rapidly evolving web, this is a challenge.

Original Comment

Response from Working Group

The normative definition of "accessibility supported" should also discuss
multi-platform accessibility, in at least the same style as 2c -> e.g. if
the content [such as an ActiveX control] is used within an organization
that has standardized on a platform for which that content is designed and
works. But for example, it should not be permissible to conform with WCAG
if content is only accessible on a single platform.

Note 1 to the definition of accessibility supported says:

Note 1: The WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".)

We do not say how many platforms must be supported. There are closed environments that standardize on a single platform, and content that is supported only on that single platform could be accessibility supported in that environment. Such content could conform to WCAG, that is, the absence of support on a second platform does not disqualify it out of hand.

Authors must understand the range of platforms, user agents, and assistive technology used by their audience to evaluate the level of accessibility support required. We hope that sources of accessibility support information can be developed to help authors with this task. In the rapidly evolving web, this is a challenge.

Edit Issue (Last Edited: 2008-12-04 18:10:11)

Issue 2681: HTML Headings technique: duplicated

Issue Created: 17 Nov 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Nov/0013.html (Public Comment)
Component: HTML/XHTML Techniques
Disposition: (No response from reviewer)

Original Comment	Response from Working Group
H42: Using h1-h6 to identify headings relates to SC 1.3.1 H69: Providing heading elements at the beginning of each section of content relates to SC 2.4.1 Comment: Both descriptions are essentially the same. I suggest they be merged into a single technique and reference both SC	H42 should describe the use of heading mark-up to label headings semantically, but also contained a good deal of discussion about how to use headings. We have removed the discussion and examples of ways to use headings to organize content from H42. Response from Reviewer: Sorry I disagree. Headings are not marked up merely to aid navigation by screen readers. Using hidden headings to work like ARIA landmarks is essentially a hack that exploits ability of screen reading software to jump from heading to heading. Technique #69 supports both the SCs including 1.3.1 and the description explains that headings are used to convey structure and hierarchy and semantics. So I am not sure what is the value of H42. In fact read the description for H42. Except for the "objective is..." sentence, the rest could be better used to within a "Common Failure".

Original Comment

Response from Working Group

H42: Using h1-h6 to identify headings
relates to SC 1.3.1
H69: Providing heading elements at the beginning of each section of content
relates to SC 2.4.1

Comment: Both descriptions are essentially the same. I suggest they be merged into a single technique and reference both SC

H42 should describe the use of heading mark-up to label headings semantically, but also contained a good deal of discussion about how to use headings. We have removed the discussion and examples of ways to use headings to organize content from H42.

Response from Reviewer:

Sorry I disagree.
Headings are not marked up merely to aid navigation by screen readers. Using hidden headings to work like ARIA landmarks is essentially a hack that exploits ability of screen reading software to jump from heading to heading.
Technique #69 supports both the SCs including 1.3.1 and the description explains that headings are used to convey structure and hierarchy and semantics. So I am not sure what is the value of H42.
In fact read the description for H42. Except for the "objective is..." sentence, the rest could be better used to within a "Common Failure".

Edit Issue (Last Edited: 2008-12-02 13:46:31)

Issue 2690: G10 should not be acceptable for SC 4.1.2

Issue Created: 02 Dec 2008
Source: AC Comment
Component: General
Disposition: NOT ACCEPTED (No response from reviewer)

Original Comment	Response from Working Group
Related to 4.1.2, though I understand it to be non-normative, I am concerned with technique G10. Example 2 from this technique enshrines as "accessible" web content that by its very nature can only be made accessible on a single platform and processor architecture (x86 binary files delivered as ActiveX components). This should not be an acceptable technique/result.	G10 is about using the accessibility API of a platform to expose the information required by SC 4.1.2. As a technique, it applies to any platform that has a standard accessibiity API. The examples are not meant as endorsements, but demonstrations of what it means to support an accessibility API, and what sorts of technologies might need to use such a technique. Example 2 is an acceptable example of this approach. It is sufficient to satisfy SC 4.1.2 in an environment that supports those technologies. In a controlled environment, it may be enough to support for only one OS platform. In other environments, it will not.

Original Comment

Response from Working Group

Related to 4.1.2, though I understand it to be non-normative, I am
concerned with technique G10. Example 2 from this technique enshrines as
"accessible" web content that by its very nature can only be made
accessible on a single platform and processor architecture (x86 binary
files delivered as ActiveX components). This should not be an acceptable
technique/result.

G10 is about using the accessibility API of a platform to expose the information required by SC 4.1.2. As a technique, it applies to any platform that has a standard accessibiity API. The examples are not meant as endorsements, but demonstrations of what it means to support an accessibility API, and what sorts of technologies might need to use such a technique.

Example 2 is an acceptable example of this approach. It is sufficient to satisfy SC 4.1.2 in an environment that supports those technologies.

In a controlled environment, it may be enough to support for only one OS platform. In other environments, it will not.

Edit Issue (Last Edited: 2008-12-04 18:10:10)

Issue 2691: Understanding Accessibility Support needs updating

Issue Created: 02 Dec 2008
Source: AC Comment
Component: Understanding Conformance
Disposition: ACCEPTED (No response from reviewer)

Original Comment	Response from Working Group
Likewise while similarly non-normative, item #5 in 'Level of Assistive Technology Support Needed for "Accessibility Support"' in 'Understanding Accessibility Support' at http://www.w3.org/TR/2008/WD-UNDERSTANDING-WCAG20-20081103/conformance.html#uc-accessibility-support-head is a misrepresentation of the current state of the art at the end of 2008. For example, the open source and free Orca screen reader has some of the best support for WAI ARIA of any screen reader available - certainly better than many commercial screen readers costing in excess of $1,000. At a minimum, the phrase "Currently assistive technology that is affordable by the general public is often very poor" should change to "Current assistive technology that is affordable by the general public may be poor" (and a similar change within the body of that paragraph). I also note that the VoiceOver screen reader available in the latest Macintosh operating system release is essentially free to anyone who already has a modern Macintosh, and is receiving good reviews (cf. the recent review of VoiceOver in AFB Access World).	Thank you for catching this and suggesting a solution We have changed the text to read "Current assistive technology that is affordable by the general public may be poor" And we have changed the following paragraph to read: "Content created for the public that can not be used by those with disabilities should be avoid. In many cases, the cost of assistive technologies is too high for users who need it. Also, while there are encouraging developments in some of these tools, the capabilities of free or low cost AT are often poor enough that Web content cannot be realistically restricted to this lowest common denominator. This creates a very difficult dilemma that needs to be addressed."

Original Comment

Response from Working Group

Likewise while similarly non-normative, item #5 in 'Level of Assistive
Technology Support Needed for "Accessibility Support"' in 'Understanding
Accessibility Support' at
http://www.w3.org/TR/2008/WD-UNDERSTANDING-WCAG20-20081103/conformance.html#uc-accessibility-support-head
is a misrepresentation of the current state of the art at the end of 2008.
For example, the open source and free Orca screen reader has some of the
best support for WAI ARIA of any screen reader available - certainly
better than many commercial screen readers costing in excess of $1,000.
At a minimum, the phrase "Currently assistive technology that is
affordable by the general public is often very poor" should change to
"Current assistive technology that is affordable by the general public may
be poor" (and a similar change within the body of that paragraph). I also
note that the VoiceOver screen reader available in the latest Macintosh
operating system release is essentially free to anyone who already has a
modern Macintosh, and is receiving good reviews (cf. the recent review of
VoiceOver in AFB Access World).

Thank you for catching this and suggesting a solution

We have changed the text to read

"Current assistive technology that is affordable by the general public may
be poor"

And we have changed the following paragraph to read:

"Content created for the public that can not be used by those with disabilities should be avoid. In many cases, the cost of assistive technologies is too high for users who need it. Also, while there are encouraging developments in some of these tools, the capabilities of free or low cost AT are often poor enough that Web content cannot be realistically restricted to this lowest common denominator. This creates a very difficult dilemma that needs to be addressed."

Edit Issue (Last Edited: 2008-12-04 18:10:10)

Issue 2695: G14 and G122 color technique: duplicated

Issue Created: 04 Dec 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Dec/0015.html (Public Comment)
Component: General
Disposition: (No response from reviewer)

Original Comment	Response from Working Group
The above techniques appear identical from their titles as well as from the content- description, examples etc. I suggest merging them. 1. G14: Ensuring that information conveyed by color differences is also available in text 2. G122: Including a text cue whenever color cues are used

Edit Issue (Last Edited: 2008-12-04 17:11:22)

Issue 2697: Techniques duplicated / identical G126 and G185

Issue Created: 05 Dec 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Dec/0016.html (Public Comment)
Component: General
Disposition: (No response from reviewer)

Original Comment	Response from Working Group
G126: Providing a list of links to all other Web pages G185: Linking to all of the pages on the site from the home page By reading the example for G185, it appears both the techniques are talking of the same thing. Also both apply to small collections of ppages. It is so difficult to distinguish between these two techniques that even the writer got confused and ended up giving identical examples. I suggest doing away with G185. Similarly, a table of contents (G64) links to related Web pages (G125). I agree that a the term "table of content" is appropriate for a document like a user guide or the WCAG doc itself. I do not see the need for listing a TOC as a technique but it could be an example for G125. As a matter of fact a TOC is cited as an example for G126- Providing a list of links to all other Web pages. Some sites have a top nav and on selecting one of the items, a left nav bar lists related links. A footer-nav contains another set of links. Why is this not listed as a separate technique then? I suggest this too be done if TOC is made a separate technique. Example: www.merck.com/licensing Actually all the techniques for 2.4.5(except G161- search) should be combined into a single technique.

Original Comment

Response from Working Group

G126: Providing a list of links to all other Web pages
G185: Linking to all of the pages on the site from the home page

By reading the example for G185, it appears both the techniques are talking of the same thing. Also both apply to small collections of ppages. It is so difficult to distinguish between these two techniques that even the writer got confused and ended up giving identical examples.

I suggest doing away with G185.

Similarly, a table of contents (G64) links to related Web pages (G125). I agree that a the term "table of content" is appropriate for a document like a user guide or the WCAG doc itself. I do not see the need for listing a TOC as a technique but it could be an example for G125.
As a matter of fact a TOC is cited as an example for G126- Providing a list of links to all other Web pages.
Some sites have a top nav and on selecting one of the items, a left nav bar lists related links. A footer-nav contains another set of links. Why is this not listed as a separate technique then? I suggest this too be done if TOC is made a separate technique.
Example: www.merck.com/licensing

Actually all the techniques for 2.4.5(except G161- search) should be combined into a single technique.

Edit Issue (Last Edited: 2008-12-05 15:07:33)

Issue 2698: Include H69 as technique for 2.4.6

Issue Created: 05 Dec 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Dec/0017.html (Public Comment)
Component: 2.4.6 (Labels Descriptive)
Disposition: (No response from reviewer)

Original Comment	Response from Working Group
SC 2.4.6 lists a general technique (G130) but omits to list H69: Providing heading elements at the beginning of each section of content as a sufficient technique. Also F2 may be listed as a failure for 2.4.6. Currently no failures are listed.

Edit Issue (Last Edited: 2008-12-05 15:08:45)

Issue 2699: Clarify G167

Issue Created: 08 Dec 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Dec/0018.html (Public Comment)
Component: General
Disposition: (No response from reviewer)

Original Comment	Response from Working Group
G167: Using an adjacent button to label the purpose of a field G167 is documented as a sufficient technique for SC3.3.2 - Labels or Instructions. As I understand this technique, it is alright for a text input field, (say for search-phrase), not to have a label or title to explicitly identify the purpose of the field so long as the search button placed after it is properly labeled. Is this interpretation correct? So a screen reader user is expected to tab to next control, exercise judgment to determine if the label associated with that control can be related to the earlier control? The note that requires compliance with 4.1.2 is not clear. Perhaps an HTML example might help.

Original Comment

Response from Working Group

G167: Using an adjacent button to label the purpose of a field
G167 is documented as a sufficient technique for SC3.3.2 - Labels or Instructions.
As I understand this technique, it is alright for a text input field, (say for search-phrase), not to have a label or title to explicitly identify the purpose of the field so long as the search button placed after it is properly labeled. Is this interpretation correct?
So a screen reader user is expected to tab to next control, exercise judgment to determine if the label associated with that control can be related to the earlier control?
The note that requires compliance with 4.1.2 is not clear. Perhaps an HTML example might help.

Edit Issue (Last Edited: 2008-12-08 12:03:28)

Issue 2687: Style changer

Issue Created: 01 Dec 2008
Source: AC Comment
Component: Customization
Disposition: NOT ACCEPTED (Reviewer Agrees)

Original Comment	Response from Working Group
the customizable quick reference (How to Meet WCAG 2.0) could benefit if a style switcher/changer was added to accommodate individual needs (i.e views per guideline) since it is still very long.	Interesting suggestion. However, the working group feels that the single-page view of the How to Meet document is one of its primary use cases in that it allows authors to view all of the techniques for WCAG 2.0 on a single page. At this time, we have decided not to make the changes you have suggested since this is not a normative document - but just a tool. We will keep your suggestion in mind and consider it as we do future versions of the tool.

Original Comment

Response from Working Group

the customizable quick reference (How to Meet WCAG 2.0) could
benefit if a style switcher/changer was added to accommodate individual
needs (i.e views per guideline) since it is still very long.

Interesting suggestion. However, the working group feels that the single-page view of the How to Meet document is one of its primary use cases in that it allows authors to view all of the techniques for WCAG 2.0 on a single page.

At this time, we have decided not to make the changes you have suggested since this is not a normative document - but just a tool. We will keep your suggestion in mind and consider it as we do future versions of the tool.

Edit Issue (Last Edited: 2008-12-11 06:29:28)

Issue 2686: Too difficult

Issue Created: 01 Dec 2008
Source: AC Comment
Component: General
Disposition: PARTIAL/OTHER (Reviewer Agrees)

Original Comment	Response from Working Group
overall the documents are too long and somehow hard to follow.	We have tried to strike a balance in providing a relatively short set of normative guidelines and a rich set of supporting materials to help people understand and apply WCAG 2.0. Sometimes people look at all the support documents and think of the guidelines (and support docs) as being long. Another way to look at this would be to look at the guidelines themselves as a not very long W3C specification, for which there is also available a free technical reference book (Understanding) and a rich set of application notes and techniques (Techniques). Taken as a whole, the collection of documents can be daunting however and we look forward to seeing additional training material developed by the Education and Outreach Working Group (EOWG) and others.

Original Comment

Response from Working Group

overall the documents are too long and somehow hard to follow.

We have tried to strike a balance in providing a relatively short set of normative guidelines and a rich set of supporting materials to help people understand and apply WCAG 2.0.

Sometimes people look at all the support documents and think of the guidelines (and support docs) as being long. Another way to look at this would be to look at the guidelines themselves as a not very long W3C specification, for which there is also available a free technical reference book (Understanding) and a rich set of application notes and techniques (Techniques).

Taken as a whole, the collection of documents can be daunting however and we look forward to seeing additional training material developed by the Education and Outreach Working Group (EOWG) and others.

Edit Issue (Last Edited: 2008-12-11 06:29:14)

Issue 2694: Changing Short Names to Make it Easier to Understand when GL 1.2 Success Criteria Apply

Issue Created: 04 Dec 2008
Source: AC Comment
Component: 1.2
Disposition: ACCEPTED (Reviewer Agrees)

Original Comment	Response from Working Group
We propose some minor editorial changes to the short descriptions which are associated with Success Criteria 1.2.1 - 1.2.9. In our experience, the application of these criteria can be confusing and it is important to explicitly show the type of media for which the criteria are applicable. The proposed new wording is below: * 1.2.1 Audio-only and Video-only (Prerecorded): o Prerecorded Audio-only: o Prerecorded Video-only: * 1.2.2 Captions (Prerecorded): * 1.2.3 Audio Description or Media Alternative (Prerecorded): * 1.2.4 Captions (Live): * 1.2.5 Audio Description (Prerecorded): * 1.2.6 Sign Language (Prerecorded): * 1.2.7 Extended Audio Description (Prerecorded): * 1.2.8 Media Alternative (Prerecorded): * 1.2.9 Live Audio-only:	Thank you. In addition to these changes to the short names, the following has been added to the beginning of Intent of Guideline 1.2: The provisions under Guideline 1.2 all have to do with Time-based media. This includes media that is * audio-only, * video-only * audio-video * audio and/or video combined with interaction To make it easy for authors to quickly determine which success criteria apply to their content, the type of media each success criterion applies to is included in its short name. For audio-only or video-only media, you only need to apply the success criteria that say "audio-only" or "video-only" in their short name. If your media is not audio-only or video-only, then all the rest of the success criteria apply. Media can also be live or prerecorded. Each of the success criterion short names clearly tells you if the success criterion applies to live or prerecorded media.

Original Comment

Response from Working Group

We propose some minor editorial changes to the short descriptions which are associated with Success Criteria 1.2.1 - 1.2.9.

In our experience, the application of these criteria can be confusing and it is important to explicitly show the type of media for which the criteria are applicable.

The proposed new wording is below:

* 1.2.1 Audio-only and Video-only (Prerecorded):
o Prerecorded Audio-only:
o Prerecorded Video-only:
* 1.2.2 Captions (Prerecorded):
* 1.2.3 Audio Description or Media Alternative (Prerecorded):
* 1.2.4 Captions (Live):
* 1.2.5 Audio Description (Prerecorded):
* 1.2.6 Sign Language (Prerecorded):
* 1.2.7 Extended Audio Description (Prerecorded):
* 1.2.8 Media Alternative (Prerecorded):
* 1.2.9 Live Audio-only:

Thank you. In addition to these changes to the short names, the following has been added to the beginning of Intent of Guideline 1.2:

The provisions under Guideline 1.2 all have to do with Time-based media. This includes media that is

* audio-only,
* video-only
* audio-video
* audio and/or video combined with interaction

To make it easy for authors to quickly determine which success criteria apply to their content, the type of media each success criterion applies to is included in its short name.

For audio-only or video-only media, you only need to apply the success criteria that say "audio-only" or "video-only" in their short name. If your media is not audio-only or video-only, then all the rest of the success criteria apply.

Media can also be live or prerecorded. Each of the success criterion short names clearly tells you if the success criterion applies to live or prerecorded media.

Edit Issue (Last Edited: 2008-12-05 06:28:03)

Issue 2696: Change contrast ratio from 5:1 to 4.5:1

Issue Created: 04 Dec 2008
Source: AC Comment
Component: 1.4.3 (Contrast (Minimum))
Disposition: ACCEPTED (Reviewer Agrees)

Original Comment	Response from Working Group
We would prefer to see the minimum contrast ratio changed from 5 to 4.5, based on some clarifications made subsequent to the working group discussion of this topic.	The Working Group has agreed to change the contrast ratio to 4.5:1.

Edit Issue (Last Edited: 2008-12-04 21:21:37)

Issue 2678: Group common failures as well as (good) techniques

Issue Created: 17 Nov 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Nov/0003.html (Public Comment)
Component: Common Failures
Disposition: NOT ACCEPTED (Reviewer Agrees)

Original Comment	Response from Working Group
I wondered why the common failures in the techniques document are not grouped as the (good) techniques are. They could be FG for general failures, FH for HTML/XHTML failures, etc. Proposed Change: Maybe rename the failures, or, at least, group them according to technology.	The working group felt it was important to raise the visibility of all failures. In particular, authors need to be aware of general failures as well as failures specific to the technology they are using. So all failures are listed together. However, we will consider including information that more clearly associates failures with the technologies they relate to in future versions of the Techniques document.

Original Comment

Response from Working Group

I wondered why the common failures in the techniques document are not grouped as the (good) techniques are. They could be FG for general failures, FH for HTML/XHTML failures, etc.

Proposed Change:
Maybe rename the failures, or, at least, group them according to technology.

The working group felt it was important to raise the visibility of all failures. In particular, authors need to be aware of general failures as well as failures specific to the technology they are using. So all failures are listed together.

However, we will consider including information that more clearly associates failures with the technologies they relate to in future versions of the Techniques document.

Edit Issue (Last Edited: 2008-12-03 09:19:04)

Issue 2679: H28 only mentions one type of SUBMIT button

Issue Created: 17 Nov 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Nov/0008.html (Public Comment)
Component: HTML/XHTML Techniques
Disposition: ACCEPTED (Reviewer Agrees)

Original Comment	Response from Working Group
I assume this is just a bug - technique H28 only mentions looking for INPUT type=SUBMIT, but what about INPUT type=IMAGE and BUTTON type=SUBMIT?	Thank you, we assume you meant H32. We have updated the test procedure to make it clearer that submit buttons can be implemented using any of these forms.

Edit Issue (Last Edited: 2008-12-01 17:11:28)

Issue 2682: H33 sufficient technique for 2.4.4?

Issue Created: 17 Nov 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Nov/0014.html (Public Comment)
Component: HTML/XHTML Techniques
Disposition: PARTIAL/OTHER (Reviewer Agrees)

Original Comment	Response from Working Group
The How to meet WCAG2.0 states H33 as a sufficient technique for SC 2.4.4 - link purpose. "4. Providing a supplemental description of the purpose of a link using one of the following techniques: H33: Supplementing link text with the title attribute" However the description for H33 does not support this. In fact one is cautioned against using this technique: "Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique. For this reason, it is preferred that the author use technique: C7: Using CSS to hide a portion of the link text or H30: Providing link text that describes the purpose of a link for anchor elements ." The How To techniques doc needs to be amended to reflect this note of caution. H33 should be made an advisory technique.	Despite all its limitations, the working group feels it is important to retain this technique for those situations where it does work. For instance, screen readers will read the title text in cases where there is no link text for the link but only a title attribute. This seems especially important for authors who want to rely only on HTML, so they cannot rely on C17. We will encourage user agents and assistive technology to provide better support for this use of the title attribute. Another example where this commonly occurs is with highly structured content such as a blog or a content management system. In these situations, similar links are often repeated with multiple similar "chunks" of content. For example, a home page for a blog might include 15 posts, each with a series of links related to the number of comments received and the categories under which the entry was filed. Each entry might include a series of links like "No comments," "1 comment" etc. where the title attribute says something like, "Comment on {title of blog post}. 1 comment received." Additional links that relate to the category the item is associated with might include "General," "Work," "Family" where the title attribute says something like, "Read all posts in the {category name} category." We have added the following note to the end of sufficient techniques section for 2.4.4: Note: Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique. For this reason, it is preferred that the author use technique C7: Using CSS to hide a portion of the link text (CSS) or H30: Providing link text that describes the purpose of a link for anchor elements (HTML)

Original Comment

Response from Working Group

The How to meet WCAG2.0 states H33 as a sufficient technique for SC 2.4.4 - link purpose.
"4. Providing a supplemental description of the purpose of a link using one of the following techniques:
H33: Supplementing link text with the title attribute"

However the description for H33 does not support this. In fact one is cautioned against using this technique:
"Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique. For this reason, it is preferred that the author use technique:
C7: Using CSS to hide a portion of the link text or
H30: Providing link text that describes the purpose of a link for anchor elements ."

The How To techniques doc needs to be amended to reflect this note of caution. H33 should be made an advisory technique.

Despite all its limitations, the working group feels it is important to retain this technique for those situations where it does work. For instance, screen readers will read the title text in cases where there is no link text for the link but only a title attribute. This seems especially important for authors who want to rely only on HTML, so they cannot rely on C17. We will encourage user agents and assistive technology to provide better support for this use of the title attribute.

Another example where this commonly occurs is with highly structured content such as a blog or a content management system. In these situations, similar links are often repeated with multiple similar "chunks" of content. For example, a home page for a blog might include 15 posts, each with a series of links related to the number of comments received and the categories under which the entry was filed. Each entry might include a series of links like "No comments," "1 comment" etc. where the title attribute says something like, "Comment on {title of blog post}. 1 comment received." Additional links that relate to the category the item is associated with might include "General," "Work," "Family" where the title attribute says something like, "Read all posts in the {category name} category."

We have added the following note to the end of sufficient techniques section for 2.4.4:

Note: Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique. For this reason, it is preferred that the author use technique C7: Using CSS to hide a portion of the link text (CSS) or H30: Providing link text that describes the purpose of a link for anchor elements (HTML)

Edit Issue (Last Edited: 2008-12-02 13:43:45)

Issue 2683: Understanding 2.4.1: misleading point?

Issue Created: 01 Dec 2008
Source: AC Comment
Component: 2.4.1 (Bypass Blocks)
Disposition: PARTIAL/OTHER (Reviewer Agrees)

Original Comment	Response from Working Group
I have noticed also a couple of points that may be a little bit misleading for the developers in order to design an accessible website. i.e. Regarding SC 2.4.1 bypass blocks, It is not clear the difference between Creating links to skip blocks in the Sufficient Techniques for this SC and the skip links to enhance page navigation in the respective Advisory Technique for this SC	Unfortunately, there are many advisory techniques like this that have not yet been written up. In this case, the difference between the sufficient technique and the advisory technique is because SC 2.4.1 only requires a navigation mechanism like skip links over repeated content. However, it can be helpful to provide navigation mechanisms to help keyboard users move to different parts of a web page, even if the information skipped is not repeated on other pages. For instance, there may be several sections of a form, and users would benefit from having easy ways to skip over sections. The advisory technique would encourage authors to provide generally enhanced page navigation for keyboard users.

Original Comment

Response from Working Group

I have noticed also a couple of points that may be a little bit
misleading for the developers in order to design an accessible website.
i.e.
Regarding SC 2.4.1 bypass blocks, It is not clear the
difference between Creating links to skip blocks in the Sufficient
Techniques for this SC and the skip links to enhance page
navigation in the respective Advisory Technique for this SC

Unfortunately, there are many advisory techniques like this that have not yet been written up.

In this case, the difference between the sufficient technique and the advisory technique is because SC 2.4.1 only requires a navigation mechanism like skip links over repeated content. However, it can be helpful to provide navigation mechanisms to help keyboard users move to different parts of a web page, even if the information skipped is not repeated on other pages. For instance, there may be several sections of a form, and users would benefit from having easy ways to skip over sections. The advisory technique would encourage authors to provide generally enhanced page navigation for keyboard users.

Edit Issue (Last Edited: 2008-12-11 06:28:33)

Issue 2684: Nested headings

Issue Created: 01 Dec 2008
Source: AC Comment
Component: 1.3.1 (Info and Relationships)
Disposition: ACCEPTED (Reviewer Agrees)

Original Comment	Response from Working Group
The examples on Success Criterion 1.3.1 and on Success criterion 2.4.10 might be misleading (nested headings). Not clear at first glance.	In response to other comments, we have made some changes to the techniques that related to nested headings (H42 and H69). H42 should describe the use of heading mark-up to label headings semantically, but also contained a good deal of discussion about how to use headings. We have removed the discussion and examples of ways to use headings to organize content from H42 (Success Criterion 1.3.1). However, we were unsure exactly which examples your comment refers to. Because the examples are part of the informative Understanding and Techniques documents, we are happy to work with you to improve these examples and address your concerns on a future draft.

Original Comment

Response from Working Group

The examples on Success Criterion 1.3.1 and on Success criterion
2.4.10 might be misleading (nested headings). Not clear at first glance.

In response to other comments, we have made some changes to the techniques that related to nested headings (H42 and H69). H42 should describe the use of heading mark-up to label headings semantically, but also contained a good deal of discussion about how to use headings. We have removed the discussion and examples of ways to use headings to organize content from H42 (Success Criterion 1.3.1).

However, we were unsure exactly which examples your comment refers to. Because the examples are part of the informative Understanding and Techniques documents, we are happy to work with you to improve these examples and address your concerns on a future draft.

Edit Issue (Last Edited: 2008-12-11 06:28:48)

Issue 2685: validity

Issue Created: 01 Dec 2008
Source: AC Comment
Component: Guideline 4.1
Disposition: NOT ACCEPTED (Reviewer Agrees)

Original Comment	Response from Working Group
worried that validity in terms of markup validation and standards compliance is just an advisory technique, that apparently it is not much promoted. Which means that regarding standardisation, WCAG 2.0 lags one step behind with respect to WCAG 1.0 that html and CSS validity were required.	The working group looked at the topic of validity carefully over an extended period of time and concluded that validity went beyond the scope of accessibility and therefore outside the group's charter because some aspects of validity do not affect accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification. Some aspects of "use technologies according to specification" and validity do relate to accessibility, and we have incorporated them as techniques or failures for the success criteria affected. We do recommend valid code and it is our number one sufficient technique listed for conforming to SC 4.1.1 (not just an advisory technique).

Original Comment

Response from Working Group

worried that validity in terms of markup validation and
standards compliance is just an advisory technique, that apparently it is
not much promoted. Which means that regarding standardisation, WCAG 2.0
lags one step behind with respect to WCAG 1.0 that html and CSS validity
were required.

The working group looked at the topic of validity carefully over an extended period of time and concluded that validity went beyond the scope of accessibility and therefore outside the group's charter because some aspects of validity do not affect accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.

Some aspects of "use technologies according to specification" and validity do relate to accessibility, and we have incorporated them as techniques or failures for the success criteria affected.

We do recommend valid code and it is our number one sufficient technique listed for conforming to SC 4.1.1 (not just an advisory technique).

Edit Issue (Last Edited: 2008-12-11 06:29:01)

Issue 2680: Technique H45 procedure description incomplete

Issue Created: 17 Nov 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Nov/0009.html (Public Comment)
Component: HTML/XHTML Techniques
Disposition: ACCEPTED (Reviewer Disagrees)

Original Comment	Response from Working Group
H45 is described as Procedure 1. Check that a longdesc attribute exists. 2. Check that the link in the longdesc attribute is valid 3. Check that the long description describes the original non-text content associated with it. Expected Results * #1 through #3 are all true But a) it doesn't explain on what elements we are to check for the longdesc attribute - presumably it should be IMG elements only in this case, and not FRAMES and IFRAMEs b) surely it's not implying that to pass H45 every element that supports longdesc attributes must in fact do so?? That would cause virtually every page on the web to fail immediately, as I don't think I've ever seen a commercial site using LONGDESC - at least, not correctly. c) what is meant by valid? That it's a valid url? Or it actually points to a resource that really exists? If the former, fine (and a very good idea, seeing I've seen quite a few cases where the LONGDESC attribute actually contains the descriptive text in the value, rather than a URL pointing to where to find the text), but if the latter, then testing this automatically becomes potentially expensive on a large site (well, it would, if anyone actually used LONGDESC).	Thank you, we have updated the test procedure to clarify these issues.

Original Comment

Response from Working Group

H45 is described as

Procedure

1. Check that a longdesc attribute exists.

2. Check that the link in the longdesc attribute is valid

3. Check that the long description describes the original non-text content associated with it.

Expected Results

* #1 through #3 are all true

But a) it doesn't explain on what elements we are to check for the longdesc attribute - presumably it should be IMG elements only in this case, and not FRAMES and IFRAMEs

b) surely it's not implying that to pass H45 every element that supports longdesc attributes must in fact do so?? That would cause virtually every page on the web to fail immediately, as I don't think I've ever seen a commercial site using LONGDESC - at least, not correctly.

c) what is meant by valid? That it's a valid url? Or it actually points to a resource that really exists? If the former, fine (and a very good idea, seeing I've seen quite a few cases where the LONGDESC attribute actually contains the descriptive text in the value, rather than a URL pointing to where to find the text), but if the latter, then testing this automatically becomes potentially expensive on a large site (well, it would, if anyone actually used LONGDESC).

Thank you, we have updated the test procedure to clarify these issues.

Edit Issue (Last Edited: 2008-12-01 18:23:40)

Issue Disposition Report for the 03 November 2008 WCAG 2.0 Proposed Recommendation

Summary

AC Comments

Public Comments

Details

Issue 2677: Low-power devices?

Issue 2688: Language of SC 1.4.5 unclear

Issue 2689: Expand info required by 4.1.2

Issue 2692: Statement of Partial Conformance

Issue 2693: require multiple platform support

Issue 2681: HTML Headings technique: duplicated

Issue 2690: G10 should not be acceptable for SC 4.1.2

Issue 2691: Understanding Accessibility Support needs updating

Issue 2695: G14 and G122 color technique: duplicated

Issue 2697: Techniques duplicated / identical G126 and G185

Issue 2698: Include H69 as technique for 2.4.6

Issue 2699: Clarify G167

Issue 2687: Style changer

Issue 2686: Too difficult

Issue 2694: Changing Short Names to Make it Easier to Understand when GL 1.2 Success Criteria Apply

Issue 2696: Change contrast ratio from 5:1 to 4.5:1

Issue 2678: Group common failures as well as (good) techniques

Issue 2679: H28 only mentions one type of SUBMIT button

Issue 2682: H33 sufficient technique for 2.4.4?

Issue 2683: Understanding 2.4.1: misleading point?

Issue 2684: Nested headings

Issue 2685: validity

Issue 2680: Technique H45 procedure description incomplete

Document Information