Disposition of comments for the Accessibility Guidelines Working Group

Single page view

1-20 21-40 41-60 61-80 81-100 101-120 121-127

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-1072 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Advisory techniques: There should not be any advisory techniques unless they are linked to a particular SC. Having advisory techniques linked to a GL only, means that the level (A, AA or AAA) is not specified.

Proposed Change:

Move all GL advisory techniques to specific SC
Because WCAG 2.0 success criteria are written as testable statements, it is not always possible to associate techniques that are difficult to test or subjective in nature with success criterion. However, the working group feels that it is important to make these technqiues available for authors who are interested in improving the accessibility of their content beyond the minimum conformance requirements. Note that regardless of association with a success criterion or guideline, whether an author chooses to implement advisory technqiues does not impact the level of conformance claimed. no
LC-1077 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Transcripts: Why isn't this at Level 1? Shouldn't the equivalent information be provided at Level 1?

Proposed Change:

Move to Level 1
Success criteria 1.2.2, 1.2.3 and 1.2.7 build upon one another. At Level A, SC 1.2.2 can be satisfied either by providing a full text alternative for multimedia or by providing audio description of the video. At level A, multimedia will either have a full text alternative or an audio description.

At Level AA, SC 1.2.3 requires an audio description. So multimedia that satisfies level AA either has only an audio description, or both an audio description and a full text alternative.

At Level AAA, SC 1.2.7 requires a full text alternative, so at level AAA content will have both an audio description and a full text alternative.

Success criterion 1.2.7 is not required at Level A because audio descriptions are usually more effective than transcripts. This is due to the fact that they contain much additional rich audio information from the sounds track and because they allow individuals who are blind the option of viewing the material with other people. Full text descriptions, however, are an option for meeting this guideline at Level A.
LC-1100 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Seizures: This is a Level 3 SC yet the Intent specifies that it is intended not to cause seizures.

Proposed Change:

Clarify the SC. If it is intended not to cause seizures it should be at Level 1.
The primary seizure provision is already at Level A. This provision is an extra measure that can be taken for those who want to go above and beyond. It covers all flashing including very small areas of the screen that would not be sufficient to cause problems. The purpose is to allow users to use extreme magnification and still not have a problem. This goes beyond all current standards. no
LC-1103 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Frames: 2.4.1 is a Level 1 SC. I don't believe we should be advocating frames at the minimum level (see Techniques section). There are better ways to group blocks of repeated content

Proposed Change:

Remove the frame technique
If a page is already using frames, then this is a sufficient technique for grouping the repeated content. So we are keeping it in the list of sufficient techniques, but we have added to the technique description to indicate that other techniques are preferred if the content doesn't already use frames. no
LC-1109 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Supplemental text: I completely disagree with supplementing link text with hidden text via CSS. If more information is required in order to understand the link, then it should be available to everyone, not just people who use screen readers

Proposed Change:

Remove this Technique
The description of this technique indicates that this is an appropriate technique when information is already provided in the surrounding context but is needed as part of the link text to interpret the link text when it is displayed out of context. The supplementary text would be information that is already available to all when the link is read in context. no
LC-1112 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Home link: why is the technique to add a home link an additional technique?

Proposed Change:

Change the additional technique to a mandatory technique
No techniques are mandatory. Any technique that is sufficient to meet the success criterion may be used.

The technique to add a home link was made advisory because it is not considered sufficient by itself to satisfy success criterion 2.4.7. Just locating the home page, while helpful, is not enough to orient the user within the set of web units because the user has no information about the organization of the web units.
LC-1091 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Script: The techniques and examples are very script heavy. It appears, to a casual reader, that the W3C is advocating scripting above other technologies, such as PDF, XHTML or CSS.

Proposed Change:

Ensure that techniques and examples are evenly spread over a variety of technologies
The examples have to match the technologies. The scripting examples are only used where we are trying to demonstrate dynamic content. Scripting is the most common method for this. If you have other examples you think could be included, please submit them. We are always looking for additional good examples. no
LC-1129 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
There are examples in the Intent section

Proposed Change:

