Edit comment LC-754 for Accessibility Guidelines Working Group

Quick access to

Previous: LC-474 Next: LC-1309

Comment LC-754: Comment Shortname:; Commenter: Jeremy Walker <jeremy@on-sitemanager.com> on behalf of Developer; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

This document in its current form is an embarrasment to the W3C, and is a step backwards from the previous version. If made official, it will set back years of work by accessibility-focused web developers. Futhermore, by releasing this horrible standard you will hurt the prestige of the W3C as a standards organization; I for one will put significantly less stock in any body that produces works as flawed as this one. Please re-consider your plans to officially deploy this document, and send it back for some serious re-working.

Proposed Change:

There is so much wrong I don\'t even know where to begin ... Please see the excellent article by Joe Clark on A List Apart for more details:
http://www.alistapart.com/articles/tohellwithwcag2/; Related issues: 735
(space separated ids); WG Notes: [EDITORZ] Discussed in the 26 April 2007 telecon: Resolution: Accept 582, 590, 644, 664, 689, 884, 1010, 1330, 735, 754 , 843, 651, 658, 1007, 1312, 1370, 857 as proposed http://www.w3.org/WAI/GL/2007/04/26-wai-wcag-minutes.html Same as LC-735; Resolution: We received a great deal of input on the last call draft and have made a large number of changes including a rewrite of much of the draft to make it easier to understand. We have also included a new quick reference document that provides a tool for practitioners who just want the bottom line on the requirements and the techniques for meeting them in different technologies. We also shortened the Guidelines document considerably. Here are some of the things we have done. Easier language to understand - Wrote simpler guidelines - Removed as many technical terms (jargon) as possible replacing them with plainer language or, where possible, their definitions - Eliminated several new or unfamiliar terms. (authored unit, etc.) - Removed the term Baseline and replaced it with â€œweb technologies that are accessibility supportedâ€? and then defined what it means to be accessibility supported. - Removed the nesting of definitions where we could (i.e. definitions that pointed to other definitions) - Tried to word things in manners that are more understandable to different levels of Web expertise - Added short names/handles on each success criterion to make them easier to find and compare etc. - Simplified the conformance Shortening the document overall - Shortened the introduction - Moved much of the discussion out of the guidelines and put it in the Understanding WCAG 2.0 document - Shortened the conformance section and moved it after the guidelines - Moved mapping from WCAG 1 to a separate support document (so it can be updated more easily) Creating a Quick Practitioner-oriented Summary / Checklist-like document - Created a Quick Reference document that has just the Guidelines, success criteria and the techniques for meeting the success criteria. Joe Clark also submitted his article as a comment. You may also want to review the working group's responses to that comment.; (Please make sure the resolution is adapted for public consumption)