WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities
This is the official Issue Disposition report for the 30 April 2008 WCAG 2.0 Candidate Recommendation. The table at the top summarizes the issues, and is followed by details for each issue. The summary table structure is:
A database-driven view of this report is available which includes the ability to sort the columns. However, that version is not official.
Total Issues: 70
The working group received responses indicating that the reviewer agrees with the actions taken for 65 issues, disagrees with the working group response to 2 issues, and has received no response from reviewers on 3 issues.
| Issue | Type | Disposition | Acknowledgment | Component |
|---|---|---|---|---|
| 2598: Drop 2.1.3 and revise 2.1.1 | proposal | NOT ACCEPTED | reviewer agrees | 2.1.1 (Keyboard) |
| 2599: Reorganizing the requirements in GL 1.2 | editorial | NOT ACCEPTED | reviewer agrees | Presentation and Structure |
| 2600: accessibility supported technology | comment | NOT ACCEPTED | reviewer disagrees | CR4 (Accessibility-Supported Technologies Only) |
| 2602: Fieldset - Legend techniques | proposal | ACCEPTED | reviewer agrees | HTML/XHTML Techniques |
| 2603: Longdesc | proposal | ACCEPTED | reviewer agrees | HTML/XHTML Techniques |
| 2604: H81: Nested Lists | proposal | ACCEPTED | reviewer agrees | HTML/XHTML Techniques |
| 2605: About technique H48 | proposal | ACCEPTED | reviewer agrees | HTML/XHTML Techniques |
| 2606: SC 3.2.5 vs. SC 2.2.4 and G75 and G76 | proposal | NOT ACCEPTED | reviewer agrees | 3.2.5 (Change on Request) |
| 2607: Duplicate General techniques: form validation | proposal | NOT ACCEPTED | reviewer agrees | General |
| 2608: Duplicate General techniques: alt-text | proposal | NOT ACCEPTED | reviewer agrees | General |
| 2609: providing a multipage view rather than a single file version of QuickRef | proposal | NOT ACCEPTED | reviewer agrees | Presentation and Structure |
| 2610: Should C16 also refer to SC 2.4.7? | proposal | ACCEPTED | reviewer agrees | CSS Techniques |
| 2611: Understanding 3.2.2 | impl. issue | ACCEPTED | reviewer agrees | 3.2.2 (On Input) |
| 2612: inconsistency with G122 | proposal | PARTIAL/OTHER | reviewer agrees | General |
| 2613: Additional resource for consideration | proposal | ACCEPTED | reviewer agrees | 1.1.1 (Non-text Content) |
| 2615: Image use cases that WCAG doesn't address | proposal | NOT ACCEPTED | reviewer agrees | 1.1.1 (Non-text Content) |
| 2616: Editorial: WCAG 2.0 is hard to connect to concrete HTML authoring | editorial | NOT ACCEPTED | none received | General |
| 2617: Terminology clarifications requested by JIS | translation | ACCEPTED | reviewer agrees | Translations |
| 2618: Geospatial mapping applications | question | PARTIAL/OTHER | none received | General |
| 2619: Large Print | editorial | ACCEPTED | reviewer agrees | 1.4.3 (Contrast (Minimum)) |
| 2620: "minimum" or "enhanced"? | editorial | NOT ACCEPTED | reviewer agrees | 1.4.6 (Contrast (Enhanced)) |
| 2621: wording of "dialog" | editorial | ACCEPTED | reviewer agrees | Appendix A: Glossary |
| 2622: Note 5 in "conforming alternate version" | translation | PARTIAL/OTHER | reviewer agrees | Appendix A: Glossary |
| 2623: "virtual magnifying glasses" in Note 1 for "viewport" | translation | PARTIAL/OTHER | reviewer agrees | Appendix A: Glossary |
| 2624: "URI" or "URL" | translation | PARTIAL/OTHER | reviewer agrees | Appendix A: Glossary |
| 2625: 18 point or 14 point bold | question | ACCEPTED | reviewer agrees | Appendix A: Glossary |
| 2626: large scale text for CJK | comment | ACCEPTED | reviewer agrees | Appendix A: Glossary |
| 2627: "must be presented in non-text format" | proposal | ACCEPTED | reviewer agrees | 1.1.1 (Non-text Content) |
| 2628: on a full-screen window | editorial | PARTIAL/OTHER | reviewer agrees | 1.4.8 (Visual Presentation) |
| 2629: definition of "process" | editorial | NOT ACCEPTED | reviewer agrees | Appendix A: Glossary |
| 2630: glyph for English | question | PARTIAL/OTHER | reviewer agrees | 1.4.8 (Visual Presentation) |
| 2631: G182: will this include underlining text links | impl. issue | PARTIAL/OTHER | reviewer agrees | General |
| 2632: Instances where technique G153 is not met. | impl. issue | PARTIAL/OTHER | reviewer agrees | General |
| 2633: Is 3.3.1 relevant if errors are not automatically detected? | impl. issue | PARTIAL/OTHER | reviewer agrees | 3.3.1 (Error Identification) |
| 2634: "all" or "potentially serious" mistakes? | impl. issue | ACCEPTED | reviewer agrees | 3.3.6 (Error Prevention (All)) |
| 2635: H44 and H65 do not seem related to 3.2.4 | impl. issue | ACCEPTED | reviewer agrees | HTML/XHTML Techniques |
| 2636: H33 Creates accessibility issues | impl. issue | PARTIAL/OTHER | reviewer agrees | HTML/XHTML Techniques |
| 2637: H30 examples encourage wordy links | impl. issue | ACCEPTED | reviewer agrees | HTML/XHTML Techniques |
| 2638: Inconsistent labeling causing confusion. | impl. issue | NOT ACCEPTED | none received | General |
| 2639: G65 - editorial correction | comment | NOT ACCEPTED | reviewer agrees | General |
| 2640: G156 should be a sufficient technique | impl. issue | NOT ACCEPTED | reviewer agrees | 1.4.3 (Contrast (Minimum)) |
| 2642: Don't make contrast conditional on font size | impl. issue | NOT ACCEPTED | reviewer agrees | 1.4.3 (Contrast (Minimum)) |
| 2643: Success Criteria seem redundant, etc. | impl. issue | PARTIAL/OTHER | reviewer agrees | General |
| 2644: Are characters in the Windows Character Map images of text? | impl. issue | PARTIAL/OTHER | reviewer agrees | 1.4.3 (Contrast (Minimum)) |
| 2645: Provide success feedback | impl. issue | PARTIAL/OTHER | reviewer agrees | 3.3.6 (Error Prevention (All)) |
| 2646: H44 : sufficient technique for 3.2.4? | comment | ACCEPTED | reviewer agrees | HTML/XHTML Techniques |
| 2647: Two comman failures missing | impl. issue | PARTIAL/OTHER | reviewer agrees | 1.1.1 (Non-text Content) |
| 2648: F42 is overly broad. | impl. issue | PARTIAL/OTHER | reviewer agrees | Common Failures |
| 2649: Common failure needed for elements that should allow focus, but don't | impl. issue | ACCEPTED | reviewer agrees | 2.1.1 (Keyboard) |
| 2650: F78: Overwriting default focus indicator | comment | ACCEPTED | reviewer agrees | Common Failures |
| 2651: Extended Audio Description | impl. issue | ACCEPTED | reviewer agrees | 1.2.7 (Audio Description (Extended)) |
| 2652: Sign Language for Videos | impl. issue | PARTIAL/OTHER | reviewer disagrees | 1.2.6 (Sign Language) |
| 2653: Audio Background | impl. issue | PARTIAL/OTHER | reviewer agrees | 1.4.7 (Low or No Background Audio) |
| 2654: Space-and-a-half between paragraphs | impl. issue | ACCEPTED | reviewer agrees | 1.4.8 (Visual Presentation) |
| 2655: Evaluating Reading Levels | impl. issue | PARTIAL/OTHER | reviewer agrees | 3.1.5 (Reading Level) |
| 2656: Editorial problems - German translation | translation | PARTIAL/OTHER | reviewer agrees | Translations |
| 2658: Decorative Images | impl. issue | PARTIAL/OTHER | reviewer agrees | 1.1.1 (Non-text Content) |
| 2659: Complex diagrams | impl. issue | ACCEPTED | reviewer agrees | 1.1.1 (Non-text Content) |
| 2661: Clarification of SC 1.4.7 | impl. issue | ACCEPTED | reviewer agrees | 1.4.7 (Low or No Background Audio) |
| 2662: National Apology to the Stolen Generations | impl. issue | PARTIAL/OTHER | reviewer agrees | conforming alternate version |
| 2663: National Apology to the Stolen Generations | impl. issue | ACCEPTED | reviewer agrees | 1.2.3 (Audio Description or Full Text Alternative) |
| 2664: Do modal dialogs violate keyboard trap? | impl. issue | ACCEPTED | reviewer agrees | 2.1.2 (No Keyboard Trap) |
| 2666: On behavior of containers that are designed to fit limited text | impl. issue | ACCEPTED | reviewer agrees | 1.4.4 (Resize text) |
| 2669: SC 1.4.3, SC 1.4.6 and font size units | impl. issue | ACCEPTED | reviewer agrees | 1.4.3 (Contrast (Minimum)) |
| 2671: Statement of partial conformance | comment | PARTIAL/OTHER | reviewer agrees | Conformance |
| 2672: Described in a way that users can identify | comment | PARTIAL/OTHER | reviewer agrees | Conformance |
| 2673: Partial conformance and conformance requirement 5 | comment | PARTIAL/OTHER | reviewer agrees | Conformance |
| 2674: Must links to other media warn users? | comment | PARTIAL/OTHER | reviewer agrees | General |
| 2675: Interference with screen reader | comment | PARTIAL/OTHER | reviewer agrees | 1.4.2 (Audio Control) |
| 2676: Must captions be resizable? | comment | ACCEPTED | reviewer agrees | 1.4.4 (Resize text) |
Issue Created: 20 May 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008May/0005.html
Component: 2.1.1 (Keyboard)
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| There is no difference between 2.1.1 and 2.1.3 if a Web page does not contain content that uses analogue input (i.e. the underlying function requires input that depends on the path of the user's movement and not just the endpoints). Question: a. If all functionality on such a Web page is keyboard-accessible, does it automatically meet AAA SC 2.1.3? b. Conversely, can one argue that making such a Web page keyboard-accessible is only a "AAA" requirement and disregard it as a "A" level requirement? If the answer to (a) is "Yes" and (b) above is "No", I feel that The reason for repeating the requirement at 2.1.3 is unclear or even futile. In that event I reiterate that 2.1.3 be dropped and 2.1.1 be re-stated as: SC2.1.1: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. This does not apply to content that uses analogue input (i.e. the underlying function requires input that depends on the path of the user's movement and not just the endpoints). (I recall I had made this suggestion to TIETAC too). | The answer to (a) is "yes". If a Web page does not contain content that uses analogue input, then if it meets 2.1.1, it will also meet 2.1.3.
The answer to (b) is "no". The Level A success criterion must be satisfied to conform at Level A. That it also satisfies a Level AAA success criterion is immaterial for Level A conformance. Note, of course, that your questions were limited to Web pages that do not contain analogue input. For pages which do contain analogue input, satisfying 2.1.1 does not also satisfy 2.1.3. Your proposed restatement of 2.1.1 is equivalent to the current success criterion 2.1.1. If 2.1.3 were dropped, then Web pages that contain analogue input would conform at Level AAA. The purpose of 2.1.3 is to ensure that all content is keyboard operable. At level A, it is permissible to have content that requires time-dependant analog input without providing a keyboard accessible alternative. This is not permissible at Level AAA because of 2.1.3. Response sent 17 Jun 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jun/0006.html |
Issue Created: 28 May 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008May/0006.html
Component: Presentation and Structure
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| In attempting to harmonize ATAG 2.0's "Guideline A.2.2 [For the authoring tool user interface] Display synchronized alternatives for synchronized media" with WCAG 2.0's "Guideline 1.2 Time-based Media: Provide alternatives for time-based media" I found the WCAG guideline confusing because it's bold labels mix the media types to be made accessible (e,g,"Audio-only and Video-only (Prerecorded):") with the ways this can be done (e.g. "Sign Language"). I think it makes the most sense to follow the lead of WCAG Guideline 1.1 and focus on the original media since that's what content authors will have in front of them. NOTE: The proposed changes are purely organizational and are not intended to modify any normative requirement. ----------------------------------------------------------- LEVEL A: NOTE: Guideline 1.2 does not apply to any media that act as a *media alternatives for text* and are clearly labeled as such. *Prerecorded Media:* *Audio-only* - A *text alternative* is provided. *Video-only* - Either: + a text alternative is provided or + an audio track is provided that presents equivalent information. *Synchronized Audio and Video* - *Captions* of the audio are provided. - Either: + a *full text alternative for synchronized media including any interaction* is provided or + *audio descriptions* of the video are provided. ----------------------------------------------------------- LEVEL AA: *Prerecorded Media:* *Synchronized Audio and Video* - *Audio descriptions* of the video are provided. *Live Media:* *Synchronized Audio and Video* - Live *captions* of the audio are provided. ----------------------------------------------------------- LEVEL AAA: *Prerecorded Media:* *Video-only* - A *text alternative* is provided. *Synchronized Audio and Video* - *Sign language interpretation* of the audio is provided. - *Extended audio description* of the video is provided. - A *full text alternative for synchronized media including any interaction* is provided. *Live Media:* *Audio-only* - A *text alternative* is provided. | The handles (bold labels) for each success criterion are meant to be unique, so that they can be a shorthand for referring to the success criterion and a memory aid for remembering what it addressed. The proposed reorganization reuses handles, since different conformance levels include different requirements for the same media types.
Response sent 24 Jul 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0013.html |
Issue Created: 17 Jun 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008May/0000.html
Component: CR4 (Accessibility-Supported Technologies Only)
Disposition: NOT ACCEPTED (Reviewer Disagrees)
| Original Comment | Response from Working Group |
|---|---|
| We noticed that WCAG 2.0 advanced to a candidate recommendation even though we have not received a follow up response to one of the issues we raised (which remains unresolved in the candidate recommendation). The issue in question is the one that we raised on April 9 (http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Apr/0043.html) regarding perceived gaps in the "accessibility supported" definition (which is a continuation of the absence of support for programmatic objects issue that we raised earlier). Are you still considering our recommendation for resolving this issue or was the issue that we raised previously accidentally overlooked? Thank you, Common Look and Feel Office | Bureau de la normalisation des sites Internet Treasury Board of Canada, Secretariat | Secrétariat du Conseil du Trésor du Canada Government of Canada | Gouvernement du Canada -----Original Message----- From: Common Look and Feel/Normalisation des sites Internet Sent: April 9, 2008 3:22 PM To: 'public-comments-WCAG20@w3.org' Cc: 'Loretta Guarino Reid' Subject: RE: Your comments on WCAG 2.0 Last Call Working Draft of December, 2007 We agree that a technology (such as JavaScript) cannot be considered an accessibility supported technology if one or more of the supported environments requires that technology to be disabled. We also agree that a technology cannot be considered an accessibility supported technology if one or more of the supported user agents (such as cell phones, PDAs, or specialized browsers) cannot support the technology natively or through a widely-distributed plugin. The problem is that these requirements are not clear in the "accessibility supported" definition (http://www.w3.org/TR/WCAG20/#accessibility-supporteddef). We recommend including the following wording in the "accessibility supported" definition and to also add "environment" to the glossary as it is used repeatedly throughout WCAG 2.0 and the meaning can be a bit unclear: 3. The Web content technology is not restricted in any of the supported environments. This means that all of the following are true: a) The technology is either supported natively or supported through widely distributed plugins for all of the supported user agents in the supported environments; AND b) The technology is not restricted from being installed, enabled, or used in any of the supported environments; AND c) The supported user agents, widely distributed plugins, and other technologies required to provide support for the technology are not restricted from being installed, enabled, or used in any of the supported environments. Common Look and Feel Office | Bureau de la normalisation des sites Internet Treasury Board of Canada, Secretariat | Secrétariat du Conseil du Trésor du Canada Government of Canada | Gouvernement du Canada -----Original Message----- From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] Sent: April 3, 2008 5:42 PM To: Common Look and Feel/Normalisation des sites Internet Cc: public-comments-WCAG20@w3.org Subject: Re: Your comments on WCAG 2.0 Last Call Working Draft of December, 2007 > B) CONCERNS WITH COMMENT 3 RESPONSE > > Quote from the Comment 3 response: > "The situations you describe are addressed differently in WCAG 2.0 than in 1.0. WCAG 2.0 has an improved set of conformance requirements. Refer to http://www.w3.org/TR/WCAG20/#conformance-reqs. We believe this is a more effective and thorough approach." > > The problem is that the conformance requirements do not cover a technology being disabled or unavailable resulting in accessibility issues, it only covers whether a technology is "accessibility-supported" or not which only deals with compatibility with assistive technologies. > > a) What about users with cell phones and other Internet-enabled devices? The way things are worded now, you could make JavaScript rendered content that is fully accessible to assistive technologies and keyboard users yet unavailable when JavaScript is disabled and the page could still achieve full compliance. > > b) What if the device does not support the required plugin (such as Flash)? There could be an accessibility supported plugin that is available for normal browsers but are not available for certain devices resulting in Web pages. This would meet the conformance requirements but still result in content being unavailable to certain users. > > Ultimately the conformance requirements as they are worded now leave many loopholes where sites can be completely inaccessible and unusable on certain user agents yet still be fully compliant (such as a fully JavaScript-rendered site that is fully accessible to assistive technologies but just an empty page on a handheld device that does not support JavaScript or secure environments where JavaScript is disabled). > > RECOMMENDATION: Either expand "Accessibility-Supported Technologies" conformance requirement to cover the case where an accessibility-supported technology is disabled or the required accessibility-plugin is not supported by the widely distributed user agent (cell phones and Internet-enabled devices are pretty common but most do not support Flash or JavaScript). > --------------------------------------------- Response from Working Group: --------------------------------------------- If a technology is not supported on the users' user agents (including such user agents as cell phones or Internet-enabled devices), then the technology is not accessibility supported. If an author is producing content for a secure environment where Javascript is disabled, then the author cannot rely on Javascript. Determining the range of user agents used in an environment is a challenge, but one which authors must already face. It is important that information about which user agents and assistive technologies support different technologies be available to authors, so they understand the environment for which they are producing content. Authors cannot control whether or not a user disables a technology such as Javascript or fails to load a plug-in that is available to users. As long as the conformance claim documents which technologies are relied upon, and as long as the user agents can support that technology, the author has met the accessibility-supported requirements of WCAG 2.0 Thanks again for the interest that you have taken in these guidelines. Could we ask you to let us know whether or not you are satisfied with this response by Wed, April 9? Loretta Guarino Reid, WCAG WG Co-Chair Gregg Vanderheiden, WCAG WG Co-Chair Michael Cooper, WCAG WG Staff Contact On behalf of the WCAG Working Group | Our apologies for leaving this dangling. We believed that we had confirmed via telephone that all of your Last Call comments had been addressed to your satisfaction.
In the WCAG 2.0 supporting document, “Understanding Conformance” there is a discussion about the conditions for a WCAG 2.0 Success Criteria. The text is as follows: "All Success Criteria must be important access issues for people with disabilities that address problems beyond the usability problems that might be faced by all users. In other words, the access issue must cause a proportionately greater problem for people with disabilities than it causes people without disabilities in order to be considered an accessibility issue (and covered under these accessibility guidelines)." http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20080505/intro.html Taking the example you've provided, if the use of JavaScript is incompatible with handheld devices (and creating a blank page), then nobody will be able to access the content (regardless of ability) and therefore it is a global problem affecting all users. It would not affect people with disabilities disproportionately, and as such it falls beyond the scope of WCAG. This would also be true in environments where JavaScript is prohibited in a secure government environment. No one could access the content. In order for content to conform, SC 2.1.1 requires it must be keyboard accessible regardless of technology. Success Criteria 1.1.1 requires it be available in text. We believe the current language of Accessibility-Supported covers closed environments where conforming content is targeted for that environment. The definition of Accessibility Supported is already complex. We believe that introducing policy constraints (such as those in a closed environment) as well as technical constraints into the definition will make it more difficult to understand. Response sent 28 Jun 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jun/0024.html |
Issue Created: 01 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0000.html
Component: HTML/XHTML Techniques
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Please refer to H71 and H82: both relate to using fieldset - legend method to group form controls and refer to SC 1.3.1 Admittedly the 'description' for both differ. The former relates to a group of controls sharing common descriptive / instructional text. But other than that I do not see why this technique should be listed twice. | We have combined these into a single technique.
Response sent 10 July 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0006.html |
Issue Created: 01 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0000.html
Component: HTML/XHTML Techniques
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| The longdesc for images is mentioned and illustrated by H37 and H45. Maybe reference to longdesc technique should be retained only in H45. | We have removed the discussion of longdesc from H37 and have added H45 to the Related Techniques.
Response sent 10 July 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0006.html |
Issue Created: 01 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0000.html
Component: HTML/XHTML Techniques
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| H81: Using nested list to convey link purpose: I think AT support is lacking and should be noted under user agent notes | We added a user agent note as requested and also added text to the technique description. We agree that this technique is not currently well supported by assistive technology.
Response sent 03 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0001.html |
Issue Created: 08 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0003.html
Component: HTML/XHTML Techniques
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| HTML technique H48 deals with marking up lists. One of the tests is: "Check that content that has the visual appearance of a bulleted list is marked as an unordered list". Comment: Even when bullets are not used, a sighted user can still determine that certain items make up a list. For instance, top-nav or footer links placed in one line horizontally. A sighted user would be able to relate these items as a group of n items. These should also be marked up as a list with no bullets. So I suggest that the test should be worded as: "Check that content that has the visual appearance of a list (with / without bullets) is marked as an unordered list". | We have changed the test procedure as suggested.
Response sent 10 July 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0005.html |
Issue Created: 10 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0004.html
Component: 3.2.5 (Change on Request)
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| SC 2.2.4 Interruptions: Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency. (Level AAA) SC3.2.5 Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA) Comment: 3.2 deals with making Web page content behave in predictable ways and the emphasis is on consistent layout, navigation and identification. This is in keeping with the "understanding" principle. I believe a change in context caused by auto updating content (3.2.5) is covered by interruptions (2.2.4) that upset task focus. Such an interruption or change in context makes it difficult to operate (or even read) the Web page. So change of context by auto updating content is a transgression of the "operate" principle than the "understand" principle. Difficulty in understanding posed by auto updating content is a consequence of difficulties posed during operation. On the other hand, changes in context referred to 3.2.1 or 3.2.2 are also unexpected but are based on user action (focus change / form input) and certainly hamper understanding. As a consequence it makes operation difficult. The supporting techniques for 2.2.4 and 3.2.5 too are identical: G75 for 2.2.4: Providing a mechanism to postpone any updating of content G76 for 3.2.5: Providing a mechanism to request an update of the content instead of updating automatically I think this is just a play of words and both SC 3.2.5 and technique G76 can be deleted without any loss. | Response sent to commenter, 24 July 2008:
While we agree that listing automatic updates under 3.2.5 (Change on Request) overlaps somewhat with the requirements of 2.2.4 (Interruptions), the two do not overlap completely in that not all changes of context would be considered an interruption. For example, providing a link that causes a movie to be opened in a media player rather than in the current user agent would not be an interruption, but would be a change of context. Regarding G75 and G76, providing a mechanism that postpones or allows users to configure the frequency of automatic updates (G75) is different than providing a mechanism that allows users to manually request them (G76). You are correct however, that G76 should have been listed under 2.2.4 and we have corrected that error. ----------------------- Reply from commenter at http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0016.html : I beg to differ with the WG on this issue. A link that opens up a presentation in a media player does cause a change in context but is a user initiated request (like the ones I stated in my email). Such links or UI elements will require advisory text like "launches in new window in media player" or the like. This link for instance cannot be turned off as required by the "or" clause of 3.2.5 because the content requires a player to display it. As the SC suggests, should the link be disabled or hidden if the user prefers not to view content in a media player? Perhaps the content and the player are fully accessible and no alternative rendering is available. User initiated change in context cannot cause an interruption because the user expects something to happen by activating an UI element. And advisory text would be a sufficient technique for this. Auto updating / refreshing content that is not user initiated is primarily an interruption which may also cause a change in context. Like a pop-up or the start of a Flash presentation suddenly. (The techniques doc too refers to change in context caused by auto updating content while discussing G76). I would find 3.2.5 acceptable if it read: "Changes of context are initiated only by user request." Causing a change in context without prior notification when a UI element is activated by user is a failure of 3.2.5. I still think that G75 and G76 are no different. ----------------------- The working group believes these are different. An interruption usually means that the user is returned to their original position after the interruption ends. A change of context generally would not. So 2.2.4 wouldn’t necessarily cover 3.2.5. And 3.2.5 doesn’t cover 2.2.4 because interruptions can take the form of a dialog box or other event that doesn’t necessarily change the context. We do agree that these are very similar - and a single success criterion might be constructed that would cover both. But it is too late in the process now to do this. And it would not change the substance of the guidelines. Response Sent 23 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0028.html |
Issue Created: 11 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0007.html
Component: General
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| G83, G84 and G85 that relate to SC 3.3.1 and 3.3.3 employ the same testing techniques: Check if validation errors are described in text with appropriate tips for correction. They could be incomplete data, incorrect range of values or incorrect format or even other (unstated) errors like values entered in one field may not be consistent with other entries in the form. All are basically validation errors. Three separate techniques are not warranted. Merge them. G83: Providing text descriptions to identify required fields that were not completed G84: Providing a text description when the user provides information that is not in the list of allowed values G85: Providing a text description when user input falls outside the required format or values | While it is true that these are all examples of validation errors, we think it is helpful to separate them. It draws more attention to these particular types of validation for which there are suggestions available. This list is by no means exhaustive, and a generic validation technique would be a good addition. Would you help us by writing one and submitting it via http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/ ?
Response sent 24 July 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0014.html |
Issue Created: 11 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0007.html
Component: General
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| G82, G94 and G95: Not clear why there are 3 techniques. There are copious notes on how alt text / short text alts should be written in different situations. Significant portions of descriptions for G94 and G95 are identical. So I suggest: merge all three. G82: Providing a text alternative that identifies the purpose of the non-text content G94: Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content G95: Providing short text alternatives that provide a brief description of the non-text content | Although the techniques are quite similar, they address different situations and require different types of information in the text alternative. G82, which only requires that the purpose of the non-text content be identified, would not be sufficient for Situation A of SC 1.1.1, where it is possible to provide a text equivalent to the non-text content.
We have added pointers between the two techniques to show they are related. Response sent 24 July 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0014.html |
Issue Created: 21 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0008.html
Component: Presentation and Structure
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| When the "How to Meet SC X.Y.Z" link is selected from the WCAG 2.0 document, the full "How to Meet WCAG 2.0" document is loaded every time. When the connection is slow, it takes quite a while to load and the page jumps around until the browser can render the correct scrolling position within the display. One also ends up with more information than one had requested, which was just to learn more about implementing a specific Success Criterion. Note: the "Understanding SC X.Y.Z" link takes users to a dedicated standalone page which has a clear and easy to use navigation, as well as more efficient orientation cues. Proposed Change: 1. Provide a multipage view on the "How to Meet WCAG 2.0" document as the default presentation, as it is often easier to use. "How to Meet SC X.Y.Z" links in the WCAG 2.0 document should take users to the specific pages of the multipage resource. 2. Provide an option in the customizable interface to select a single page view for those who want a full listing (for example to print out a checklist of requirements to cover). Note: the "Understanding WCAG 2.0" document also has an option to display it as a single file. | 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. If an author is interested only in a specific success criterion, they can use the "Understanding SC X.Y.Z" document, which includes the short list of sufficient and advisory techniques and common failures for a given success criterion.
At this time, we have decided not to make the changes you have suggested, but we will keep them in mind should time and resources become available to explore this further. Response sent 03 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0003.html |
Issue Created: 21 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0009.html
Component: CSS Techniques
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| The stated purpose, examples and evaluation process for C15 and C16 are quite identical. But the former refers to SC 2.4.7 and the latter to C16. Should C16 also refer to SC 2.4.7? Refer to following: C15: Using CSS to change the presentation of a user interface component when it receives focus C16: Changing the background color or border of the element with hover and focus For C15: The objective of this technique is to demonstrate how the current focus can be made visually evident by changing the appearance of the focused element with CSS styling. For C16: The objective of this technique is to demonstrate how visual appearance may be enhanced via style sheets to provide visual feedback when an interactive element has focus or when a user hovers over it using a pointing device. | We have combined techniques C15 and C16.
Response sent 28 Aug 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0049.html : |
Issue Created: 22 Jul 2008
Source: (Original comment not archived)
Component: 3.2.2 (On Input)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| My developers in Germany recently went through the 3.2.2 understanding doc and found some problems. I was able to help them due to my understanding of the matter, but I think we ought to make some corrections. Here are the issues. First example of SC, “A form is provided for creating calendar entries in a Web based calendaring and scheduling application. Along with the standard fields for subject, time and location, there is a set of radio buttons to select the type of calendar entry to create. The calendar entry type can be meeting, appointment or reminder. If the user selects the radio for meeting, additional fields are displayed on the page for entering the meeting participants. Different fields appear if the reminder button is chosen. Because only parts of the entry change and the overall structure remains the same the basic context remains for the user. Instructions at the beginning of the Web page explain the behavior of each radio button and the fields that appear when the button is selected.” Pay attention to the last two sentences. It say the example is NOT a change of context on the second last sentence. Then we go on to say that instruction is needed on the next sentence. That is a contradiction. If the scenario is not a change of context, which I agree, then no instruction is needed according to the success criteria. If we intend to show an example to which instruction is needed, then we need a real change of context, not a minor change of content. The second example with tab strip seems to say that a change of content due to switching from tab to tab is not considered a change of context because it is an expected behavior. Although I agree, it does not seem to the appropriate decision criteria since “expected behavior” is not part of the change of context definition. We ought to tighten up either the example language or the definition. Obviously, that would stress test our agreement as to what degree of change of content constitutes a change of context. Oh that can of worm! The intent section ends with, “Changes of context are appropriate only when it is clear that such a change will happen when a field is selected or a button is pressed.” Maybe it is because my audience are Germans, but they are confused as to whether “only when it is clear that such a change will happen” applies to “a button is pressed”. I told them it does not, but they were really confused over it. Considering that many of our audience may not be fluent in English, we may want to simplify that. | Thank you for pointing out these issues in Understanding SC 3.2.2. We have clarified them in the current document.
Response sent 24 July 2008. |
Issue Created: 24 Jul 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jul/0011.html
Component: General
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| I was looking at WCAG 2.0 forms techniques to see what might apply to older users - went to two different techniques places and found different suggestions in the examples: http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/G14.html Example 4 recommends an "*" for required fields http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/G122.html Example 1 illustrates the better practice of using words (albeit an abbreviation) and recommends "(req)" for required fields The literature is reporting that older users often have difficulty with the "*" solution (as do/did WindowsEyes users and also others with low-vision). Also, better than "(req)" is "(required)" for required fields - no one should be confused then. Proposed Change: Both examples should preferably use "(required)", in addition to colour, to indicate mandatory fields. | We have revised technique G122 as you proposed.
The working group felt it was important to include an example that includes the use of asterisk because we feel that it is sufficient to meet the success criterion and its use is commonly understood on the Web today. However, we added a new sufficient technique and a note to the example in G14 to highlight ways to reduce the accessibility challenges caused by the asterisk. We have added the following note to the example in G14 related to asterisks: Note: Asterisks may not be read by all screen readers (in all reading modes) and may be difficult for users with low vision because they are rendered in a smaller size than default text. It is important for authors to include the text indicating that asterisk is used and to consider increasing the size of the asterisk that is presented. We have also added a new sufficient technique to SC 3.3.2, "H90: Indicating required form controls", where we discuss using a larger font size for asterisks and alerting the user to its use at the start of the form. http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H90.html Response sent 8 Aug 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0002.html |
Issue Created: 06 Aug 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0001.html
Component: 1.1.1 (Non-text Content)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| I note you do not list the resources from RNIB, a W3C member. Proposed Change: Please consider http://www.rnib.org.uk/wacblog/articles/better-connected/better-connected-better-results-alt-text/ and/or http://www.rnib.org.uk/wacblog/images/captcha-if-youre-names-not-down-youre-not-coming-in/#more-150 for 1.1.1 Other articles from the RNIB may be suitable resources for other sections (eg see http://www.rnib.org.uk/wacblog/ and http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_checkpoints.hcsp#P8_458) | Thank you, we have added these resources to Understanding 1.1.1 and other RNIB
articles to other sections. Response sent 29 Aug 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0031.html |
Issue Created: 20 Aug 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0013.html
Component: 1.1.1 (Non-text Content)
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| This comment is about Guideline 1.1 Text Alternatives, and this comment is about the substance of the guideline. The HTML5 draft[1] gives advice and examples for including text alternatives for a variety of image uses cases. As far as I can tell, the following use cases aren't addressed by WCAG 2.0: * A diagram illustrates what is already said textually. (HTML5 says alt="" for this case.) * A user-uploaded image whose content is unknown to the programmer of the HTML generator that frames the image for Web display and the user hasn't supplied a text alternative. (HTML5 says to put the description of what kind of image the image is in curly braces in the alt attribute. E.g. a photo sharing site would use alt="{photo}".) Proposed change: I propose aligning with the HTML5 draft by saying that an image be marked as omissible from non-visual rendering if it illustrates what the surrounding prose already says. I propose aligning with the HTML5 draft by saying that if the generator of markup does not have a text alternative available, it should use the natural-language expression describing the kind of content (to the precision known to the generator) as the text alternative and use a mechanism provided by the host format for marking the text as not really being a text alternative but an indication of what kind of non-text content is in question. [1] http://www.w3.org/html/wg/html5/ -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ | We try to make our guidelines match technical standards to the extent possible.
We have looked at the HTML 5 standard and we note that although many of the examples match the WCAG 2.0 guidelines - some do not, including the ones you mentioned. (although the second example you mention seems to have been removed from the September editors draft) We are adding one sufficient technique to make it clear that some of the examples in HTML 5 do conform with WCAG. The new technique is: G196: Using a text alternative on one item within a group of images that describes all items in the group (http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/G196.html) As for the other one you cite above, we think that WCAG currently draws the line in the right place and changing the standard would create problems for accessibility. Response sent 23 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0029.html |
Issue Created: 20 Aug 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0014.html
Component: General
Disposition: NOT ACCEPTED (No response from reviewer)
| Original Comment | Response from Working Group |
|---|---|
| This comment applies to the whole set of WCAG 2.0 documents as is an editorial comment. I tried to compare alt advice in the HTML5 draft with WCAG 2.0. I found that matching a concrete image use case to suggested HTML syntax is harder when reading WCAG 2.0 than when reading HTML5. Splitting the content of WCAG 2.0 across three documents and trying to operate on a technology-agnostic abstraction level makes it WCAG 2.0 less approachable than a document that covers concrete cases using a specific markup language as the example. Proposed solution: Making the Understanding document the spec and introducing things by concrete example cases instead of abstract terms. | One of the requirements of WCAG (http://www.w3.org/TR/wcag2-req/) is to ensure that requirements may be applied across technologies and to ensure that the revision is "backwards and forward compatible". We agree that this makes the language of the guidelines more abstract and we have provided the Understanding and Techniques documents to help authors better understand how to apply the guidelines when using different technologies.
Note that because the Understanding and Techniques documents are not normative, it possible for the working group to add to and revise them without going back through the W3C Recommendation process. This will, for example, make it possible for us to include HTML5 techniques when it becomes a recommendation. How to Meet WCAG 2.0 (http://www.w3.org/WAI/WCAG20/quickref/) already addresses part of this concern as it can be configured to show only the techniques in the technologies of interest. We hope that once WCAG 2.0 has become a Recommendation and is stable, additional document and resources will be created that will make it easier for authors who are only interested in specific technologies. Response sent 29 Aug 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0048.html |
Issue Created: 22 Aug 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0015.html
Component: Translations
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0015.html There are both "accessibility supported" and "accessibility-supported" in WCAG 2.0 CR. Are they intentional or editorial mistakes? Proposed Change: Need consistency through the document if they are editorial mistakes. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0016.html We need clarification on what "symbols" means. Does it mean graphic symbols for people with developmental disorders and speech comprehension difficulties? Or does it imply more than it? Proposed Change: Hard to translate. Add the explanation to the Glossary. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0017.html What do you want to say by "indicating an action"? Some concrete examples would be helpful for us to translate the phrase. Proposed Change: Hard to translate. Provide examples. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0018.html The term "mechanism" is defined in the Appendix A: Glossary. Is it used in unusual meaning? Proposed Change: Just to clarify. We need your help in order to find the appropriate word in Japanese. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0019.html What is "glyph"? For Japanese, it can be translated in several ways. We need to make sure what it indicates. Could you provide us with the visual examples(not in text)? It will allow us to find an appropriate word in Japanese. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0020.html We couldn't understand both "line spacing" and "leading". Could you explain both by using visual examples? There are multiple interpretation in Japan and both are confusing. For "line spacing" / "leading", We guess there would be differences among languages. Proposed Change: Need visual explanation on what "line spacing" is and what "leading" is. We'll be able to translate them if we see both. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0021.html We need more details on "space-and-a-half". It is one of the jargon. We couldn't find an appropriate word in Japanese. Proposed Change: Need explanation. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0022.html We need the clarification what "path" means. Is it applied to pointing device only? Or also keyboard interfaces? Or any other movement? Proposed Change: "path" can be translated to wider range of meaning. Need clarification. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0023.html "timing" = "time limit"? The "Note" reads "While exceptions to Success Criterion 2.2.1 where timing is essential exist,". Does "timing" mean "time limit"? Proposed Change: Need explanation. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0024.html Does it mean that "5.0 seconds" is not included and "5.01 seconds" is included? Proposed Change: Just to confirm. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0025.html What "process" means In Note 3, it reads "Content that is updated from a process, real-time or remote stream". We couldn't understand "a process, real-time or remote stream". Is this mean "process, realtime stream or remote stream"? Also we couldn't understand what "process" is in this Note 3. Proposed Change: Very hard to translate. Could you say this in other words? http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0026.html Why "bypass"? We use "skip" for this. We'd like to know why you use "bypass" instead of "skip". What is the difference?? Proposed Change: Need explanation for appropriate translation. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0027.html "sections" = "section" in Glossary? In Note 2, it reads "This success criterion covers sections within writing,". We couldn't understand what "sections within writing" means. Does "sections within writing" mean the same thing as "section" in Glossary? Proposed Change: Need clarification. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0028.html "report progress" for whom? In Note 1, it reads "Although conformance can only be achieved at the stated levels, authors are encouraged to satisfy and report progress toward meeting success criteria from all levels beyond the achieved level of conformance." What did you want to say by "report progress"? Proposed Change: Hard to translation. Need clarification. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0029.html In "Optional components of a conformance claim" section, it reads "This information should be provided in a form that consumers can use, preferably machine-readable metadata." Who is "consumers"? Does it mean "end users of the web site/web appication"? If so, why "consumers" instead of "users"? Proposed Change: Need explanation. http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0030.html We found that several words don't have links to the same words in Glossary though they are defined in Glossary. For the same word, some are linked and the others are not linked. Is this an editorial mistakes? Or the words which don't link to Glossary are used in different meaning? Proposed Change: Add link to Glosarry to all if they are editorial mistakes. | accessibility supported/accessibility-supported
There are both "accessibility supported" and "accessibility-supported" in WCAG 2.0 CR. Are they intentional or editorial mistakes? Proposed Change: Need consistency through the document if they are editorial mistakes. RESPONSE: They are both correct. In English if you have two words that modify a third, the two words should be hyphenated. Thus ‘accessibility-supported technology’ should be hyphenated but ‘the technology is accessibility supported’ would not. ------------------------- What is "symbols"? We need clarification on what "symbols" means. Does it mean graphic symbols for people with developmental disorders and speech comprehension difficulties? Or does it imply more than it? Proposed Change: Hard to translate. Add the explanation to the Glossary. RESPONSE: Symbols could apply to ‘anything that represents something else’ See http://en.wikipedia.org/wiki/Symbol . It is not limited to graphic symbols for people with developmental disorders and speech comprehension difficulties. ------------------------- What is "action"? What do you want to say by "indicating an action"? Some concrete examples would be helpful for us to translate the phrase. Proposed Change: Hard to translate. Provide examples. RESPONSE: This means “indicating that something will happen or has already happened”. For example, using color to indicate that a link will open in a new window or that a database entry been updated successfully. “Prompting a response” refers to a use of color that would indicate that the user should do something. For example, a Web page could use highlighting on form fields to indicate that a required field had been left blank. ------------------------- mechanism The term "mechanism" is defined in the Appendix A: Glossary. Is it used in unusual meaning? Proposed Change: Just to clarify. We need your help in order to find the appropriate word in Japanese. RESPONSE: It is defined because there are many definitions for mechanism and we are using it in a restricted (but not unusual) way. ------------------------- What is "glyph"? For Japanese, it can be translated in several ways. We need to make sure what it indicates. Could you provide us with the visual examples (not in text)? It will allow us to find an appropriate word in Japanese. RESPONSE: The characters in hiragana and katakana are glyphs. Kanji are also glyphs. As are the representations of characters in the Western Alphabet See http://en.wikipedia.org/wiki/Glyphs ------------------------- What is "line spacing" / "leading"? We couldn't understand both "line spacing" and "leading". Could you explain both by using visual examples? There are multiple interpretation in Japan and both are confusing. For "line spacing" / "leading", We guess there would be differences among languages. Proposed Change: Need visual explanation on what "line spacing" is and what "leading" is. We'll be able to translate them if we see both. RESPONSE: “Line spacing” is the space from the top of one line to the top of the next line. It is also called “Leading” for historical reasons. It comes from the old days when type was set by hand. Thin sheets of lead (the metal) were inserted between lines to adjust their spacing. So we now call any extra space between lines “leading”. ------------------------- What is "space-and-a-half"? We need more details on "space-and-a-half". It is one of the jargon. We couldn't find an appropriate word in Japanese. Proposed Change: Need explanation. RESPONSE: There is not a word for this in English either. We must use a phrase. Space-and-a-half means that there is 50% more distance from the top of one line and the top of the next line than is normal for that font. (50% more than ‘single-spaced’ text) We have added an illustration of this to the understanding document (http://tinyurl.com/62jzfl). ------------------------- What "path" means We need the clarification what "path" means. Is it applied to pointing device only? Or also keyboard interfaces? Or any other movement? Proposed Change: "path" can be translated to wider range of meaning. Need clarification. RESPONSE: PATH means the “path taken by the users movement”. With pointing devices, the path you take to a button does not change the result if you press the button. However, if you are drawing a freehand line, you get a much different shape depending on the path of your movement. Same for a watercolor painting on your computer. ------------------------- "timing" = "time limit"? The "Note" reads "While exceptions to Success Criterion 2.2.1 where timing is essential exist,". Does "timing" mean "time limit"? Proposed Change: Need explanation. RESPONSE: YES. We have revised the note to read as follows. DONE Note: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1 which puts limits on changes of content or context as a result of user action. ------------------------- more than 5 seconds Does it mean that "5.0 seconds" is not included and "5.01 seconds" is included? Proposed Change: Just to confirm. RESPONSE: YES. "more than 5 sec" = "> 5 sec". One would prefer more than 1/100th of a second but that would indeed satisfy the requirement. ------------------------- What "process" means In Note 3, it reads "Content that is updated from a process, real-time or remote stream". We couldn't understand "a process, real-time or remote stream". Is this mean "process, real time stream or remote stream"? Also we couldn't understand what "process" is in this Note 3. Proposed Change: Very hard to translate. Could you say this in other words? RESPONSE: We have revised the note as follows: "Content that is automatically updated periodically by software, or that is streamed to the user agent…” [is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.] Is this easier to understand? ------------------------- Why "bypass"? We use "skip" for this. We'd like to know why you use "bypass" instead of "skip". What is the difference?? Proposed Change: Need explanation for appropriate translation. RESPONSE: Bypass and Skip mean the same thing. You could use either word in this provision. In English skip has multiple meanings so Bypass was used in our document. It means to “pass by without stopping”. ------------------------- "sections" = "section" in Glossary? In Note 2, it reads "This success criterion covers sections within writing,". We couldn't understand what "sections within writing" means. Does "sections within writing" mean the same thing as "section" in Glossary? Need clarification. RESPONSE: YES. Sections is the plural of ‘section’ and we mean it as defined in the Glossary. ------------------------- "report progress" for whom? In Note 1, it reads "Although conformance can only be achieved at the stated levels, authors are encouraged to satisfy and report progress toward meeting success criteria from all levels beyond the achieved level of conformance." What did you want to say by "report progress"? Proposed Change: Hard to translation. Need clarification. RESPONSE: We mean "include in the conformance claim." We should make this clearer. We will change this to "authors are encouraged to report (in their claim) any progress toward…" ------------------------- why "consumers"? In "Optional components of a conformance claim" section, it reads "This information should be provided in a form that consumers can use, preferably machine-readable metadata." Who is "consumers"? Does it mean "end users of the web site/web application"? If so, why "consumers" instead of "users"? Need explanation. RESPONSE: Good catch. We should be consistent. We only user ‘consumers’ in the one location in the document. We will change it to ‘This information should be provided to users in a usable form, preferably machine-readable metadata’ in the next draft. ------------------------- words in Glossary We found that several words don't have links to the same words in Glossary though they are defined in Glossary. For the same word, some are linked and the others are not linked. Is this an editorial mistakes? Or the words which don't link to Glossary are used in different meaning? Proposed Change: Add link to Glossary to all if they are editorial mistakes. RESPONSE: We provide links from terms as they are used normatively in SC and some other places. We don't duplicate a link in the SC or paragraph/section. We only make it a link the first time it appears. Responses sent 29 Aug 2008: Response to commenter in http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0031.html - through - http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Aug/0047.html |
Issue Created: 02 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0000.html
Component: General
Disposition: PARTIAL/OTHER (No response from reviewer)
| Original Comment | Response from Working Group |
|---|---|
| Are there any inclusions / exclusions in the new guidelines that identify accessibility requirements for geospatial mapping web applications, similar to Google Maps? The Government Agency I work for, Geoscience Australia, produces many applications of this type and I would like to know what effect we will have if we adopt these guidelines. An example of a particular mapping application we host can be viewed at http://webmap.ga.gov.au/imf-natural_hazards/imf.jsp?site=natural_hazards_earthquake | There are no exclusions for complex non-text content such as geospatial maps. However, if your example is typical, the "Recent Earthquakes" link provides a long description of the information provided by the map. In addition, your example provides an alternate version of the data used to generate the map via the search feature. The map could contain a short description that indicates what kind of data it contains and tells the user where to find the longer description. See Situation B in Understanding Success Criterion 1.1.1 for similar techniques.
Response sent 03 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0002.html |
Issue Created: 02 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0001.html
Component: 1.4.3 (Contrast (Minimum))
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Are "Large Print" used in SC 1.4.3 and 1.4.6 different from "large print" used in GL 1.1? If so, the same wording is confusing. Proposed Change: Change "Large Print" used in SC 1.4.3 and 1.4.6 to "Large Text". | Since this appears to be causing translation difficulties, we have changed the handles on SC 1.4.3 and 1.4.6 to "Large Text".
Response sent 03 OCt 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0004.html |
Issue Created: 02 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0002.html
Component: 1.4.6 (Contrast (Enhanced))
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| In the section of "Incidental", it reads "..., have no minimum contrast requirement". It should be "enhanced" instead of "minimum" as this is the SC for "Contrast (Enhanced)". Proposed Change: Change "..., have no minimum contrast requirement" to "..., have no enhanced contrast requirement". | "Minimum" is correct in these parts of SC 1.4.6. Just as with SC 1.4.3, there is no minimum contrast requirement for text that occurs in the situations described by the Incidental and Logotypes clauses. So that text may have very poor contrast and still satisfy the success criterion.
We have revised the second bullet of 1.4.3 and 1.4.6 as follows to clarify this: Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement. Response sent 03 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0005.html |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0011.html
Component: Appendix A: Glossary
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| We thought that "dialog" means "a conversation between two or more persons" in general. For caption, it is not limited to the conversation. Proposed Change: For example, change "dialog" to "speech/dialog". | We have revised the definition of "captions" as follows:
captions synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content Response sent 03 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0006.html |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0012.html
Component: Appendix A: Glossary
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| It is difficult for us to interpret Note 5. Did Note 5 want to say that the conforming alternative version may be located on the other website which is outside of the scope of conformance? Proposed Change: Need clarification for translation. | Your interpretation of this note is correct. If, for example, you included a high resolution photograph of a handwritten historical document on a page on your site and you referenced a conforming alternate version located on another site that included an HTML version of the document you had photographed, you would still be able to claim conformance for the original page.
We have modified the note as follows: Note 5: The conforming alternative version does not need to reside within the scope of conformance<add>, or even on the same Web site,</add> as long as it is as freely available as the non-conforming version. Response sent 03 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0007.html |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0013.html
Component: Appendix A: Glossary
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Why did you use "virtual magnifying glasses" instead of "magnifying software" or "screen magnifier"? Proposed Change: Just to confirm the intent. | This language comes from the definition of viewport used in the User Agent Accessibility Guidelines (http://www.w3.org/TR/WAI-USERAGENT/glossary.html).
It is meant to describe a type of magnification software that allows users to enlarge portions of the screen in a manner very similar to the way users might use a hand held magnifying glass. Response sent 03 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0008.html |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0014.html
Component: Appendix A: Glossary
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| In "Web page" section, both "URI" and "URL" are used. Proposed Change: If there isn't any difference between "URI" and "URL", use "URI" in order to be consistent through the document. | We have updated the documents to use "URI" as proposed.
Response sent 23 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0037.html |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0015.html
Component: Appendix A: Glossary
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| What is "common pixel sizes available today"? 1024 x 768? Proposed Change: We need more concrete premise for the users display. | Since the note relates to the definition of large scale text, we have removed this sentence "This success criterion is based on common pixel sizes available today." Additional detail about why 14 point bold and 18 point were chosen can be found in the understanding 1.4.3 and 1.4.6 documents.
Response sent 24 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0042.html |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0016.html
Component: Appendix A: Glossary
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| In "large scale (text)", it reads "... font size that would yield equivalent stroke width for Chinese, Japanese and Korean (CJK) fonts". For Japanese, the stroke width differs according to the font face, also between Kanji and Hiragana/Katakana. And the stroke width is not proportional to the font size. Proposed Change: We can't determine the large scale text for Japanese characters with this definition. Please tell us how to find appropriate font size for Japanese. To be testable, we have to present the font sizes like "18 point or 14 point bold" for Japanese authors. | We determined the font sizes for this provision by using the standard font sizes for large print in the United States.
We suggest that the font sizes for CJK languages be derived in the same fashion. If you have a suggestion for a specific font size that would be suitable for large print in CJK languages, we would welcome any input you might have. We have added the following note to the definition: NOTE 5: The 18 and 14 point sizes for roman texts are taken from the minimum size for large print (14pt) and the larger standard font size (18pt). For other fonts such as CJK languages the "equivalent" sizes would the the minimum large print size used for those languages and the next larger standard large print size. Response sent 23 Oct 2008. |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0017.html
Component: 1.1.1 (Non-text Content)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| "must be presented in non-text format" which is defined in Glossary can be changed to "would be invalid if presented in text" as defined in Grossary. The phrase is used just one time. Proposed Change: Just replace "must be presented in non-text format" with "would be invalid if presented in text" and remove "must be presented in non-text format" from Glossary. | We have updated the draft as proposed.
Response sent 06 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0010.html |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0018.html
Component: 1.4.8 (Visual Presentation)
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| "on a full-screen window" is used just one time. Proposed Change: Change "on a full-screen window" to "on the most common sized desktop/laptop display with the viewport maximized" as defined in Glossary and remove "on a full-screen window" from Glossary. | We have moved an important note from the understanding doc to the definition so it no longer works to move the definition up to the success criterion.
Response sent 06 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0011.html |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0019.html
Component: Appendix A: Glossary
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| It reads "series of user actions where each action is required in order to complete an activity". Can we remove "where action is required" and say "series of user actions in order to complete an activity"? Proposed Change: If it would change the meaning, just keep it as it is. | Removing this phrase would change the meaning of the term. This is because it specifies that "each action" is required in order to complete an activity. For example, a process would require that a user complete each of the following actions:
1. add an item to their shopping cart 2. provide a shipping address 3. provide payment information 4. review and submit their order Response sent 06 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0012.html |
Issue Created: 16 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0020.html
Component: 1.4.8 (Visual Presentation)
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| In English, does glyph include %, $, &, @, # and so on? For "33%" as an example, "33" is character and "%" is glyph? Proposed Change: Just to confirm the answers from WCAG WG. | The differences between these terms can be somewhat confusing. Perhaps the following definitions (from wikipedia) will help.
- a grapheme is the fundamental unit in written language. Graphemes include alphabetic letters, Chinese characters, numerals, punctuation marks, and all the individual symbols of any of the world's writing systems. - a character is a unit of information that roughly corresponds to a grapheme - a glyph is the shape given in a particular typeface to a specific grapheme or symbol Another useful resource that may help in understanding this topic is: FAQ: Character encodings for beginners: http://www.w3.org/International/questions/qa-what-is-encoding In your example, all of the items mentioned (%, $, &, @, #, 33%) would be both characters and glyphs because the association between their shape and the information the shapes represent are intact. If however, you were to create a font where the character mapping for the letter "b" was associated with a glyph that was a picture of a fish, then you would have something that is a glyph, but not a character. Another resource that may be helpful is http://ja.wikipedia.org/wiki/%E5%AD%97%E4%BD%93 Response sent 06 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0012.html |
Issue Created: 17 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/implementation_experience?implementation_id=25
Component: General
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Will this technique include a specific sub-technique relating to underlining text links? | Yes, this technique has been drafted and includes information related to underlining text links.
Refer to http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/G182.html for the new technique. Response sent to implementor 06 Oct 2008. |
Issue Created: 17 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/implementation_experience?implementation_id=25
Component: General
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Testing with different tools provide widely varying results. E.g. Juicy Studio Readability Flesch-Kincaid Test reads the entire web page including navigation, not just content. It can also give a very different result to the Microsift Word Flesch-Kincaid Test tool. These tools need to be checked to ensure they are accurate. | While the working group has attempted to provide helpful Related Resources, no endorsement is implied, and we cannot take responsibility for the design of the tools. The working group commends any reading experts who are willing to test the tools and provide feedback to the authors to improve them.
Based on implementation experience, we have also changed the Success Criterion to require that the text meet the reading levels AFTER removal of proper names and titles. This may require yet more adjustments to how to use the existing tools. Response sent to commenter 23 Oct 2008. |
Issue Created: 17 Sep 2008
Source: (Original comment not archived)
Component: 3.3.1 (Error Identification)
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| General Note: Success Criterion 3.3.1 states: "If an error is automatically detected, the item that is in error is identified and the error is described to the user in text" The Success Criterion seems to imply that if errors are not automatically detected then the Success Criterion is not relevant. However, the technique G83: "Providing text descriptions to identify required fields that were not completed" seems to state that errors must be detected: 1. Fill out a form, deliberately leaving one or more required (mandatory) fields blank, and submit it. 2. Check that a text description is provided identifying the mandatory field(s) that was not completed. Is it a breach of this Success Criterion if errors are not automatically detected? G83 Technique also contains an example which does not work for screen reader users: "A user is completing a form that contains mandatory fields. The labels of the fields indicate whether or not they are mandatory. The user tabs to a mandatory field, and tabs out of the field without entering any data or selecting a choice. A client-side script modifies the label of the field to indicate that leaving it blank was an error". Many screen readers would not pick up the change in the DOM which is done by the scripting. Even if the screen readers copy of the page is updated when the label is updated (reflecting the change in the DOM), the user might not tab back to that control to have the label announced. The two other examples mentioned in the technique works very well for screen reader users. So including the above example in the technique could potentially mean that it is implemented instead of a technique that works for screen reader users. | If errors are not automatically detected, SC 3.3.1 is not relevant. The success criterion ensures that when errors are reported they are reported in a way that makes it easier for users to understand what field was in error and why.
If the error is not automatically detected then none of the users are notified of the error and people with disabilities are at no special disadvantage. We have added an explanation to the third example in G83 that screen reader users may not be aware of the error: Note: Some screen readers may not notice and announce the change to the label so screen reader users may be unaware of the error. Response sent 06 Oct 2008. |
Issue Created: 17 Sep 2008
Source: (Original comment not archived)
Component: 3.3.6 (Error Prevention (All))
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| General Note: This SC seems to apply to all forms, by including the word "all": "3.6.6 Error Prevention (All): For Web pages that require the user to submit information ..." However, when reading the "Understanding" section and the techniques it seems that this success criteria only applies when potentially serious mistakes can be made (for example purchasing goods, or submitting private information). This success criterion is on level AAA and would therefore be expected to apply to "all" situations where form information is submitted, for example search functions (spell checking should be provided) and users submitting feedback regarding web site design and functionality (feedback checked for omitted fields). | We agree. We have removed the phrase " that could result in serious consequences" from intent if 3.3.6 and from the benefits section. Also, the techniques you have suggested are addressed in other success criteria such as 3.3.5 and 3.3.1.
Response sent 23 Oct 2008. |
Issue Created: 17 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/implementation_experience?implementation_id=25
Component: HTML/XHTML Techniques
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| General Note: The two techniques for Success Criterion 3.2.4 - Consistent Identification do not seem related to the success criterion. The two techniques are: H44: Using label elements to associate text labels with form controls (HTML) H65: Using the title attribute to identify form controls when the label element cannot be used These techniques deal purely with correct labeling on individual pages while the success criterion is about consistent labeling across many pages. The techniques seem to imply, for example, that if a search function at the top of all pages have different label text on different pages, it still passes if the labels are correctly marked-up (associated) on the individual pages. This goes against the Success Criterion. | We have revised the sufficient techniques section of Understanding Success Criterion 3.2.4 to clarify that the sufficient techniques from Success Criterion 1.1.1 and Success Criterion 4.1.2 should be used to provide labels, names and text alternatives. SC 3.2.4 requires that they be used consistently.
Response to implementor sent 06 Oct 2008. |
Issue Created: 17 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/implementation_experience?implementation_id=25
Component: HTML/XHTML Techniques
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Technique: "H33: Supplementing link text with the title attribute" creates accessibility issues: it encourages the use of an attribute that is not widely announced by screen readers and never will be. Screen reader users have more than enough information to process when listening to a page, and expecting them to listen to the title of links just in case the title includes extra information is unreasonable. Why includes this technique when there are perfectly good alternatives, for example including information in the link text or off-screen?. | The User Agent and Assistive Technology Notes for H33 are extensive, documenting the limitations of this technique and the obstacles it can pose for users. This technique is only sufficient when the title is providing supplemental information to the link text.
We have added the following paragraph to the description of 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. Response sent to implementor 23 Oct 2008. |
Issue Created: 17 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/implementation_experience?implementation_id=25
Component: HTML/XHTML Techniques
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| General Note: The following example from technique H30: "Providing link text that describes the purpose of a link for anchor elements" encourages wordy links (not many web pages have link phrases like "go to the home page"): Example 4 A link contains an icon and text, and the site help refers to the icon. The img has a text alternative which is the name used for the icon in the site help, which describes clicking the home page icon. <a href="foo.htm"> <img src="house.gif" alt="home page icon"/> Go to the home page </a> Suggestion: Example 4 A link contains text and an icon, and the site help refers to the icon. The img has a text alternative which is the name used for the icon in the site help. <a href="foo.htm"> Woodend Music Festival Program <img src="pdficon.gif" alt="PDF format"/> </a> | Thanks for noticing this. We tightened up the text in our example and added your proposed example as well.
Response sent to implementor 06 Oct 2008. |
Issue Created: 17 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/implementation_experience?implementation_id=25
Component: General
Disposition: NOT ACCEPTED (No response from reviewer)
| Original Comment | Response from Working Group |
|---|---|
| General WCAG 2.0 Issue: Inconsistent labeling causing confusion. Items 1.2.2 to 1.2.8 indicate what needs to be provided to make content accessible which is inconsistent to labelling of other Success Criteria. Make wording consistent. It is better if all success criterion start with a phrase indicating content. This is because web designers checking pages for potential accessibility issues need to keep the relevant content in mind rather than what needs to be provided to make content accessible. | We agree with you but these provisions are a special case. There are some tricky issues with these and we tried many different forms for these SC before we could find one that worked. These are worded in this fashion because they must be in order to be accurate for the full range of media that they would apply to.
Response to implementor 23 Oct 2008. |
Issue Created: 18 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0022.html
Component: General
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Refer to Testing procedure for G65 (bread crumb nav) 5. For a breadcrumb trail that does include the current location: 1. Check that all elements except for the current location are implemented as links. 2. Check that the current location is not implemented as a link. Comment: Item#2 above is redundant and may be omitted. Already covered in item#1. | Since Item #1 explicitly excludes the current location, Item #2 is not covered by it. The requirement for the current location in the breadcrumb trail is different from the requirements for the other elements.
Response sent 06 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0014.html |
Issue Created: 18 Sep 2008
Source: (Original comment not archived)
Component: 1.4.3 (Contrast (Minimum))
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Why not putting G156 as possible sufficient technique. When all background and foreground colors are managed through CSS, if the contrast is not sufficient for a user, he can disable styles ou use his own stylesheets. | Because G156 does not address the contrast ratio of the background and foreground colors, it would not be sufficient to meet the requirements for 1.4.3. Also, few users know how to create or use custom CSS or turn it off. However, since using it could make it easier for a user to adjust their user agents so in order to improve the contrast ratio, we have listed it as an advisory technique for both 1.4.3 and 1.4.6.
Response sent to implementer 06 Oct 2008. |
Issue Created: 18 Sep 2008
Source: (Original comment not archived)
Component: 1.4.3 (Contrast (Minimum))
Disposition: NOT ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Additionally conditioning the target ratio to the font size is much complicated... I use mainly "em" or named font size... what does it gives in "points" ??? I suggest to stay with ISO standard 3:1 for 1.4.3 and 5:1 for 1.4.6 and not taking into consideration this size stuff... | The ISO standard is for people with normal vision. These guidelines are designed to provide enough contrast to accommodate people with low vision including those with colorblindness.
We could use 5:1 and 7:1 without a lesser value for larger print but this is more restrictive than necessary. However, if an author desires to make it simpler for themselves they could just use 5:1 and 7:1 and avoid considering font size. Note that based on implementation feedback, we have changed the ratio for SC 1.4.3 from 5:1 to 4.5:1. For people with vision impairments, 4.5:1 is equivalent to ISO's 3:1 for people with normal vision. Response to commenter sent 23 Oct 2008. |
Issue Created: 18 Sep 2008
Source: (Original comment not archived)
Component: General
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| SC 1.2.5 Audio Descriptions: Isn't this already covered under 1.2.3? I don't understand why it's separated how here, and in 1.2.8. SC 1.2.8: Full Text Alternative: Isn't this already covered under 1.2.3? I don't understand why it's separated how here, and in 1.2.8. SC 1.4.9: Images of Text (No Exception) : Seems redundant with 1.4.5. SC 2.4.9: Link Purpose (Link Only): Seems redundant with 2.4.4. SC 2.4.10: Section Headings : This seems too similar to 1.3.1 to be so disconnected. | WCAG 2.0 contains progressive requirements for some types of content, that is, the requirements at Level AA are more rigorous than the requirements at Level A and similarly for Level AAA and Level AA.
So SC 1.2.3 at Level A requires either Audio Descriptions or Full Text Alternatives. At Level AA, SC 1.2.5 requires Audio Descriptions and Level AAA SC 1.2.8 requires Full Text Alternatives. To conform at Level AAA, both Audio Descriptions (possibly Extended) and Full Text Alternatives are required. However, at Level AA, it is possible to conform with only Audio Descriptions provided and at Level A, it is possible to conform with only Full Text Alternatives. SC 1.4.5 (Images of Text), at Level AA, is very similar to SC 1.4.9 (Images of Text (No Exception) at Level AAA except a Level AA an exception is permitted if the technology used cannot achieve the visual presentation of the text. At Level AAA, this exception is removed. When content satisfies SC 2.4.4 Link Purpose (In Context) at Level A the user may need to consults programmatically determined link context to determine the purpose of the link. At Level AAA, SC 2.4.9 (Link Purpose (Link Only)) requires that the link context depend only on the link text itself not on the context. With respect the headings, SC 1.3.1 (Info and Relationships) requires that if headings are used they are marked up in a way that assistive technology can recognize them as headings. But it does not require that headings be used. SC 2.4.10 (Section Headings) requires that headings be present. Response sent to implementer, 06 Oct 2008. |
Issue Created: 18 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=39
Component: 1.4.3 (Contrast (Minimum))
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| The screenshots of the Windows Character Map contain text but are not really images of text. However, the text in the screenshots is not incidental either. How does SC 1.4.3 apply to these screenshots? http://canada.esat.kuleuven.be/user/error404/chinese/WindowsCharacterMap.html | The provision has "that are part of a picture that contains significant other visual content," as an exception. This exception is intended to separate pictures that have text in them from images of text that are done to replace text (in order to get a particular look).
So these images would not be "images of text" and are not covered by 1.4.3. To make this clearer we are adding the following to the Understanding doc. In this provision there is an exception that reads "that are part of a picture that contains significant other visual content,". This exception is intended to separate pictures that have text in them from images of text that are done to replace text in order to get a particular look. Response to commenter 23 Oct 2008. |
Issue Created: 18 Sep 2008
Source: (Original comment not archived)
Component: 3.3.6 (Error Prevention (All))
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| In addition to error feedback, success feedback is also provided to inform users that an operation completed successfully, removing the need to manually confirm whether an action was successful or not. Success feedback is not included as a criteria in WCAG2. It probably should be. Without it AT users are often required to expend significant effort to confirm that an action just completed was successful | We agree that success feedback is often helpful to users. We have added an advisory technique to SC 3.3.1, 3.3.3, and 3.3.4 and would welcome any help you can provide in drafting it.
We have added an advisory technique titled, "Providing success feedback when data is submitted successfully." Response sent to implementor 06 Oct 2008. |
Issue Created: 19 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0024.html
Component: HTML/XHTML Techniques
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| H44 (using labels for form controls) deals only with explicit association and does not refer to "consistency". Yet the "Applicability" section refers to 3.2.4 (Consistent Identification). The eval techniques for 3.2.4 also lists H44 as a sufficient technique. I think this is not appropriate and the cross references should be deleted. Also note: H65 (using title attribute for form controls) does not refer to 3.2.4. | We have revised the sufficient techniques section of Understanding Success Criterion 3.2.4 to clarify that the sufficient techniques from Success Criterion 1.1.1 and Success Criterion 4.1.2 should be used to provide labels, names and text alternatives. SC 3.2.4 requires that they be used consistently.
Response sent 06 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0015.html |
Issue Created: 20 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=47
Component: 1.1.1 (Non-text Content)
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| There are two notable failures to which there were not Failure options provided. 1) Failure due to images that convey content, but do not have appropriate alternative text (either in alt attribute or context), and 2) Failure for linked image (image is only element within the link) missing alt text or alt attribute. | Regarding:
"1) Failure due to images that convey content, but do not have appropriate alternative text (either in alt attribute or context)" Although we do require that text alternatives serve the equivalent purpose of the non-text content, we do not feel it is possible to create a testable failure that would identify when text alternatives are not appropriate. We do, however, have a failure for using placeholders in alt text. Regarding: "2) Failure for linked image (image is only element within the link) missing alt text or alt attribute." You may have linked images in different technologies where alt text is not the proper technique for the text alternative. We have added a failure titled "F89: Failure of 2.4.4, 2.4.9 and 4.1.2 due to using null alt on an image where the image is the only content in a link" (http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/F89.html) Response to commenter 23 Oct 2008. |
Issue Created: 20 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=47
Component: Common Failures
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| If an alternative mechanism is provided to trigger the scripting functionality, this should not be a failure. | We have added "in a way that is not programmatically determinable" so that the failure title reads as follows:
F42: Failure of Success Criterion 1.3.1 and 2.1.1 due to using scripting events to emulate links in a way that is not programmatically determinable. As with any content that does not meet the requirements, it is possible to conform by providing a conforming alternate version (Refer to Understanding conforming alternate versions). However, even if an alternate mechanism is provided in a way that makes the page as a whole conform, the specific sections of code that include the problems illustrated in F42 would still fail the requirements of the success criterion. Response to commenter 23 Oct 2008. |
Issue Created: 20 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=47
Component: 2.1.1 (Keyboard)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| There should be a failure for elements that should allow keyboard focus, but do not (either through scripting, tabindex, etc.). On this site there are some checkboxes that are removed from the tab order. I marked this as a F55 failure as the failure is evidenced from the test even though it doesn't directly fit into F55's scope (focus is set, then lost). | We agree that this describes a failure of the success criterion because the content would not be keyboard operable. However, we do not have the resources to draft the failure at this point in time. If you are interested in drafting such a failure, we would welcome your input. You can use the techniques submission form (http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/) to submit draft techniques.
Response to commenter 23 Oct 2008. |
Issue Created: 22 Sep 2008
Source: http://lists.w3.org/Archives/Public/w3c-wai-gl/2008JulSep/0092.html
Component: Common Failures
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| I have a question/comment about F78: Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that overrides or renders non-visible the default visual focus indicator. The failure as it is written seems to mean that the browser default focus cannot be overwritten or turned off. Does assistive technology use the browsers default focus indicator to indicate focus to a user? If so, then I understand that it probably shouldn't be turned off entirely, but I'm having trouble understanding why the default focus indicator can't be rendered non-visible, as long as it is replaced by something more visible. In my opinion, in most browsers, including both IE 7 and Firefox 2, the default focus indicator is so hard to see that overriding it almost seems necessary in order to make the focus indicator really visible. It is especially hard to see when a form element, such as a checkbox, has focus. This Failure also seems to be in contradiction with 2.4.7 Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA). Reading 2.4.7, it seems that is OK to override the default focus border as long as focus IS visible. We also allow an "author supplied, highly visible focus indicator" and C15 allows the use of CSS to change the presentation of a UI component when it receives focus. For example, changing the background color of a focused menu item still makes focus visible even if there is no dotted border. Does F78 mean that all of the sufficient techniques in 2.4.7 will fail? Perhaps F78 should just say that shouldn't entirely disable the focus indicator? | Thanks for catching this. We agree that the failure was written too narrowly. We have updated it so that the failure only occurs if there is no visible focus indicator.
Response sent 06 Oct 2008: http://lists.w3.org/Archives/Public/w3c-wai-gl/2008OctDec/0009.html |
Issue Created: 22 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=15
Component: 1.2.7 (Audio Description (Extended))
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| > There are many instances where important visual information > was left out of the Descriptions because there was not time. > At AAA, Extended Audio Description would pause the > video for a short audio description rather than rushing or > leaving out important information. > # I respectfully disagree. The note under "extended audio description" in the WCAG 2.0 Glossary says "This technique is only used when the sense of the video would be lost without the additional audio description and the pauses between dialog/narration are too short." The subjective judgement here is whether the "sense of the video would be lost". Audio description on all of our videos was provided by highly credible audio description vendors (WGBH, Narrative TV, and Vitac), and we had an opportunity to review their audio description scripts prior to recording to ensure that users would indeed have full access to the "sense" of the video. Since both the vendor and DO-IT have signed off on the audio description content for each video, I believe that we have met this success criterion. If you stand by your disagreement, I would be interested in knowing specific details about where you feel our audio description is inadequate. This would be important feedback for our vendors, since their failure to meet the success criteria will impact large numbers of their clients' videos as well. | We have revised Success Criterion 1.2.7 as follows:
1.2.7 Audio Description (Extended): Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media. (Level AAA) Quality of text alternatives is subjective, so we do not specify the quality of text alternatives, captions or descriptions. As long as the alternatives are not mere placeholders, the Success Criterion would be met. Therefore, these examples would meet the success criterion, though we would prefer that additional information such as speaker identification and other important information that had been provided in text visually be included. Response to commenter 23 Oct 2008. |
Issue Created: 22 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=15
Component: 1.2.6 (Sign Language)
Disposition: PARTIAL/OTHER (Reviewer Disagrees)
| Original Comment | Response from Working Group |
|---|---|
| This success critereon raises many questions, and currently there is too little support provided in WCAG 2.0 for us to know exactly how to proceed. We can add a sign language interpreter to our videos via SMIL but as far as we could find there's little or no research or precedent for optimum positioning and size of the interpreter, relative to the main video. The "Related Resources" section under "Understanding SC 1.2.6" includes a link to "NCAM Rich Media Accessibility, Accessible SMIL Templates", but none of the templates on this page include a region for sign language. Also, this success critereon says nothing about which language is most appropriate. If we use American Sign Language (ASL), we're still inaccessible to users who only know Signed English or British Sign Language. Conversely, Shawn Henry referred me to http://www.creaturediscomforts.org/ as an example. Although the primary language of this site is English, none of my American deaf colleagues could understand the sign language interpreter. I'm guessing it's British Sign Language? Is this really an issue of internationalization, rather than accessibility? | In the Related Resources for SC 1.2.6,
http://www.sign-lang.uni-hamburg.de/SigningBooks/SBRC/Grid/d71/guide12.htm has advice on filming sign language interpreters. The complete report on the Signing Book project starts at http://www.sign-lang.uni-hamburg.de/SigningBooks/SBRC/Grid/d71/guide00.htm http://tinyurl.com/6zqgqh is another example of a video that uses a different style to add the sign language video. That sign language and oral language do not map 1-to-1 is an unfortunate complication. In this circumstance, using any of the sign languages that correspond to the oral language will satisfy the success criterion. It does not require providing all of them. It is recommended, of course, to use the sign language of the target culture or country. Response sent to commenter 23 Oct 2008. |
Issue Created: 22 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=15
Component: 1.4.7 (Low or No Background Audio)
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| As noted in my comments related to 1.2.7, all our audio description was produced by one of three highly credible vendors. The lack of conformance here raises a couple of important questions for me: First, if audio description is mixed into the program audio, how can the difference between audio description foreground and background be measured? That would seem to require very high end audio tools, if it's even possible. Measuring the difference by determining whether the foreground is "approximately four times louder" is still extremely subjective, and I doubt that many people have audio perception that is accute enough to reliably measure that. Second, assuming our foreground/background really does differ by less than 20dB, our failure to conform suggests that much of the audio description produced by these same leading vendors probably does not meet this success criterion. How was 20db determined as a threshhold? Might it be to strict? | First, if audio description is mixed into the program audio, how can the
difference between audio description foreground and background be measured? - The RMS volume can be measured in the gaps before or after or in pauses during the description and compared to the RMS volume of the description. That would seem to require very high end audio tools, if it's even possible. Measuring the difference by determining whether the foreground is "approximately four times louder" is still extremely subjective, and I doubt that many people have audio perception that is acute enough to reliably measure that. - We acknowledge that it can be difficult to evaluate foreground and background today. However, a tool (similar to the tools available for evaluating text contrast) is in development that should make it much easier to evaluate this requirement. Second, assuming our foreground/background really does differ by less than 20 dB, our failure to conform suggests that much of the audio description produced by these same leading vendors probably does not meet this success criterion. How was 20 dB determined as a threshold? Might it be to strict? - The 20 dB is a common measure for signal background separation. The understanding document (intent section) cites two sources and memebers of our working group have confirmed these findings with various experts in the field. We have also added the following note to SC 1.4.7: Note: Given that in normal speech, hearing people loose the occasional word, it is acceptable to have occasional dips of contrast between 10dbs-20 dbs for up to 2 words in a sentence that are isolated and not nouns or verbs. Response sent to commenter 23 Oct 2008. |
Issue Created: 22 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=15
Component: 1.4.8 (Visual Presentation)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| The Techniques for 1.4.8 (Fourth Requirement) include examples for setting line spacing to space-and-a-half within paragraphs (e.g., p { line-height: 150%; } ). However, this would seem to address only the first portion of this requirement. How does one also ensure that "paragraph spacing is at least 1.5 times larger than the line spacing?" My confusion comes partially from the use of line-height in the first example. Is line-height synonymous with "line spacing"? My brain views this requirement in two ways. Is either of these accurate? a) If I have font-size:1em, and line-height:1.5em, I believe that line spacing is the amount of space not occupied by text (0.5em), in which case the paragraph should have margin-bottom:1.5em (line spacing x 1.5). b) "Line spacing" actually refers to line-height. So if I have line-height:1.5em, then my paragraph should have 1.5x that for a bottom margin (or padding), e.g., margin-bottom:2.25em. Since I have to ask the above question, I think more explanation, including additional examples, should be included in the Techniques for this success criterion. | Your first proposal (a) is the correct one.
You are also correct that there should be more information in the Understanding doc. Additional information has been added therefore to the Understanding document. Paragraph 4 now reads People with some cognitive disabilities find it difficult to track text where the lines are close together. Providing extra space between lines and paragraphs allows them to better track the next line and to recognize when they have reached the end of a paragraph. It is best if there are several different options, for instance, space-and-a-half and double spacing for line spacing. By space and a half within paragraphs we mean that top of one line is 150% further from the top of the line below it than would be true when the text is 'single spaced' (the default spacing for the font). By Paragraph spacing that is 1.5 times larger than the line spacing we mean that the spacing from the top of the last line of 1 paragraph is 250% farther from the Top of the first line of the next paragraph (I.e. that there is a blank line between the two paragraphs that is 150% of the single space blank line). Response sent to commenter 24 Oct 2008. |
Issue Created: 22 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=15
Component: 3.1.5 (Reading Level)
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| I somewhat randomly selected a few transcript pages from our site, as well as the home page and FAQ page, and ran them through the Juicy Studio Readability Test. Results: DO-IT Video Search Home Page Gunning Fog Index 15.56 Flesch Reading Ease 35.14 Flesch-Kincaid Grade 11.84 FAQ Page Gunning Fog Index 12.30 Flesch Reading Ease 52.60 Flesch-Kincaid Grade 9.49 Transcript Page: Access to Technology in the Workplace: In Our Own Words Gunning Fog Index 9.30 Flesch Reading Ease 67.66 Flesch-Kincaid Grade 5.70 Transcript Page: Equal Access: Student Services Gunning Fog Index 10.06 Flesch Reading Ease 63.01 Flesch-Kincaid Grade 6.48 Transcript Page: How DO-IT Does It Gunning Fog Index 7.73 Flesch Reading Ease 72.28 Flesch-Kincaid Grade 5.06 Transcript Page: Invisible Disabilities and Postsecondary Education Gunning Fog Index 9.85 Flesch Reading Ease 65.77 Flesch-Kincaid Grade 6.09 The primary content of our site is that contained within the videos, and as the ratings on the transcript pages indicate, this content meets the success criterion. Between now and October 13, I will edit the FAQ page with improved readability in mind, and hopefully can attain a more readable FAQ without creating a separate version. The home page is trickier. The ratings on this page are higher because it is comprised almost exclusively of video titles and their official descriptions, and these titles and descriptions include words with more syllables, such as "disabilities", "postsecondary education", and "accessible". Even if we could think of suitable alternative words to use in our descriptions, I think we would still have Gunning Fog Indexes and Flesch-Kincaid Grades higher than 9 because of the titles, and we can't change this content. Given that our transcripts (and therefore our video content) already meets this success criterion, and if we address the readability of the FAQ, would that be sufficient for claiming that our site meets AAA conformance to this success criterion? | We have discovered that the length of proper names, titles and other things that cannot be changed can affect the reading level scores such that it is not possible to meet the reading levels. For example, America or Argentina or Pellegrino push the indexes up but there is no way to make them shorter or simpler and over-use of "it" or "them" can make sentences ambiguous rather than simpler.
We are therefore changing the SC to require that the text meet the reading levels AFTER removal of proper names and titles (which would include book titles). Response sent to implementor 06 Oct 2008. |
Issue Created: 23 Sep 2008
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Sep/0026.html
Component: Translations
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| During the process of translating the WCAG 2.0, we encountered a few wording problems. Shadi asked me to hand them in. label: We don't have a word in German that completely equals the meaning of label, so we'll use the English term. programmatically determined: Our question is, whether this term is meant as an active or a passive roll. Video-only: In German, we don't use the word "Nur-Video" what's the 1:1-translation. Audio-only Same problem as mentioned under video-only. Captions There's no difference between captions and subtitles, so we decided to use the English term. set of Web pages We do need a little more explanation here. Is set of webpages really meant to be webpages which are related only by author or organisation. So if the pages are on different websites, they do still count as set of Web pages? Proposed Change: None, but we do need a little further explanation on a few of our translation problems. | {partial/other}
Response to Commenter: label: We don't have a word in German that completely equals the meaning of label so we'll use the English term. Reply from Working Group: OK ---------------------------- programmatically determined: Our question is whether this term is meant as an active or a passive roll. Reply from Working Group: This is passive in that the information and relationships must be explicitly represented in the data. Whether user agents and assistive technology actively use this information is a question of accessibility support for the technology. ---------------------------- Video-only: In German we don't use the word "Nur-Video" what's the 1:1-translation. Reply from Working Group: Video-only means "Only video content with no audio or interaction". ---------------------------- Audio-only Same problem as mentioned under video-only. Reply from Working Group: Audio-only means "Only audio content with no video or interaction". ---------------------------- Captions There's no difference between captions and subtitles so we decided to use the English term. Reply from Working Group: OK. This seems to be a problem unique to English-speaking cultures. ---------------------------- set of Web pages We do need a little more explanation here. Is set of Web pages really meant to be Web pages which are related only by author or organisation. So if the pages are on different websites they do still count as set of Web pages? Reply from Working Group: They could be on different Web sites or servers but they must have a common purpose. Response sent 06 Oct 2008: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Oct/0016.html |
Issue Created: 27 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=31
Component: 1.1.1 (Non-text Content)
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Concerning the 4 <img> elements non complying with SC 1.1.1: Non-text Content (Level A), these errors are due to a difference between evaluator's interpretation and mine concerning the decorative or informative nature of these images. Considering the context in which they are used, both interpretations seem correct to me. Guidelines and definitions are clear ; even like this, there will still be place for interpretations ; I encounter this regularly when evaluating client's sites. Anyway, I fixed it and the 4 images now conform. | We understand that there are different interpretations of what is decorative. The definition of 'decorative' in WCAG says that you would need to be able to replace the picture with another picture of something else - and that would clearly be a problem on this page.
Thank you for taking care of these. We have also added the following failure to help clarify this issue. F89: Failure of 2.4.4, 2.4.9 and 4.1.2 due to using null alt on an image where the image is the only content in a link Response sent to commenter 23 Oct 2008. |
Issue Created: 29 Sep 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/evaluation_results_site_summary?implementation_id=16
Component: 1.1.1 (Non-text Content)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| Comment from evaluation: SC 1.1.1: Non-text Content See comments about SC 1.1.1 in the evaluation summary. Response from implementor: We've confirmed that every figures you mentioned above are assistive contents for better understanding, and every vital information are described in the text. We mean, for example, "exact organization structure" is not vital in the context. So we believe that we don't have to do anything to meet 1.1.1 about these figures/contents. | There can be information in an image that is not critical to the purpose of the image on the page. This sounds like such a situation. The vital information is available to the user on the page, and the image itself has a text alternative that describes its purpose. We believe this satisfies SC 1.1.1.
Response sent to commenter 23 Oct 2008. |
Issue Created: 29 Sep 2008
Source: (Original comment not archived)
Component: 1.4.7 (Low or No Background Audio)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| I think we have to add the following note to the Success Criterion: Note: Given that in normal speech, hearing people loose the occasional word, it is acceptable to have occasional dips of contrast between 10dbs-20 dbs for up to 2 words in a sentence that are isolated and not nouns or verbs. | We have accepted your suggestion by revising SC 1.4.7 as follows:
1.4.7 Low or No Background Audio: For prerecorded audio-only content that (1) contains primarily speech in the foreground, (2) is not an audio CAPTCHA or audio logo, and (3) is not vocalization intended to be primarily musical expression such as singing or rapping, at least one of the following is true: (Level AAA) How to Meet 1.4.7 Understanding 1.4.7 * No Background: The audio does not contain background sounds. * Turn Off: The background sounds can be turned off. * 20 dB: The background sounds are at least 20 decibels lower than the foreground speech content, with the exception of occasional sounds that last for only one or two seconds. Note: Per the definition of "decibel," background sound that meets this requirement will be approximately four times quieter than the foreground speech content. Response sent 23 Oct 2008. |
Issue Created: 29 Sep 2008
Source: http://www.australia.gov.au/Video_-_National_Apology_to_the_Stolen_Generations
Component: conforming alternate version
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| The main page for the video contains links to pages that provide sign language, audio description, or extended audio description versions of the video. While each alternate page provides an example of meeting the corresponding success criterion, it is not clear that this structure satisfies the Conforming Alternate Version definition, since no one version meets all of the success criteria. Nevertheless, this seems like a useful way to organize the many different copies of the videos (since there are also multiple versions to support the different video formats for different players). | If there is a link to the previous page and the other alternates then "a mechanism exists" to obtain the other forms from any one of the pages and the pages would all pass. (Note: The BACK button is not sufficient by itself since a person could land directly on one of the pages). To make this clearer we have added the following to the procedure for G8, G173, G158, G159, G69, G151:
- If the alternate version(s) are on a separate page, check for the availability of link(s) to allow the user to get to the other versions. Response sent to commenter 23 Oct 2008. |
Issue Created: 29 Sep 2008
Source: http://www.australia.gov.au/Video_-_National_Apology_to_the_Stolen_Generations
Component: 1.2.3 (Audio Description or Full Text Alternative)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| The pages contain an Apology Transcript, which contains the text of the speech, but not speaker identification, description of the room, disclaimers at the beginning and end of the video. Would this qualify as a Full Text Equivalent? | The Transcript is posted to the body of the page. The page as a whole therefore needs to be taken into account. The question is whether the 'content' or 'intent' or 'purpose' of the video is presented in the transcript. The warnings at the beginning and end are not part of the purpose or function of the video - but these are actually contained on the page anyway.
Note that we have replaced the term "full text alternative for synchronized media including any interaction" with "alternative for time-based media." and have adjusted the definition as follows: alternative for time-based media document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction Since the bulk of what is intended to be presented though (the apology itself) is presented on the page, in the text box, and in the other text on the page, we feel that this example passes the requirement. However, there are other visual things that could be added to the description to make it better. A short description of the context would be a good addition. Response sent to commenter 23 Oct 2008. |
Issue Created: 29 Sep 2008
Source: (Original comment not archived)
Component: 2.1.2 (No Keyboard Trap)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| This question came up during a discussion of the sufficient technique for SC 1.3.2, 2.1.1, 2.4.3: Creating Custom Dialogs in a Device Independent Way | We have made the following changes:
2.1.2: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys <ins>or other standard exit methods</ins>, the user is advised of the method for moving focus away. Intent section of Understanding 2.1.2 There may be times when the functionality of the Web page restricts the focus to a subsection of the content, as long as the user knows how to leave that state and "untrap" the focus. Add example to Understanding 2.1.2: A modal dialog box A web application brings up a dialog box. At the bottom of the dialog are two buttons, Cancel and OK. When the dialog has been opened, focus is trapped within the dialog; tabbing from the last control in the dialog takes focus to the first control in the dialog. The dialog is dismissed by activating the Cancel button or the OK button. Response sent to commenter 23 Oct 2008. |
Issue Created: 06 Oct 2008
Source: (Original comment not archived)
Component: 1.4.4 (Resize text)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| It was brought to my attention that a category of containers in which they are designed to fit limited amount of text may be incompatible with guideline 1.4.4. A note may be needed to facilitate its use. We see these sorts of containers nearly every day when doing tab browsing and using the windows taskbar. Note how the tabs in tab browsing handle titles—the tabs truncate long titles. The tab itself is not meant to increase in size to accommodate the text. As more tabs are added, the size the tab must eventually decrease. Windows taskbar behaves much the same way. Since they are not designed to fit long title even at normal text size, 200 percent increase in text size would surely truncate the text on display even more. More complete text is available via tooltips which can generally be resized without being subject to the truncation. Indeed, tab browsing is a user agent issue and windows taskbar is an operating design issue. But the same behavior can be seen in tables—for example subject column in Gmail. Long email subjects are truncated and increased font size would truncate the subject text even more. The question is—does the application of such truncation constitute a loss of content per 1.4.4? On the surface, it seems that there is clearly loss of content if more content is truncated due to increased text size. Demanding a redesign of tab seems to me a fundamental alteration of its very purpose. Such redesign may confuse nearly all users and may acutely disadvantage those with cognitive disorders. To the degree possible, I believe we ought to avoid forcing any change in the tab behavior. I would like to suggest that there is actually no loss of content in the scenario. First, the content is not lost if it is available via tooltip and that the tooltip can be resized. Thus, one may consider the tooltip alternative conformance content. Second, truncating content that are already truncated may not necessarily count as loss of content. The full content is meant to be access via either tooltip or and viewing the content in full (looking at the content within the tab). The text displayed within the container (tab) is merely a truncated representation of the actual content. Thus, the scenario is a reduction of a proxy of the actual content, not a reduction of content itself. My proposed solution is to add a note following the line of argument on one of the two arguments above — either 1.treat tooltip as alternative or 2. Treat container text as only proxy representation of actual content which are available elsewhere. I prefer to apply this proposal as a note to 1.4.4 or understanding doc, not a sufficient technique since it is not really a technique of any kind. It is a special situation in which expected behavior conflicts against display of content. | Thanks. We have added the following paragraph to Understanding SC 1.4.4 to clarify that this type of truncation is not considered losing functionality:
Some user interface components that function as a label and require activation by the user to access content are not wide enough to accomodate the label's content. For example, in Web mail applications the subject column may not wide enough to accomodate every possible subject header, but activating the subject header takes the user to the full message with the full subject header. In Web-based spreadsheets, cell content that is too long to be displayed in a column can be truncated, and the full content of the cell is available to the user when the cell receives focus. The content of a user interface component may also become too wide in user interfaces where the user can resize the column width. In this type of user interface component, line wrapping is not required; truncation is acceptable if the component's full content is available on focus or after user activation and an indication that this information can be accessed, is provided to the user in some way besides the fact that it is truncated. Response sent to commenter 23 Oct 2008. |
Issue Created: 09 Oct 2008
Source: http://www.w3.org/WAI/GL/WCAG20/CR-eval/implementation_experience?implementation_id=39
Component: 1.4.3 (Contrast (Minimum))
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| When I was evaluating if an implementation met the luminosity contrast requirements (SC 1.4.3, SC 1.4.6), I needed to check whether certain spans of text were large print or not. According to the definition, large scale test is "at least 18 point or 14 point bold or font size that would yield equivalent stroke width for Chinese, Japanese and Korean (CJK) fonts". In the implementation I evaluated, font sizes were expressed in em units. Inspection with Firebug gave me computed font sizes in px units. I then looked for a conversion from pixels to point sizes and found the conversion tables at http://sureshjain.wordpress.com/2007/07/06/53/ and http://www.reeddesign.co.uk/test/points-pixels.html. There should be a more practical way to check whether text is large text. Any suggestions? | Using the same reference that you provided
http://www.reeddesign.co.uk/test/points-pixels.html (which puts 12 pt as 1 em) you get 14 pt as 1.2 em and 18 pt as 1.5 em. To make this easier we have added 1.2 em and 1.5 em to note 3 of the definition of large text as follows: Note 3: The actual size of the character that a user sees is dependent both on the author-defined size and the users display or user-agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion.Users who have low vision would be responsible for choosing appropriate settings. Response sent to commenter 23 Oct 2008. |
Issue Created: 16 Oct 2008
Source: http://lists.w3.org/Archives/Public/w3c-wai-gl/2008OctDec/0013.html
Component: Conformance
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| http://www.w3.org/TR/2008/CR-WCAG20-20080430/#conformance-partial (A) This section says that 'The form of that statement would be, "This page would conform to WCAG 2.0 at level X if the following parts from uncontrolled sources were removed." ...' I assume that this would need to be followed by the other required parts of a conformance claim http://www.w3.org/TR/2008/CR-WCAG20-20080430/#conformance-required, but this is not stated. | A statement of partial conformance is a statement of non-conformance. It says the the page does not conform but would if some part(s) of it were removed or not present. Since it is not a statement of conformance (but of non-conformance) there is no need to mention the other parts of a conformance claim since a conformance claim cannot be made. Also, listing all of the other information in a claim may be confusing and lead to the impression that the page did conform - or that parts of the page conform (which is not possible - conformance is strictly on a page basis).
In order to avoid confusion - making a partial conformance claim look like a conformance claim is not suggested. We have also made the following change to the description of partial conformance emphasize that a statement of partial conformance is a statement of non-conformance: "This page would conform to WCAG 2.0 at level X if the following parts from uncontrolled sources were removed." to "This page does not conform but would conform to WCAG 2.0 at level X if the following parts from uncontrolled sources were removed." Response to commenter 23 Oct 2008. |
Issue Created: 16 Oct 2008
Source: http://lists.w3.org/Archives/Public/w3c-wai-gl/2008OctDec/0013.html
Component: Conformance
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| This section [on partial conformance] also requires that the excluded content 'is described in a way that that users can identify (e.g. they can't be described as "all parts that we do not control" unless they are clearly marked as such.)' However, it is not clear where this description should be included: is it sufficient to only describe the excluded content in the conformance claim or should the excluded content also be identified in the conforming part of the content. For example, if you pull in image ads without alt text, what would you need to do? Which of the following would be sufficient? (b1) Conformance claim says that ads from ad server XYZ are excluded. Nothing special is done in the content. (Readers don't read conformance claims.) (b2) Conformance claim says that ads from ad server XYZ are excluded. In the web page, the text "advertisement" is added above or before every ad. (Readers don't read conformance claims.) (b3) Conformance claim says that ads from ad server XYZ are excluded. In the web page, the text "ads by XYZ" is added above or before every ad. (Readers don't read conformance claims.) (b4) Conformance claim says that ads from ad server XYZ are excluded. In the web page, the text "ads by XYZ" and a warning (or a link to the relevant section in the conformance claim) is added above or before every ad. | The information must be included in the Statement of Partial Conformance - third party content, so (b1) is sufficient (except that it is not a *conformance* claim). In general, the other options are good practice, but are not required.
However, given your description of the way the Statement of Partial Conformance has been written, the only way to conform would be to label each part in the content, since otherwise users would not be able to identify which ads came from which server. Response sent to commenter 23 Oct 2008. |
Issue Created: 16 Oct 2008
Source: http://lists.w3.org/Archives/Public/w3c-wai-gl/2008OctDec/0013.html
Component: Conformance
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| More info on how partial conformance and conformance requirement 5 interact would be welcomed. For example, if you have a page that triggers a semi-transparent Flash overlay (as an alternative to a pop-up prompt or a new window - e.g. for authentication) that traps the keyboard, and you exclude the Flash through a statement of partial conformance, does conformance requirement 5 still apply? In my opinion, the intent is that the conformance requirements still apply, but that is not clear from the section on partial conformance. According to our definition of "relied upon" the content still needs to conform if Flash is turned off or not supported, but I'm not sure if readers understand the implications of that definition. | Conformance requirement 5 applies to content under the author's control that is present in the page but not relied on. It does not apply to the excluded content from Statements of Partial Conformance.
If the third-party Flash content were removed from the page (as is required for evaluation of partial conformance), the keyboard trapping would not occur. So a Statement of Partial Conformance could still be made for such a page if the Flash content is not under the author's control and can be identified as the non-conforming content. Response sent to commenter 23 Oct 2008. |
Issue Created: 16 Oct 2008
Source: http://lists.w3.org/Archives/Public/w3c-wai-gl/2008OctDec/0013.html
Component: General
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| The audience also asked if links to other media (PDF, audio, video) need to warn users in (or near) the link text (SC 2.4.4 Link Purpose (In Context) - Level A). Such a link would cause a change of context (3.2.2 On Input - Level A; 3.2.5 Change on Request - Level AAA), but who would include link activation in "Changing the setting of any user interface component" (SC 3.2.2) - even though the definition of user interface components includes links. | It is not clear what you are asking that the user be warned of. Most links cause change of context, and we do not require a warning for change of context that results from a use action such as clicking on a link.
We added a note to Understanding Success Criterion 3.2.2 to clarify this: "Note: This Success Criterion covers changes in context due to changing the setting of a control. Clicking on links or tabs in a tab control is activating the control, not changing the setting of that control." If the type of content is important to the purpose of the link, it may be covered by Success Criterion 2.4.4 or 2.4.9. Response sent to commenter 28 Oct 2008. |
Issue Created: 16 Oct 2008
Source: http://lists.w3.org/Archives/Public/w3c-wai-gl/2008OctDec/0013.html
Component: 1.4.2 (Audio Control)
Disposition: PARTIAL/OTHER (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| If there is a mechanism to pause or stop the audio or to control its volume, it is allowed to play automatically and for more than 3 seconds. This means that a screen reader user needs to find that mechanism while the audio is still playing, i.e. interfering with the speech output of his/her screen reader. So even content that passes this SC can interfere with the user's ability to use the whole page. | Unfortunately, this is the case. The audio may be playing while the screen reader user locates and activates the mechanism to control it. The working group could find no way around this other than forbidding any audio from playing on page opening. We have added a note recommending against using audio on page opening (that lasts more than 3 seconds) as follows:
Note: Playing audio automatically when landing on a page may affect a screen reader user's ability to find the mechanism to stop it because they navigate by listening and automatically started sounds might interfere with that navigation. Therefore, we discourage the practice of automatically starting sounds (especially if they last more than 3 seconds), and encourage that the sound be *started* by an action initiated by the user after they reach the page, rather than requiring that the sound be *stopped* by an action of the user after they land on the page. Response sent to commenter 23 Oct 2008. |
Issue Created: 16 Oct 2008
Source: http://lists.w3.org/Archives/Public/w3c-wai-gl/2008OctDec/0013.html
Component: 1.4.4 (Resize text)
Disposition: ACCEPTED (Reviewer Agrees)
| Original Comment | Response from Working Group |
|---|---|
| When I created a list of success criteria that apply to synchronised media, I found the following: SC 1.2.2 at Level A requires captions. If authors want to conform at Level AA, they also need to pass SC 1.4.4 (Resize text). If captions are implemented as text (closed captions), SC 1.4.4 applies to the captions, since there is nothing in the SC that says that captions are exempted. If video plugins don't have a resize functionality, this needs to be implemented in the content. Are there any plugins for video that can resize captions? If not, in which formats can authors implement functionality to resize text? (SMIL??) | Good catch. We have modified SC 1.4.4 to add an exception for captions:
Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. We have also added an advisory technique to 1.4.4: Providing a mechanism to allow captions to be enlarged Response sent to commenter 23 Oct 2008. |
Skip to content 