- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:27:09 -0700
- To: "Gian Sampson-Wild" <gian@tkh.com.au>
- Cc: public-comments-WCAG20@w3.org
Comment 10: LC-1112:Why isn't this technique sufficient Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0071.html (Issue ID: 2323) ---------------------------- Original Comment: ---------------------------- Comment 85: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1112) Home link: why is the technique to add a home link an additional technique? Proposed Change: Change the additional technique to a mandatory technique ---------------------------- Response from Working Group: ---------------------------- 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. ---------------------------- Response from GSW: ---------------------------- I am still unclear as to why this is not under the "Sufficient techniques" section --------------------------------------------- Response from Working Group: --------------------------------------------- The working group does not understand what is unclear about the explanation in our response about why we did not consider this a sufficient technique. Only techniques (or combinations of techniques) that are sufficient in themselves to meet the success criteria are listed as sufficient. This technique by itself is not sufficient as described above (in original response from the Working Group). ---------------------------------------------------------- Comment 11: LC-1110: Understanding SC 2.4.4 should be rewritten Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0073.html (Issue ID: 2324) ---------------------------- Original Comment: ---------------------------- Comment 83: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1110) 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 ---------------------------- Response from Working Group: ---------------------------- 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. ---------------------------- Response from GSW: ---------------------------- If this is the case then the intents and benefits section needs to be rewritten as it is peppered with benefits that are reliant on the pure link text being comprehensible (eg. tabbing from link to link) not the link text and its surrounding content. In addition to this I still believe that WCAG2 should outlaw "click here" and "more" links. --------------------------------------------- Response from Working Group: --------------------------------------------- The Intent and Benefit section encourages the use of link text that is sufficient without additional context. So this means of satisfying the success criterion is described first, and the benefits are described to make it clear why this is the preferred option. We have updated the Intent section to try to make this as clear as possible. ---------------------------------------------------------- Comment 12: LC-1109: contextual information not available to low vision users Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0074.html (Issue ID: 2325) ---------------------------- Original Comment: ---------------------------- Comment 82: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1109) 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 ---------------------------- Response from Working Group: ---------------------------- 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. ---------------------------- Response from GSW: ---------------------------- Yes but that assumes that people who cannot access the context of the link can access the hidden information, which is not the case for magnifier users. --------------------------------------------- Response from Working Group: --------------------------------------------- @@ add to response that there is a new sufficient technique to hide for everybody (see Cynthia's suggestion in response) The working group agrees that screen magnifiers do not provide low vision users with the hidden context, and we have added language to the technique to discourage its use for satisfying SC 2.4.4, where there are better techniques available. However, this is one of the few techniques available for satisfying SC 2.4.8 in situations where link text would become highly repetitive in order to describe the purpose of the link out of context. We feel it should remain available for use in this situation. ---------------------------------------------------------- Comment 13: LC 1103: deprecate use of frames Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0078.html (Issue ID: 2326) ---------------------------- Original Comment: ---------------------------- Comment 76: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1103) 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 ---------------------------- Response from Working Group: ---------------------------- 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. ---------------------------- Response from GSW: ---------------------------- I do not agree with the use of frames in this SC. If it is to remain in this SC I would like it indicated in the "Understanding WCAG2" document that frames are not preferred. --------------------------------------------- Response from Working Group: --------------------------------------------- We have clarified the description for H70 to say: "This technique is appropriate when framesets are already used to organize the content of the page; other techniques are preferred for pages that are not already using framesets, because many people using assistive technology have trouble with frames." ---------------------------------------------------------- Comment 14: LC 1100: Clarify relation between 2.3.1 and 2.3.2 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0081.html (Issue ID: 2327) ---------------------------- Original Comment: ---------------------------- Comment 73: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1100) 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. ---------------------------- Response from Working Group: ---------------------------- 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. ---------------------------- Response from GSW: ---------------------------- I am happy for this to remain at Level 3 - I trust that the WG has sufficient research to back this up - however my comment actually pertains to the use of "preventing seizures" as an intent. If WCAG2 has a SC in Level 3 that is intended not to prevent seizures then I am sure there will be questions in the larger web community as to why it is at such a high level. I understand why it is there and accept that it is the proper position for it (assuming there is research behind this) however just saying "to prevent seizures" doesn't explain why this is at Level 3 and not at Level 1 - like Checkpoint 7.1 was in WCAG1. I would recommend removing this intent or clarifying that it builds on previous SC and that those previous SC are - in most cases - sufficient enough to prevent seizures. --------------------------------------------- Response from Working Group: --------------------------------------------- Thank you. We agree that was not very clear. We have revised the intent to read: The purpose of this success criterion is to further reduce the chance of seizures. Seizures cannot be completely eliminated since some people are so sensitive. However, by eliminating all 3-per-second flashing over any area of the screen, the chances of a person having a seizure are further reduced than when just meeting the measures ordinarily used today in standards internationally, as we do at Level A. ---------------------------------------------------------- Comment 15: LC-1096: Move SC 2.2.6 to Level A Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0088.html (Issue ID: 2328) ---------------------------- Original Comment: ---------------------------- Comment 69: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1096) 2.2.6: This should be at Level 2. If someone is using an authenticated session and cannot complete the information before automatic logoff, then being able to continue after re-login is imperative in order to use the system. Otherwise the system is inaccessible Proposed Change: Move 2.2.6 to Level 1 ---------------------------- Response from Working Group: ---------------------------- The working group has discussed this issue. The criteria for having something at Level AA is that it must be something that can reasonably be applied to all Web content. But there are valid reasons, such as financial security or personal information where this cannot be done because it is against regulations to preserve any of this information once a session expires or is terminated. The working group therefore decided to put this requirement at Level AAA. ---------------------------- Response from GSW: ---------------------------- I disagree with this decision. One solution would be to put this at Level 1 or Level 2 and temper the SC by saying "except where the form has legal or financial purposes" as has been done in other SC Received on --------------------------------------------- Response from Working Group: --------------------------------------------- This success criterion requires control of the server that may not be possible for some authors and technologies. It's not appropriate for all sites because on some sites it could place a very heavy load on servers, and not all servers will have the capacity to handle that load. It is also a new success criterion in WCAG 2.0 and there is little if any experience with the requirement and the solutions. For these reasons the Working Group feels it is best positioned at level AAA. ---------------------------------------------------------- Comment 16: LC-1071: Properly positioned labels Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0100.html (Issue ID: 2329) ---------------------------- Original Comment: ---------------------------- Comment 48: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1071) Properly positioned labels: 10.2 no longer maps to any particular SC. Although this checkpoint was included in WCAG1 to assist people who use screen readers, prior to the uptake of explicit labelling, this is still a very important SC for people who use magnifiers and people with cognitive disabilities. Proposed Change: Create a new SC the equivalent of 10.2 (I am happy to write this) ---------------------------- Response from Working Group: ---------------------------- Assistive technology has advanced since the WCAG 1.0 guidelines were released. As long as the label is explicitly associated with a field, assistive technologies can present the information to the user in an understandable manner. However, since visual positioning can be important, especially for pages translated into other languages, we have added an advisory technique to Success Criterion 1.3.1 and Guideline 3.2 titled "Positioning labels to maximize predictability of relationships." Note: The mapping has been removed from the WCAG document itself. The working group will work in coordination with the EOWG WCAG 2.0 Materials Support Task Force in the creation of transition materials and will consider these comments when the mapping is updated. ---------------------------- Response from GSW: ---------------------------- I believe this needs to be a mandatory technique - not advisory. It is imperative for people with cognitive disabilities and those using magnifiers --------------------------------------------- Response from Working Group: --------------------------------------------- We have reviewed this and feel that it can not be required for the reasons stated previously. ---------------------------------------------------------- Comment 17: LC-1077: SC 1.2.7 should be Level A Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0101.html (Issue ID: 2330) ---------------------------- Original Comment: ---------------------------- Comment 53: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1077) Transcripts: Why isn't this at Level 1? Shouldn't the equivalent information be provided at Level 1? Proposed Change: Move to Level 1 ---------------------------- Response from Working Group: ---------------------------- 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. ---------------------------- Response from GSW: ---------------------------- Audio descriptions may be more effective than transcripts for people with audio impairments but what about people who are blind? Are captions required at Level A? What about people who can't operate the multimedia file? Or whose assistive technology does not interact with the multimedia file? --------------------------------------------- Response from Working Group: --------------------------------------------- > Audio descriptions may be more effective than transcripts for people with audio impairments but what about people who are blind? At Level A, audio descriptions or multimedia alternatives to text satisfy SC 1.2.2. Audio descriptions are not an accommodation for people with audio impairments; they are an accommodation for people who are blind. > Are captions required at Level A? Yes, SC 1.2.1 (Captions) is at Level A. > What about people who can't operate the multimedia file? Operating the multimedia file would be covered under Principle 2. If the concern is keyboard access for operating the multimedia file, this would be covered under GL 2.1. > Or whose assistive technology does not interact with the multimedia file? We assume this concern refers to assistive technology that cannot interact with the controller for playing the multimedia. We are not aware of assistive technology that interacts directly with multimedia files. Assistive technology support for interacting with the multimedia file is a question of whether the technology is accessibility supported. If it is not, then use of the multimedia would not comform. ---------------------------------------------------------- Comment 18: LC-1075: testability of text alternatives Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0103.html (Issue ID: 2331) ---------------------------- Original Comment: ---------------------------- Comment 52: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1075) 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" ---------------------------- Response from Working Group: ---------------------------- 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. ---------------------------- Response from GSW: ---------------------------- How does this fit with testability? Surely if the same alternative text could be used, or different alternative text could be used then it doesn't conform with testability. Any my comment was about what images are intended to convey - sometimes they are specific to the site. Another (perhaps clearer) example would be an image of the world. On a travel site the alternative text might be "International travel" (especially if it is used to link to the international travel section). On an environmental site the alternative text might be "Our earth is precious", or "We've only got one earth so we must treasure it". On a university web site it might be "international campuses". --------------------------------------------- Response from Working Group: --------------------------------------------- We agree that different alternative text can be appropriate for the same image in different contexts, and that your example of images of the world is a good one. We have added it to the examples for Understanding SC 1.1.1. ---------------------------------------------------------- Comment 19: LC-1072: advisory techniques should have conformance levels Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0105.html (Issue ID: 2332) ---------------------------- Original Comment: ---------------------------- Comment 49: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1072) 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 ---------------------------- Response from Working Group: ---------------------------- 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. ---------------------------- Response from GSW: ---------------------------- Advisory techniques are not testable - that's why they are advisory. Therefore there should be no problem in associated advisory techniques with a particular SC and therefore a particular level. --------------------------------------------- Response from Working Group: --------------------------------------------- Advisory techniques cannot be associated with a success criterion that they do not address. However, we have added new SC that relate to some of the advisory techniques that were previously under guidelines and have been able to move those techniques down to the SC . Move from GL 1.2 to SC 1.2.4: Providing audio description for live multimedia (future link) [LC-487] Remove from GL 1.3 (superceded by SC 1.4.4): Providing resizable text (future link) Move from GL 1.3 to SC 1.3.1: G140: Separating information and structure from presentation so that Web pages can be presented different ways without losing information [LC-1201] Add to SC 2.4.9, but do not remove from GL 2.4: Providing mechanisms to navigate to different sections of the content of a Web page (future link) [LC-928] In GL 3.1, change "Setting expectations about auto-generated or user-contributed content (future link)" to "Setting expectations about content in the page from uncontrolled sources (future link)" Add to SC 1.4.3, 1.4.5, but do not remove from GL 3.1: Using a light pastel background rather than a white background behind black text (future link) Move from GL 3.1 to new SC 2.4.X (Focus Visible): Highlighting a link or control when the mouse hovers over it (future link) Added new SC 1.4.8 : For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA) -foreground and background colors can be selected by the user -width is no more than 80 characters: -text is not aligned on both the left and the right -line spacing is at least space-and-a-half within paragraphs, and paragraph spacing is larger than line spacing -text is resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text + advisories Additional Techniques (Advisory) for 1.4.8 Using a hover effect to highlight a paragraph, list items, or table cells(HTML, CSS) Presenting text in sans serif font or providing a mechanism to achieve this (CSS) Using bulleted/numbered/vertical lists rather than inline lists Using upper and lower case according to the spelling conventions of the text language Providing large fonts by default Avoiding the use of text in raster images Avoiding scaling font sizes smaller than the user-agent default Providing sufficient inter-column spacing [LC-569 (add)] Avoiding centrally aligned text [LC-1253] Avoiding chunks of italic text [LC-1253] Avoiding overuse of different styles on individual pages and in sites [LC-1253] Making links visually distinct [LC-1300] Providing expandable bullets Show/hide bullet points] Putting an em-space or two spaces after sentences ---------------------------------------------------------- Comment 20: LC-1070: Clarify relying on CSS to convey information Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0106.html (Issue ID: 2333) ---------------------------- Original Comment: ---------------------------- Comment 47: Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer (Issue ID: LC-1070) Baseline CSS: This mapping essentially says that if CSS is in the baseline then information can be put into the style sheet and not in the HTML. This appears to allow formatting (ie headings) via CSS and not HTML, important images included in CSS and not HTML, etc. How is someone who uses a screen reader going to interpret this? How are they going to be able to access the information they require? Proposed Change: Clarify baseline requirements ---------------------------- Response from Working Group: ---------------------------- If CSS is an accessibility-supported Web technology, then the author can rely on it to satisfy success criterion. However, the success criterion must still be satisfied. So, for instance, if non-text content that conveys information is included via CSS, SC 1.1.1 requires that a text alternative also present equivalent information. This information must be programmatically determined, that is, exposed to assistive technologies. So even if most of the features or functionality of a Web technology are accessibility supported, it may not be possible to use certain functionality in the technology and still conform to WCAG. We have completely rewritten the Conformance section, and this should now be clearer. ---------------------------- Response from GSW: ---------------------------- I don't believe this is clear from reading the conformance section. Perhaps some examples would assist? For example an image that is integral to the user shouldn't sit within CSS because it cannot be accessed by AT - therefore it should sit within the HTML so that AT can access it and it's alternative text. Another example should be that developers use <h1> etc instead of <class="heading1"> as the former is a recognized element by AT. --------------------------------------------- Response from Working Group: --------------------------------------------- Since the May 2007 draft, we have revised the conformance section significantly and have provided additional details in the Understanding document related to conformance. Your example of including important information within images is covered by failure F3: Failure of SC 1.1.1 due to using CSS to include images that convey important information. The use of CSS to indicate headings would be a failure of 1.3.1 and is addressed through failure F2: Failure of 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text.
Received on Sunday, 4 November 2007 04:27:22 UTC