- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:09:39 -0700
- To: "Aurelien Levy" <aurelien.levy@free.fr>
- Cc: public-comments-WCAG20@w3.org
Dear Aurelien Levy, Thank you for your comments on the 17 May 2007 Public Working Draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0 http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group has reviewed all comments received on the May draft, and will be publishing an updated Public Working Draft shortly. Before we do that, we would like to know whether we have understood your comments correctly, and also whether you are satisfied with our resolutions. Please review our resolutions for the following comments, and reply to us by 19 November 2007 at public-comments-wcag20@w3.org to say whether you are satisfied. Note that this list is publicly archived. Note also that we are not asking for new issues, nor for an updated review of the entire document at this time. Please see below for the text of comments that you submitted and our resolutions to your comments. Each comment includes a link to the archived copy of your original comment on http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may also include links to the relevant changes in the WCAG 2.0 Editor's Draft of May-October 2007 at http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/ Thank you for your time reviewing and sending comments. Though we cannot always do exactly what each commenter requests, all of the comments are valuable to the development of WCAG 2.0. Regards, Loretta Guarino Reid, WCAG WG Co-Chair Gregg Vanderheiden, WCAG WG Co-Chair Michael Cooper, WCAG WG Staff Contact On behalf of the WCAG Working Group ---------------------------------------------------------- Comment 1: Switching languages within an attribute Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0206.html (Issue ID: 2021) ---------------------------- Original Comment: ---------------------------- what about lang in attribute value like an English alt attribute in a french page and what about attribute value who mix the language --------------------------------------------- Response from Working Group: --------------------------------------------- If the language of an alt attribute is different from the surrounding text, the element should be given a lang attribute to indicate the language of the alt attribute. HTML provides no mechanism for marking up language changes within an attribute. In such a situation, another technique may be needed that provides this support. For instance, longdesc could provide a link to a web page in which the language changes could be marked up explicitly. This is awkward and only works for images. For other attributes, mixed languages could not be used and still conform to this particular SC. ---------------------------------------------------------- Comment 2: F44 is failure of 2.4.3, not 2.4.4 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0201.html (Issue ID: 2022) ---------------------------- Original Comment: ---------------------------- This is a 2.4.3 failure not 2.4.4 Proposed Change: *F44: Failure of SC 2.4.3 due to using tabindex to create a tab order that does not follow relationships and sequences in the content --------------------------------------------- Response from Working Group: --------------------------------------------- We have corrected this error in the Failure title. ---------------------------------------------------------- Comment 3: F63 is a failure of 2.4.4, not 2.4.6 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0202.html (Issue ID: 2023) ---------------------------- Original Comment: ---------------------------- this is a 2.4.4 failure Proposed Change: F63: Failure of SC 2.4.4 due to providing link context only in content that is not related to the link --------------------------------------------- Response from Working Group: --------------------------------------------- We have corrected this error in the failure title. ---------------------------------------------------------- Comment 4: contextual alternative Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0148.html (Issue ID: 2027) ---------------------------- Original Comment: ---------------------------- i didn\'t see anywhere that i can have an empty alt attribut on an image when the text alternative is next to the image tag like : <img alt=\"\" src=\"cars.pjg\">A nice racing car What about image replacement technique like here :http://www.mezzoblue.com/tests/revised-image-replacement/ for me the last technique is perfectly accessible --------------------------------------------- Response from Working Group: --------------------------------------------- The use of an empty alt tag on images is reserved for decorative images, not for images that are redundant with text elsewhere on the page. If an image is described on the page, there is a sufficient technique that allows one to put a short phrase in the image that points to a description in the text. For example alt="Picture of car described in text immediately following this image". If, however the image and text were enclosed within the same link (ex. Products page) then the empty alt attribute value could be used. Refer to technique H2: Combining adjacent image and text links for the same resource (http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H2.html) for more information. Regarding the image replacement technique you referenced, since the use of non-text content in the Shea Enhancement example would be considered decorative and the "alternative" is available to AT, then this technique would be sufficient to meet 1.1.1. To clarify this, we have added an example to C9: Using CSS to include decorative images. ---------------------------------------------------------- Comment 5: level of SC 1.2.3 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0149.html (Issue ID: 2028) ---------------------------- Original Comment: ---------------------------- I really think this success criteria must be in AAA because of his cost, and difficulty to be integrated in an industrial production of video. On the other hand I don't understand why the live audiodescription in not included in the document even at a AAA level. If it was include it must be at the same level as the live captioning --------------------------------------------- Response from Working Group: --------------------------------------------- Captioning of live material is both important and possible today. For material that is professionally broadcast on the Web the cost would be much less than the production cost. For informal, non-professional live productions, we agree that this criterion would be difficult to meet. Audio description of live material is not possible without significantly delaying the material except in the few cases where the material is a play or other pre-scripted activity. The describer simply doesn't know when the gaps in audio will occur or how long they will be. ---------------------------------------------------------- Comment 6: contextual caption and summary Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0150.html (Issue ID: 2029) ---------------------------- Original Comment: ---------------------------- What about data table without caption and summary but textual information just before the table who actually is the caption or summary information. For example, if i do shopping cart with a table element and just before the table use something like <h3> Your shopping cart</h3> <p> in every line of your shopping cart who will find, the production name, it's price and the quantity you want</p> --------------------------------------------- Response from Working Group: --------------------------------------------- The example provided in your comment would lack the characteristic of programmatically exposing the relationship between the table and header / summary provided before it. Users navigating from table to table might not easily find this information, as they would if the information were directly associated with the table. Therefore, it would be an example in which the HTML techniques for caption and summary would be preferred. That said, it may still be a judgement call about what information should appear as in your example and what would need to be directly associated with the table, and it may be most appropriate to duplicate some information, such as providing the summary both in the paragraph before the table and in the summary attribute of the table itself. ---------------------------------------------------------- Comment 7: missing information on SC 1.3.3 common failures Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0151.html (Issue ID: 2030) ---------------------------- Original Comment: ---------------------------- What about the use of shape to convey information by itself for exemple a two parts document the first part is in a square shape and the others is in a rounded square shape. The distinction between the two part is just a visual distinction based on his shape. --------------------------------------------- Response from Working Group: --------------------------------------------- If shape were used to convey information in the absence of any instructions, then it would be a failure of 1.1.1 or 1.3.1. If there were instructions that depended on the shapes - then it would be a failure of 1.3.3. For example, for text content styled with CSS to generate containers with different shape in a page where instructions rely on the shape of these containers, there would be a failure of SC 1.3.3. However, if the different shapes are just used to make the different sections more distinct visually, but the actual shape does not convey information - then this would not violate the success criterion - nor success criterion 1.1.1. ---------------------------------------------------------- Comment 8: Use of color information for contextual distinction Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0152.html (Issue ID: 2031) ---------------------------- Original Comment: ---------------------------- make sure clearly define : Ensuring that when text color is used to convey information, the text style is visually differentiated without color (future link) for example is this a failure : - Use a different color scheme between two category of a website - Use background color to show what is the currently visited page in a navigation bar Currently, the background color of an element to give information is not treated at all. Furthermore, without color is equal to turning off color only or style too ? I think the G111 technique can't be achieve in every case specially in maps, you must add the text information case like G111: Using color and pattern or textual information. If I have a map with two road to go to a point, I can use two different colors for the two roads put I can identify road in text like road 1 and road 2 Finally , I think the F73: Failure of SC 1.4.1 due to creating links that are not visually evident without color vision must me more clear to directly identify that it's just for links within text that is part of a sentence or paragraph. Even with that I'm not sure it's a good point because bold or italicized text can be hard to read in some case so the only way i have is to underline the link. I think the link must be visually different but i think color difference can be sufficient if the color difference is sufficient. Exemple: red link and black text pass the test, dark grey link and black text fail. People who actually didn't see the red still see a color difference. --------------------------------------------- Response from Working Group: --------------------------------------------- We have changed the success criteria and the Failure to allow more types of 'non-color coding' including differences in luminance such as you suggested. (see below) G111 may not always be applicable but it is not required. It is one technique. We have also added another technique: "Conveying all information in text that is conveyed in color" SC 1.4.1 has been reworded as: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. In F73, the following note has been added to the Description: If the link is a different color and bold it would not fail because the boldness is not color dependent. ---------------------------------------------------------- Comment 9: Contrast value and background problem Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0154.html (Issue ID: 2032) ---------------------------- Original Comment: ---------------------------- First I think the 5:1 value is too difficult to achieve currently something like every website will fail (even the w3 website actually), a 4:1 value seen to be more realistic to me. The document must be more clear about how to handle text hover background or gradient image, the G18 technique must be more explicit how to test it. For example, how many pixel must have the halo to validate ? The success and failure technique must repeat (and images of text) in there wording like in the criterion itself to more clear. For the h21 and f24 I'm ok for most of the part but I think their is a case where the user must specify there need correctly. For example, if the author specify white background color on body element and the user has modified is UA to have black background, the user must change the text color too, it's nonsense to just modify the background color. Futhermore, it's to UA to propose alternate style sheet (like opera browser do) and option to render webpage with user preference in every case Finally, there is case where even with good color contrast a text is still difficult to read look at this example : http://yorunokoe.net/ressources/medias/Dautant.png --------------------------------------------- Response from Working Group: --------------------------------------------- We have added information to make it clearer how to handle text over a background including: H21: Not specifying background color, not specifying text color, and not using CSS that changes those defaults (HTML) F24: Failure of SC 1.4.3 and 1.4.5 due to specifying foreground colors without specifying background colors or vice versa We have added "(and images of text) " to the techniques. We are staying with 5:1 at Level AA based on the rationale in the Understanding 1.4.3. We have no contrast required at Level A since high contrast system highlighting and simple color shifting assistive technology can address the problem there. ---------------------------------------------------------- Comment 10: Please choose your side, UA bug or not ? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0158.html (Issue ID: 2034) ---------------------------- Original Comment: ---------------------------- Can you give me a case where this criteria is failed, with the current sufficient technique I can pass every time since html support zoom and opera zoom can render perfectly in every case. Otherwise define what is commonly available. And this one : 3. Providing controls on the Web page that incrementally change the size of the text (future link) Please tell me that it's not javascript widget width some 10pxX10px image to increase or decrease the text size of part of the page. If it case the case, it was just another way to say everybody will pass this criteria. So please, choose your side, it's an UA problem or it's not. If it's not, the only way to pass the test must be that the page render correctly when the user increase the text size to 200% with the UA features (if it don't resize at all, like IE with pixel, it's an IE bug not accessibility issue from the author, otherwise add a criteria about use off %, keyword or em value for text sizing) --------------------------------------------- Response from Working Group: --------------------------------------------- This success criterion includes a heavy interaction with user agent functionality. The goal is to ensure that, between the user agent and the author, a way is provided to the user to resize text. It is important to remember that this success criterion is not just about HTML. Other technologies have their own user agents with varying capabilities. The author cannot rely on the user agent to satisfy SC 1.4.4 for HTML content if users do not have access to a user agent with zoom support. For example, if they work in an environment that requires them to use IE 6 or Firefox. If the author is using a technology whose user agents do not provide zoom support, the author is responsible to provide this type of functionality directly or to provide content that works with the type of functionality provided by the user agent. If the user agent doesn't provide zoom functionality but does let the user change the text size, the author is responsible for ensuring that the content remains usable when the text is resized. The working group anticipates that, over time, this success criterion will be satisfied by user agents and not by authors directly. ---------------------------------------------------------- Comment 11: G21: UA bug on object Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0182.html (Issue ID: 2043) ---------------------------- Original Comment: ---------------------------- I think the G21 technique is partially wrong because for most of the case it's an UA, plugin or AT manufacturers problem not an author probem. For example, actually Firefox don't provide a way to navigate with keyboard trough a Flash object. the only way to achieve this is to click on it with the mouse and then click outside the flash to get the focus out. It's a Firefox bug not an author mistake, yes the author can hack this bug by providing a link before the flash and then use javascript and actionscript to move focus in and out of the flash element but what if javascript is turned off ? Yes the users must not be trapped in the content, but for me it's just applicable in the case where the plugin or UA provide a way to access it (in and out) with the keyboard. So, it's more : don't break the UA or plugin feature to access plugin element otherwise the user can be trapped in the element. For exemple, at this time, for Flash element, it's equal to test that with IE the user can go trough the flash element without be trapped, with other browser i haven't to test it because they don't provide a way to trough the flash element with keyboard without the mouse (for Firefox, Safari and Opera at least) --------------------------------------------- Response from Working Group: --------------------------------------------- We have fixed the technique to be more accurate and clear. "If the author uses a technology that does not allow users to exit the sub-content by default (i.e. it is not a feature of the web content technology or its user agents) then, in order to implement this technique the author would build such a capability into their content or not use the technology." This captures the dependency that all web content techniques have on user agent and assistive technology support. The user will be trapped in the content just as badly, whether the error is in the authored content or the user agent. The author must choose techniques and technologies for which WCAG can be satisfied. ---------------------------------------------------------- Comment 12: Frame technique promote old fashion web Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0183.html (Issue ID: 2044) ---------------------------- Original Comment: ---------------------------- Please remove the H70 technique even with title attribute frame is painful to use, it's no a good example to promote accessible web. Yes, this way I can skip them easily but I can't use , access the content of the frame easily. Don't promote old fashion web --------------------------------------------- Response from Working Group: --------------------------------------------- H70 says that the technique of using frames to group repeated material is only appropriate when framesets are already used to organize the content of the page, and that other techniques are preferred. Assistive technology support for frames has improved, so we feel this is a sufficient technique for SC 2.4.1. ---------------------------------------------------------- Comment 13: F63: direct context or DOM context Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0205.html (Issue ID: 2051) ---------------------------- Original Comment: ---------------------------- I disagree with this failure because link can't be used out of context and there is always a DOM context, it's an AT missing feature to have an easy way to read full parent element, next sibling or preview sibling. For your example : <div> <p>A British businessman has racked up 2 million flyer miles and plans to travel on the world's first commercial tourism flights to space.</p> <p><a href="ff.html">Read More...</a></p> </div> the user must be able to read the brothers element of the a element (in this case empty), or read the brothers element of his parent element (in this case the content of the previous p element, or read the content of his grandfather (in this case the whole div element) In definition list, dd go whis dt so if i read an a element in a dd i must be able to access to content of the previous dt element and brothers dd elements Furthermore, if there is a title attribute with a title longer than the content of the a element and explaining the purpose of the link, i think the test must passed. Make your choice, stay in the wcag 1.0 position and say the link must be understandable out of context or just say ok it's nearly impossible, so if you can't do it, use the title attribute to do so (or act that it impossible at all). --------------------------------------------- Response from Working Group: --------------------------------------------- It is true that there is always some context that explains the purpose of the link. Otherwise, no one would know what it meant, which would be a usability problem rather than an accessibility problem. However, a blind user must be able to find the relevant context in a supported way. It is not sufficient to expect the user to search the entire page for the relevant context, or start searching arbitrarily in the DOM "near" the link to find the important context. This is why the success criterion say that the context is programmatically determinable. ---------------------------------------------------------- Comment 14: F15: Invalid test procedure Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0211.html (Issue ID: 2054) ---------------------------- Original Comment: ---------------------------- F15: Failure of SC 4.1.2 due to implementing custom controls that do not use... Since, the AT have different support of non html technology like java and flash i can\'t use it to test this and sometimes i can\'t have access to source code or have the commercial product to open that code. Not everybody as a PC with Jaws 8 and Flash installed on it. So, the result of this test is not Yes or No but more "Maybe in some case it's accessible and maybe in some others it's not" --------------------------------------------- Response from Working Group: --------------------------------------------- Content like Flash can be evaluated without having the source code. There are tools which are available (usually free) from the company that created the API(e.g. Microsoft) that will allow you to check the way the content has implemented the API to see if it is implemented completely and properly by the content. Flash can also be evaluated using the Flash authoring tool. Testing with screen readers is also good but as you say not everyone has one. There are services such as Narrator in Windows and Voiceover for Macintosh however that are free and will also voice things that implement the Microsoft or Apple APIs. ---------------------------------------------------------- Comment 15: SC 3.3.3: more ergonomic problem than accessibility problem Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0214.html (Issue ID: 2056) ---------------------------- Original Comment: ---------------------------- i think that this success criterion is more an ergonomic problem than accessibility problem, everybody can do mistake and everybody need to have a way to correct it. I am not sure that people with disability have more trouble than others people so i think a AAA level is better --------------------------------------------- Response from Working Group: --------------------------------------------- While it is true that everyone can make mistakes, users with disabilities may be more likely to make mistakes and may have a more difficult time recovering from mistakes, as discussed in Understanding SC 3.3.3. This Level AA success criterion is a more restricted version of the Level AAA success criterion 3.3.6; it applies only to actions where an error has particularly serious consequences. For this reason, the working group feels that Level AA is appropriate. ---------------------------------------------------------- Comment 16: common failure and Sufficient Techniques matching Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0215.html (Issue ID: 2057) ---------------------------- Original Comment: ---------------------------- there is numbers of case where the common failure did not match the Sufficient Techniques like in 2.2.1, 3.2.1 --------------------------------------------- Response from Working Group: --------------------------------------------- Common failures are situations that are known to fail the success criterion. We list them because they are examples of content found on the web that cause accessibility problems. By listing them as failures, we make clear that the failure behavior is violating the success criterion. The list of sufficient techniques does not include every way to pass the success criterion. So it is possible that there is not yet a matching sufficient technique for every failure. We welcome contributions of additional sufficient techniques that we could add to the Understanding WCAG document. ---------------------------------------------------------- Comment 17: 3.2 SC need more explanation and examples Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0216.html (Issue ID: 2058) ---------------------------- Original Comment: ---------------------------- I think this success criterion * Understanding Success Criterion 3.2.1 (On Focus) * Understanding Success Criterion 3.2.2 (On Input) * Understanding Success Criterion 3.2.5 (Change on Request) need a lot more example, technique, common failure and explanation to be clearly understand. Specially, what about ajax features like auto completion, on blur partial validation and other stuff like that? --------------------------------------------- Response from Working Group: --------------------------------------------- We agree that more examples, techniques, and explanation are always helpful. We would particularly welcome submissions of Ajax techniques and failures, using the Techniques for WCAG 2.0 submission form at http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/ . We are not sure what you are asking about auto completion and onblur partial validation without more details about their behavior. Auto completion does not cause a change in context. If onblur partial validation causes a change in context, it would violate SC 3.2.5. Depending on the details of the functionality, it may also violate SC 2.1.1. ---------------------------------------------------------- Comment 18: better but still dommageable concept Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0217.html (Issue ID: 2059) ---------------------------- Original Comment: ---------------------------- I think the concept of accessibility supported technologies is far better than the baseline concept in term of wording. It's much more understandable but there is still big problems with lake of definition of some element like : widely-distributed user agents and widely-distributed user plugins, purchase in a way that does not disadvantage people with disabilities (purchase disadvantage everybody, as far as i know AT vendor didn't not sell different version for disabled or not person, and if it's about cost disadvantage at what price it make it a disadvantage) There is question with no response like how many platform, AT, language need to support a technology to be concidered like accessible. One of the most problematic part is : Authors, companies or others may wish to create and use their own lists of accessibility-supported technologies. For me it's clearly means that for example Adobe can say Flash is an accessible technology because it's work when you use Flash 7 or more, IE and a PC and a "widely distributed" plugin. But what about Mac and Linux Users, what about jaws 6 and firefox users. At this time validate the fact, that only HTML (and maybe PDF) can be considered like an accessibility supported technology, other technology specially flash and javascript still need fallback alternative. Otherwise, we will see a lot off full flash website working just with ie claimed that they are accessible with a AAA level when majority of user haven't any access to content. It's to the WCAG working group to maintain a list of accessible technology and not only limited to W3C technology (since the working group is partially composed by employee of non standard technology company it must not be a problem) --------------------------------------------- Response from Working Group: --------------------------------------------- Companies may indeed want to use their own lists. If it is a good list there would not be a problem. If it is a bad list, it would be similar to a bad interpretation of the guidelines and would need to be controlled in the same way. WCAG does intend to work with others to help create a list. This could be then used by those not interested or capable of creating their own researched list. As for companies posting lists with their products on them with unrealistic appraisals, we would expect that this would not happen because of the feedback and comment it would likely generate on the Web and in the community. We do not have any requirements for platforms per se, but the documented list of accessibility support for a technology should note which platforms the technology has AT support on. This is described more in Documenting Accessibility Support for a Web Technology (http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20070910/appendixB.html).
Received on Sunday, 4 November 2007 04:10:03 UTC