W3C

Disposition of comments for the Accessibility Guidelines Working Group

Single page view

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.

CommentorCommentWorking Group decisionCommentor reply
LC-2532 Maria Moore <maria.moore@utas.edu.au> (archived comment)
I am a bit unclear about the note on http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-av-only-alt.html, that says /Note: /A text equivalent is not required for audio that is provided as an equivalent for video with no audio information. For example, it is not required to caption video description that is provided as an alternative to a silent movie.
> Surely this does not assist deaf-blind people? I would have thought that a text equivalent would be needed.

Proposed Change:
Providing an audio description of video only creates another file (the audio description), that needs a text equivalent
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)
The "How to meet" document offers four alternative options to meet SC 1.4.4 (Resize Text), one of them simply "G142: Using a technology that has commonly-available user agents that support zoom". F69, on the other hand, describes the failure of clipping , truncating or obscuring text when applying text-only magnification to 200%. It seems that the How to meet" document should link support for page zoom to a (perhaps more modest) support for text-only zoom. Just affording page zoom (this works nearly always without any extra effort) does not prevent the failure 69 when scaling text only.

Proposed Change:
Change logic in the "How to meet" document: G142 alone is not good enough. In addition, text-only resizing must also work to ensure a pass of F69.
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)
Flash animation is embedded in a HTML web page. The animation has five screens. It starts automatically, lasts more than five seconds, and is presented in parallel with other content. It also has five buttons to stop the animation. When each button receive focus, the movement of the animation will be paused.

Is this considered to be "a mechanism for the user to pause" the animation?

The point is that it might not be obvious for users to understand that the buttons are the mechanism.

Example:
http://www.fujitsu.com/us/

Proposed Change:
Need an answer from WCAG WG to harmonize JIS with WCAG 2.0.
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)
Will SC 1.4.1 be applied to a stacked bar chart?

For example, a stacked bar chart shows two items by using two different colors. There are the graph legends near the chart which explains what is represented by each bar and color. The patterns are not used.

It might depend on the colors used in the chart. If the colors are black and white, will SC 1.4.1 be applied to the image of the stacked bar chart?

In that case, the color differences are used to convey information within non-text content. However the patterns are not necessarily needed to convey the same information in a manner that does not depend on color. Because black and white has sufficient contrast ratio and brightness difference.

Does SC 1.4.1 require the authors to include patterns to any combination of colors?

If yes, could you explain the reason why the patterns are needed for black and white?

Proposed Change:
Need an answer from WCAG WG in order to harmonize JIS and WCAG 2.0.
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)
We now have additional information on generally referencing and linking to WAI technical documents. Ideally we'd spend some time to integrate these better; however, I don't think it's worth the time. Instead I propose one little addition to this appendix. Thanks. (I added a a link to this appendix from that document.)

Proposed Change:
Add to the beginning: For additional guidance, see <a href="http://www.w3.org/WAI/intro/linking.html">Referencing and Linking to WAI Guidelines and Technical Documents</a>.
[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)
Under Level of Assistive Technology Support Needed for "Accessibility Support" list item 1 says: Accessibility support of Web technologies varies by environment
- In a company where all employees are provided with particular user agents and assistive technologies, Web technologies may need to only be supported by those user agents and older assistive technologies.
- Content posted to the public Web may need to work with a broader range of user agents and assistive technologies.
"

I think the "older" is incorrect in the first bullet. I think it should be deleted. (because the point is that if users are known to have certain AT, then you do *not* have to support older AT, yes?)

To further clarify, consider adding it to the second sub-point.

Proposed Change:
...Web technologies may need to only be supported by those user agents and assistive technologies.

Content posted to the public Web may need to work with a broader range of user agents and assistive technologies, including older versions.
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

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:40:18 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org