Public document·View comments·Disposition of Comments·
Accessibility Guidelines Working Group Other specs in this tool Accessibility Guidelines Working Group's Issue tracker
Not all comments have been marked as replied to. The disposition of comments is not complete.
In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.
In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.
| Commentor | Comment | Working Group decision | Commentor reply |
|---|---|---|---|
LC-2532
Maria Moore <maria.moore@utas.edu.au> (archived comment) |
|
There is never a requirement for an alternative to an alternative. If an audio description is required, it is an alternative to visual information and a visual alternative to the audio alternative for the visual content is not required. Note that captions are not required to be "programmatically determined" so a deaf-blind person cannot necessarily access captions anyway. Also, audio descriptions only provide minimal coverage of the visual information unless extended audio descriptions are used -- which are not required. A machine readable text description of both audio and visual information would indeed be helpful to people who are deaf-blind and is one of the ways of meeting the level A provision. It is also explicitly required in its own provision at level AAA. |
tocheck |
LC-2513
Detlev Fischer <fischer@dias.de> (archived comment) |
|
Thank you for your comment. The title of F69 does not specifically mention text-only magnification. It can refer to zoom magnification as well. It parallels the language in the title of the success criterion itself, which mentions text resizing. Just as the title of the success criterion does not exclude zoom magnification as a means to resize text, so too the title of the failure does not exclude zoom magnification in that respect. The failure, therefore, applies equally to situations where text resize or zoom might be applied. However, as indicated in your comment, the examples provided do in fact resize correctly with zoom, and we must therefore amend the failure document to indicate that those failure examples apply only in an environment where zoom functionality is not available. Furthermore, we have added an additional example of failure when using zoom. Regarding requiring support for text-resize in this criterion, the group has discussed this issue at length and has concluded that zoom functionality is sufficient to meet this success criterion. [DONE] Add http://www.w3.org/WAI/GL/wiki/F69_Example as a third example. Add text in the description to indicate that this failure applies to both text resize and zoom resize, and that support for either is sufficient to avoid the failure. Add text in the first two examples which states clearly that they fail only in environments which do not support zoom functionality. |
tocheck |
LC-2546
Makoto Ueki <makoto.ueki@gmail.com> on behalf of JIS (archived comment) |
|
If you cannot move the focus away from the buttons without the animation restarting, then the animation cannot be paused in a manner that allows use of the page -- so it would not be considered a pause in the way it is meant in the SC. We have clarified this in the Understanding Document by adding the following. [DONE] For a mechanism to be considered "a mechanism for the user to pause," it must provide the user with a means to pause that does not tie up the user or the focus so that the page cannot be used. The word "pause" here is meant in the sense of a "pause button" although other mechanisms than a button can be used. Having an animation stop only so long as a user has focus on it (where it restarts as soon as the user moves the focus away) would not be considered a "mechanism for the user to pause" because it makes the page unusable in the process and would not meet this SC. ================================================================== [DONE] add a new section in the techniques intro after the "testing techniques" section, with title "Application of techniques", and content as follows. Techniques in this suite often contain code samples to show the technique in practice. These samples exemplify the technique but do not necessarily exemplify all aspects of good code practice or features needed to conform to other success criteria. This is to keep the examples brief and facilitate understanding of the central point of the sample. Accordingly, authors should not copy these examples in production code unless they provide the missing functionality. In addition to inline code samples, many techniques provide "working examples" that are more complete. Such samples are more appropriate as a starting point for production code, although even these may have minimal content. Many techniques describe how to provide alternate mechanisms to access content. It is important to remember that such alternate functionality must itself conform to WCAG 2.0. A given technique may focus on the basic way to provide the alternate mechanism, but authors need to follow additional relevant techniques to ensure the alternate mechanism meets requirements. Some techniques use the word "must". Because this is not a normative document, this word is not used in the sense of RFC 2119, as it is in WCAG 2.0. The colloquial use of the word "must" describes proper application of the specific technique under consideration. It does not imply requirements beyond the scope of the technique. This means it does not impose requirements on interpretation of the Success Criterion to which the technique relates. |
tocheck |
LC-2545
Makoto Ueki <makoto.ueki@gmail.com> on behalf of JIS (archived comment) |
|
Yes. Lightness/darkness is independent of color and can be used to present information in a manner that is "not color alone". Black and white is an obvious example of something which is independent of color vision. Unlike WCAG requirements for foreground text against a background, there are no specific guidelines for how much lightness/darkness (or relative luminosity) contrast there should be between two items in a chart. It would seem to differ if they were separate vs if they were touching as in your example. If touching, a contrast ratio of 3:1 is probably sufficient though 4.5:1 is better and 7:1 is best (but you cannot have three different colors with that ratio. Patterns can be used when there are more than two or three types of information to be differentiated. |
tocheck |
LC-2552
Shawn Henry <hawn@w3.org> (archived comment) |
|
[DONE] The WG thanks you for your comment. The proposed change is accepted, and the proposed sentence will be added to the appendix as you request. | tocheck |
LC-2573
Shawn Henry <shawn@w3.org> (archived comment) |
|
Thank you for catching this. We have edited the document as follows: [DONE] Web technologies may only need to be supported by those specific user agents and assistive technologies deployed at a company. (These may be older versions of user agents and assistive technologies or the very newest versions). Content posted to the public Web may need to work with a broader range of user agents and assistive technologies, including older versions. |
tocheck |