All examples should be in the Examples or Failures section
The examples in this item are not examples of the success criterion or meeting the success criterion but rather examples of what we mean by one of the terms in the success criterion. So these particular examples can't go in the examples section. no
LC-1075 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Example 6: Add another alt text example "Shaking a world leader's hand can subtly affect the distribution of power in the relationship" and "Shaking hands is a purely Western artifice"
The Working Group feels that your first proposed example reveals an opinion and is thus not appropriate alternative text for the situation described in the photograph. While the second alternative may be true, it does not sufficiently describe the image. We have not updated the example with these additional alternatives. Instead, we are including the following example:

On one page a checkmark is used to indicate that an item should be ordered and and on another page it is used to indicate that a step has been completed. The same alt text "checked" could be used but since they serve different purposes, different text alternative may make it easier to understand.
LC-1110 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Click here: Please clarify whether or not this SC allows for link text such as "Click here" and "more". If so this SC should be rewritten to outlaw this ext

Proposed Change:

Clarify or rewrite SC
SC 2.4.4 allows for link text such as "Click here" and "more" as long as the purpose of the link can still be determined from programmatically determined context such as the enclosing sentence, paragraph, or list item. We have added such an example to How To Meet SC 2.4.4, to clarify that they are permitted. However, the Intent section of How To Meet SC 2.4.4 has been changed to encourage authors to make the link text as meaningful as possible. no
LC-1121 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Situation A - If an application causes a legal transaction…: what is a "period of time"? Is this going to be quantified? Should we be doing that?

Proposed Change:

Clarify the Technique
When this technique is completed, guidelines for the period of time will be qualified within the technique based on the situations provided. For example, when accepting an on-line loan offer there may be a legal requirement that the transaction can be reversed within a certain number of hours or days. A loan payment, however, may have a much shorter time period to cancel. no
LC-1130 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Needs more examples
This success criterion requires that you not do something. We don't provide examples of things not to do because they can be misunderstood as examples of how to conform. We tried to think of positive examples of thing to do that didn't violate the provision but that was pretty much anything. We have provided one. If you can think of another positive example (not an example of a failure) we would be happy to include it as well. no
LC-1018 Judy Brewer <jbrewer@w3.org> on behalf of W3C/WAI, on behalf of the Education and Outreach Working Group (archived comment)
Part of Item: Intent
Comment Type: editorial
Comment (including rationale for proposed change):

For each guideline & success criteria, provide a couple of word summary, rather than just a number. Sometimes referred to as \"shortname\".

Proposed Change:
We have included short handles in the draft to make the success criterion easier to reference. no
LC-1308 Charles McCathieNevile <chaals@opera.com> (archived comment)

In the current framework, while there are success criteria there are no
normative explanations of how they apply to given technologies. Instead,
understanding WCAG 2.0 has been made an informative document.

This is inappropriate to ensure interoperability of tools and content.
This has been a major problem with the implementation of WCAG 1.0, where
important questions of interpretation (such as "are tables OK for
layout?", "do all user agents identify form fields without default text in
them?", "is it OK to rely on javascript?", "are px units OK for layout?"
among others) have gone unanswered for many years leading to a major
breakdown in interoperability between tools, services, and content itself.

I propose that the information be made available in a normative document.
The process requirements for publishing such a document would seem to be
very lightweight in the context of how long it takes the WCAG group to
determine necessary changes, and this will at least ensure that an
authorative answer becomes available for issues which arise.


It has been challenging to write success criteria that are technology neutral, testable, and easy to understand. We have taken great pains to write the success criteria so that it would be clear which techniques would or would not pass to experts. We are using the Understanding document to make it clear for those who are not experts. However, we don't want to restrict the range of solutions by making the list of known solutions normative. We do not believe that we could update normative Understanding and Technique documents quickly enough to keep pace with the changes in technologies and user agents. The W3C process is long for any document.

This approach also allows WCAG 2.0 to avoid introducing some of the "until user agent" problems from WCAG 1.0.
LC-1081 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Example 2: As previously discussed, people who use screen readers (people with vision impairments and people with dyslexia) expect that the order of the site with CSS on matches the order of the site with CSS off

Proposed Change:

