Re: [WCAG2] i18n comment: Provide simpler text

> Comment 1:
> 
> Source: http://www.w3.org/mid/20060627170742.9C4774F144@homer.w3.org
> (Issue ID: LC-1370)
> 
> 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.
> 
> ----------------------------
> Response from Working Group:
> ----------------------------
> 
> 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.

This comment from Richard Ishida has been approved during an i18n Core WG telecon.

This does seem a lot better. Thank you.  

There is something important missing for me - a focus on answering the unspoken questions of the reader quickly at the top of the page.

I think there should be a section entitled "Who should read this?". It should be the first subsection in the introduction.  It should use short sentences to say something about who reads what for what purpose.

I also think much of the difficulty in getting WCAG accepted by content authors is that they come to the document with the wrong expectations, and could do with some additional signposting.

The WCAG guidelines are used to (a) set general targets for design, and (b) to evaluate conformance to accessibility needs.  Most content authors, however, will typically be asking themselves "How do I find out what do I need to do, right now, to make this accessible?".  The more useful document in that case is a well-indexed *techniques document*.  The guidelines are so abstract and high level that content authors will struggle to use them for that purpose.

I think the introduction should describe that *very clearly*, and in terms of the questions the *reader will be asking themselves*.  For example, the headings "WCAG 2.0 Supporting Documents", and "Organization of the WCAG 2.0 Document" sound to me like descriptive titles, written from the point of view of the author of the document (it answers the question "How can I describe how this all hangs together?"). It doesn't grab me - it sounds like a chore to read that stuff. The intended reader, on the other hand, will be asking themselves "Who is this for (do I need to read it)? What do I need to read, and where do I start? If this is for me, how do I use this stuff?".

Structuring the introduction around questions like those will, I believe, help a great deal.

I also think you should move the section "Components of Web Accessibility" lower down the introduction. It isn't vital to know that stuff at such an early point, and it gets in the way of answering the more burning questions in the mind of the reader.

I would also shorten and rearrange the first few paragraphs of the introduction.  I think it should be replaced with a short paragraph describing what this document is for.  Much of the current content is detail that can be addressed after addressing the reader's burning questions (Do I need to read this? What do I need to read?) under a title such as 'Scope'.

(Note also that I feel that the quick reference doc is not much better for content authors wanting to know what to do. I think that they will find it easier to use material organized by task, rather than by abstract groupings.)


============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)
 
http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/

Received on Wednesday, 6 June 2007 08:58:34 UTC