RE: [WCAG2] i18n comment: Provide simpler text

> -----Original Message-----
> From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] 
> Sent: 04 November 2007 05:09
...
> 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.  
...
> WCAG 2.0 Editor's Draft of May-October 2007 at 
> http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/
> 
...
> 
> ----------------------------------------------------------
> Comment 1: answering the unspoken questions of the reader quickly
> Source: 
> http://lists.w3.org/Archives/Public/public-comments-wcag20/200
7Jun/0008.html
> (Issue ID: 1959)
> ----------------------------
> Original Comment:
> ----------------------------
> 
> > 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.)
> 
 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------
 
 We have considerably shortened the introduction and tried to 
 address most of your questions directly.  We did not re-title 
 our section heads to be questions because this is a technical 
 standard. We do use
 that strategy in the WCAG FAQ to great effect.   We have moved
 "components of accessibility" out of the document except for a short
 statement and a couple links to more information.   We have tried to
 answer the key questions you highlight and provide links to 
 further discussions where the reader is interested.

Received on Friday, 16 November 2007 14:01:55 UTC