Public document·View comments·Disposition of Comments·
Accessibility Guidelines Working Group Other specs in this tool Accessibility Guidelines Working Group's Issue tracker
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.
| Commentor | Comment | Working Group decision | Commentor reply |
|---|---|---|---|
LC-1072
Gian Sampson-Wild <gian@tkh.com.au> (archived comment) |
|
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) |
|
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. |
no |
LC-1100
Gian Sampson-Wild <gian@tkh.com.au> (archived comment) |
|
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) |
|
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) |
|
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) |
|
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. |
no |
LC-1091
Gian Sampson-Wild <gian@tkh.com.au> (archived comment) |
|
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) |
|
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) |
|
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. |
no |
LC-1110
Gian Sampson-Wild <gian@tkh.com.au> (archived comment) |
|
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) |
|
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) |
|
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) |
|
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) |
|
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. |
yes |
LC-1081
Gian Sampson-Wild <gian@tkh.com.au> (archived comment) |
|
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) |
|
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. |
yes |
LC-1118
Gian Sampson-Wild <gian@tkh.com.au> (archived comment) |
|
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". |
tocheck |
LC-1119
Gian Sampson-Wild <gian@tkh.com.au> (archived comment) |
|
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) |
yes |
LC-784
Joe Clark 1 <joeclark@joeclark.org> (archived comment) |
|
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. |
tocheck |
LC-592
Martin Stehle <pewtah@snafu.de> (archived comment) |
|
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 |