- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 22:10:30 -0700
- To: "Sandra Vassallo" <S.Vassallo@e-bility.com>
- Cc: public-comments-WCAG20@w3.org
Dear Sandra Vassallo, 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: Guideline does not mention the need for equivalent alternatives (only SC). Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0266.html (Issue ID: 2096) ---------------------------- Original Comment: ---------------------------- As stated by the Guideline, the primary benefit in providing text alternatives for any non-text content is that it can be changed into other forms people need such as large print, braille, speech, symbols or simpler language. However, unless the alternative conveys the same information it may be of little use. Courts and Government policy makers will most likely use the W3C normative guidelines as their benchmark for determinations of accessibility conformance and since the Success Criterion 1.1.1 (Non-text Content) already has as a checkpoint that "All non-text content has a text alternative that presents equivalent information ...", it would be beneficial and consistent to include equivalence in the actual Guideline. Proposed Change: Edit Guideline 1.1 to read "Provide equivalent text alternatives for any non-text content so that it can be changed into other forms people need such as large print, braille, speech, symbols or simpler language" --------------------------------------------- Response from Working Group: --------------------------------------------- We did have equivalent in there at one point. But not all of the text alternatives are equivalent. In some cases it is impossible for the text alternative to be equivalent. There are a number of text alternatives that label content. Thus, the guideline was changed to match this situation. The different points under SC 1.1.1 explain the different situations in which equivalent text alternatives are required vs when a label is deemed sufficient. ---------------------------------------------------------- Comment 2: Add definition of testability to Guidelines (Introduction & Glossary) Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0269.html (Issue ID: 2099) ---------------------------- Original Comment: ---------------------------- There needs to be a clear definition of testability in the Introduction and Glossary of the Guidelines so that it is understood that this refers to both machine and human testable measures. Testability is a core premise of the new WCAG 2.0, which I understand to embrace both machine and/or human testability, although this is not clearly documented in the normative guidelines. The human testable aspect of this definition is critical to certain guidelines being effectively implemented e.g. testing for equivalent text alternatives to non-text content. My concern is that many developers will see testability as a purely automated validation and when this is passed for presence of alt text it will be considered sufficient even if were not considered equivalent by human testers. Proposed Change: Include the definitions for testable (currently provided in the "Requirements for WCAG 2.0 Checklists and Techniques" document at www.w3.org/TR/2003/WD-wcag2-tech-req-20030207/#defs) in the normative Guidelines Glossary and mention in the Introduction that testability includes both machine and human testable criteria. This second point could be achieved by editing the second paragraph in the Introduction: "Rather than specifying what technologies to use, WCAG 2.0 lays out general guidelines for using technologies along with specific machine and human testable success criteria for guiding and evaluating the use of the technologies." --------------------------------------------- Response from Working Group: --------------------------------------------- We have added your language to the introduction. We have not defined testability since we are using it in the normal English language sense of the word. We do discuss its meaning however in the Conformance section of the guidelines. ---------------------------------------------------------- Comment 3: Skip links are not required to be visible (G1) Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0270.html (Issue ID: 2100) ---------------------------- Original Comment: ---------------------------- The techniques document currently includes appropriate rationale i.e. "visible links are necessary for those navigating with a keyboard including switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software". However the preceding sentence "when possible, a visible link is preferred over a hidden link" seems to contradict the importance of this. Proposed Change: Change "when possible ..." to read "skip links are required to be visible, not hidden, at least on keyboard focus." --------------------------------------------- Response from Working Group: --------------------------------------------- We have updated the sufficient techniques related to skip navigation links to include a requirement that the links either be always visible or visible when they have keyboard focus. We have also removed the sentence, "When possible, a visible link is preferred over a hidden link." ---------------------------------------------------------- Comment 4: Stronger statement about accessibility for people with cognitive disability Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0271.html (Issue ID: 2101) Status: VERIFIED ACCEPTED ---------------------------- Original Comment: ---------------------------- In their current form there are still some important areas of web accessibility for people with cognitive, language, and learning disability that are not covered by the WCAG 2.0 Guidelines and due to testability are unlikely to be accepted. With this in mind a stronger statement about the importance of web accessibility for this audience and the need for developers to consider issues affecting these users would be worthwhile. The first part of this issue has already been taken up in the recent draft, which states: "Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by WCAG 2.0, either directly or through assistive technologies, the WCAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area." (WCAG 2.0 Introduction) In addition a statement that encourages developers to follow current best practice for this group as part of meeting their accessibility obligations would help raise awareness and provide support for any companion documents/checklists that may be developed by authoritative agencies in the future. Proposed Change: Add the following recommendation to the end of the existing paragraph in the WCAG 2.0 Guidelines: "... There is a need for more research and development in this important area and developers should seek relevant expert advice about current best practice to ensure that web content is accessible, as far as possible, to this community." --------------------------------------------- Response from Working Group: --------------------------------------------- The Working Group hoped that the inclusion of the sentence "There is a need for more research and development in this important area." would encourage support in the research community for additional work in these areas. At the request of several reviewers, we have removed it. We added the sentence based on comments submitted: Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs. In context it reads: All of these layers of guidance (guidelines, success criteria, and sufficient and advisory techniques) work together to provide guidance on how to make content more accessible. Authors are encouraged to view and apply all layers that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users. Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs. ---------------------------------------------------------- Comment 5: Clarification on Conformance Requirements for Alternative Content Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0280.html (Issue ID: 2110) ---------------------------- Original Comment: ---------------------------- The option to accept an alternative accessible page has merit but is also a significant weakness and I am nervous that this may be used by some websites as a way to legitimately avoid any efforts involved in making the primary content accessible. The legacy of "text only" links as the accessibility solution to HTML 3.2 is only just being redressed and WCAG 2.0 seems to open the possibility for this to start all over again with a proliferation of "alternate" pages. This approach treats people with disability as a separate audience, rather than acknowledging them as part of the diversity in every audience (i.e. children with disability, job seekers with disability, seniors with disability, employer with disability). In its current form this requirement appears to make it acceptable for software developers to release and re-release versions of their product with no priority or time frame for including accessibility but to still be used on accessible websites and have the status of conforming to the level of the accessible alternate page. In a commercial world there are many competing demands for time and resources with the result that accessibility is often seen as a lower priority. Once it is acceptable for developers to publish alternate content pages then championing mainstream accessibility becomes harder, especially when this approach is endorsed by an international body with the standing of the W3C. As such, I suspect accessibility considerations will have less chance of competing with other important business requirements. Similarly, once alternate pages are published there is little incentive in the Guidelines for developers to make the main pages accessible in the future and in practice (unless they are drawn from single sourced content) alternate pages are infrequently, if ever, updated. For example, there is no requirement (I could see) to make the main web page accessible if it becomes possible to do this with the software at a later date or for people to make it accessible if it is possible but harder to implement using the software accessibility properties. Currently "If the Web page does not meet all of the success criteria for a specified level, then a mechanism to obtain an alternate version that meets all of the success criteria can be derived from the nonconforming content" is acceptable. Getting to the accessible content in an accessible way from an inaccessible page is also an unresolved issue at present (as documented in the WCAG 2.0 Editorial Note) and I'm wondering why the focus is not on universal design with progressive enhancement for inaccessible formats, starting with the accessible document as the main/default page. Note: I have not had time to fully explore all the WCAG 2.0 documentation in the time available for comments, so please let me know if this concern is already addressed. However, from my reading so far it seems to be rather a big issue that is not yet satisfactorily resolved – in that websites can claim conformance in principle while not conforming in spirit to the Guidelines. Proposed Change: This needs more thought than I've had time to give it at present, but possible changes might include: * a statement to the effect that if it is possible for the main content to be made accessible then an alternate page is not acceptable * making the most accessible page the main/default page with links to or progressive enhancement of inaccessible content --------------------------------------------- Response from Working Group: --------------------------------------------- We have added a note to say "Alternate versions may be provided to accommodate different technology environments or user groups. Each version should be as conformant as possible. One version must be fully conformant in order to meet conformance requirement 1." ---------------------------------------------------------- Comment 6: Text resizing - What Level Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0281.html (Issue ID: 2111) ---------------------------- Original Comment: ---------------------------- The ability to resize text can be critical to accessibility for people with print disabilities such as degenerative eye sight and reading/learning difficulty but this does not seem to be adequately covered in the Guidelines. 1. SC 1.4.4 Resize Text is a Level AA requirement (rather than Level A) 2. Text as an image appears to be acceptable, yet images are not resizable by many browsers and where image ‘zoom’ is a feature of the browser this can create other accessibility problems such as broken page formats, horizontal scroll bars and pixelation of the text/image. Turning images off to view the alt text is not a practical solution, since many people do not know how to do this and once set this preference applies to all images not just text images. It becomes increasingly difficult when text based images are used for navigation elements, such as an image map. 3. Resizing of text based form content and form controls also does not seem to be mentioned and textual content in non-text based form controls also needs to be resizable by the user. For example: using the browser resizing options in forms is problematic when the text resizes but not the radio button. Proposed Change: 1. Move SC 1.4.4 to Level A 2. Text as an image should not be acceptable unless Success Criterion are applied that would address the needs of people with print disability 3. Include Success Criterion for resizing of text based and non-text based form controls --------------------------------------------- Response from Working Group: --------------------------------------------- RE # 1. Move SC 1.4.4 to Level A This provision may not be implementable with some technologies directly but the same effect could be achieved with assistive technologies. Because of these factors the Working Group feels that his provision is better put at Level AA. The working group examined the issue of images of text carefully and felt that they should be allowed,. The group feels that the majority of images of text used on the web these day can be zoomed up to 200% and down to 50% without pixelation being a significant barrier. For zooming above that AT have smoothing algorithms. The group also feels that there are sufficient resources in the operating system and with external AT devices that contrast issues can be handled at level AA. However, we have made a note in the understanding document describing some of the problems with images of text such as contrast and pixelation, and we encourage text. And we have added a note to 1.4.3. For 1.4.3: Note: Images of text do not scale as well as text because they tend to pixelate. It is also harder to change foreground and background contrast and color combinations for images of text, which is necessary for some users. Therefore, we suggest using text wherever possible, and when not, consider supplying an image of higher resolution. For 1.4.4: Note: Images of text do not scale as well as text because they tend to pixelate, and therefore we suggest using text wherever possible. It is also harder to change foreground and background contrast and color combinations for images of text, which are necessary for some users. RE #3 Include Success Criterion for resizing of text based and non-text based form controls We think this should be a User Agent guideline, and just an advisory/repair technique in WCAG. If text is big enough to be useful, it will be so big that designers won't want to use it. If some elements scale and others don't, the layout is likely to get messed up. Whether that's a barrier or not depends on whether content or functionality is lost, but it's much eaiser to get this right when everything scales such as a user agent zoom, commercial AT, or operating system magnification. However we have added a sufficient technique for 1.4.4: "Specifying the size of objects in terms of the font size" By the time WCAG reaches recommendation, we expect Zoom features in browsers will become more and more used among people who need moderate amounts of zoom. We realize that this is not perfect, but we think it is the best compromise given the alternatives.
Received on Sunday, 4 November 2007 05:10:45 UTC