Change this example so that the order of the content is the same with CSS on or off
Success criteria 1.3.2 (formerly 1.3.3) does not require that the reading order be the same with CSS off as with it on. It only requires that if the order can change the meaning, the correct order can be determined. Example 2 is therefore an appropriate illustration of conforming to this success criterion. tocheck
LC-1102 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Limiting the number of links per page: Firstly this should be an advisory technique under a specific SC, not under the entire GL (otherwise how do we know what level it is aimed at?). Secondly, why is this a technique? A portal site or a news site etc would have difficulty complying and I believe the number of links on a page is entirely dependent on the content. It will be diffiicult to define a "limit"

Proposed Change:

Remove this advisory technique
Because the technique is advisory, it is not associated with any level. Levels are associated with conformance statements, but are not an indication of importance.

This is an advisory technique for the guideline rather than for one of the success criteria because it does not address any of the success criteria, but is a technique that can improve the accessibility of the content for some users.

The technique is also advisory because there is no clear test for how many links a page could contain before it would fail.

We agree that there are sites, such as portals or news sites, which would have a difficult time using this technique. Such sites should use other techniques to make keyboard navigation manageable and to make the organization of the page easy to understand.
LC-1118 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Examples: The two examples should be moved to Advisory Techniques
The working group believes that these examples are just specific instances of some of the already listed future advisory techniques. There are many ways of meeting this success criterion and we don't want to give undue weight to particular instances by providing advisory techniques about some methods and not others.

The example titled "Additional Help for Correcting An Input Error" would be covered in the "Displaying errors and suggestions in the context of the original form (for example, re-displaying a form where input errors and suggestions for correction are highlighted and displayed in the context of the original form)" technique.

The example about correcting the input of months would be covered in the technique titled, "Providing a text message that contains information about the number of input errors, suggestions for corrections for each item, and instructions on how to proceed".
LC-1119 Gian Sampson-Wild <gian@tkh.com.au> (archived comment)
Is this SC about providing corrections to field errors or highlighting field errors. The techniques and examples seem contradictory

Proposed Change:

Clarify the techniques and examples
The working group feels that the three situations in How To Meet SC 3.3.2 (formerly 2.5.2) do require that suggestions for correction be provided. The description and examples in these techniques provide general instructions for how to highlight the error and what type of information should be provided to help the user correct the error. The How To Meet document has also been updated to indicate that more than one situation and technique may apply. We have also retained Situation A about mandatory fields since the user needs to be informed that a field is required but may not always require suggested corrections such as in the case of a field requiring the user name.

In addition, the following HTML and Client Side Scripting future Techniques have been added as sufficient for Situations B and C

Situation B: If information for a field is required to be in a specific data format:

1. G85: Providing a text description when user input falls outside the required format or values
2. Providing links to suggested correction text "close to" form fields, or providing the suggested correction text itself directly on the Web unit "next to" form fields (future link)
3. SCR18: Providing client-side validation and alert (SCRIPT)
4. Providing client-side validation and adding error text via the DOM (future link)

Situation C: Information provided by the user is required to be one of a limited set of values:

1. G84: Providing a text description when the user provides information that is not in the list of allowed values
2. Providing links to suggested correction text "close to" form fields, or providing the suggested correction text itself directly on the Web unit "next to" form fields (future link)
3. SCR18: Providing client-side validation and alert (SCRIPT)
4. Providing client-side validation and adding error text via the DOM (future link)
LC-784 Joe Clark 1 <joeclark@joeclark.org> (archived comment)

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html

Time limits

In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.

Then that isn't an issue of Web content anymore. Hiring a human aide to make a site accessible to you is no longer our problem.
Using a human aide is similar in this instance to using a screen reader,
in that it is an accommodation that may cause the user to need more time. Therefore, we think it is an appropriate benefit for the time limits success criterion.
LC-592 Martin Stehle <pewtah@snafu.de> (archived comment)
Comment (including rationale for any proposed change):

The technical notes are not wrong, but misleading. One can get the impression that sign language videos are only necessary if there are captions in videos. This does not meet the reality.

Proposed Change:

Please delete this notes.
Captions are required for all multimedia at level AA (1.2.1 Captions are provided for prerecorded multimedia., 1.2.4 Captions are provided for live multimedia. ) It is helpful to discuss why signed language interpretation is needed even though captions are already available in any multimedia being considered at level AAA. yes

1-20 21-40 41-60 61-80 81-100 101-120 121-127

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