Edit comment LC-1370 for Accessibility Guidelines Working Group

Quick access to

Previous: LC-850 Next: LC-644

Comment LC-1370: Comment Shortname:; Commenter: Richard Ishida <ishida@w3.org> on behalf of I18N WG; 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:
Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-WCAG20-20060427/

Comment 1
At http://www.w3.org/International/reviews/0606-wcag2/
Editorial/substantive: E
Owner: RI

Location in reviewed document:
Introduction

Comment:
The content of the introduction is long and written in a legalistic style that is hard to get through. I think this can putoff, or at least scare, web designers and content authors.

I suggest that you provide short summaries of each major section, written in a friendly style, so that people can get thegist of the section. That way the complex normative text can remain, but does not have to be read in detail until needed.

Also, use more active phrasing. For example, "The set of technologies that an author assumes are supported and turned on inaccessible user agents is called a baseline." could be written "A baseline is what we call the set of technologies that an author assumes aresupported and turned on in accessible user agents." This is easier to read, makes it easier to find the definition of 'baseline', and gives a quickeridea of the content of the paragraph for those who are skimming text.; Related issues: (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; Resolution: We have reworked the entire document to make it shorter and easier to read and understand with different levels of expertise. This includes 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. We can't always use active phrasing but we have tried to use it wherever we could - much more than in last draft (though success criteria need to be in a true/false format) We have summary information at the front, and each guideline and SC has a link to more explanatory info. See if this version isn't easier to use and understand.; (Please make sure the resolution is adapted for public consumption)