Checkpoint 3.3

I have been asked to bring the recent draft of Checkpoint 3.3 
(included at the end of this message) more into line with the format 
used in the rest of WCAG 2.0 [1]. I have been doing a lot of thinking 
about 3.3 in recent weeks, and in this message I will attempt to lay 
out some of those thoughts (coherently, I hope) for discussion by the 
group.

Checkpoint 3.3 has potential overlaps with a number of other 
checkpoints, most notably:

Checkpoint 3.1: Use consistent presentation.
Checkpoint 3.2: Emphasize structure through presentation, 
positioning, and labels.
Checkpoint 1.5: Separate content and structure from presentation.
Checkpoint 3.4: Supplement text with non-text content.
Checkpoint 3.5: Annotate complex, abbreviated, or unfamiliar 
information with summaries and definitions.

To begin, we can remove from the 3.3 draft some of the advice that 
more logically belongs under one of these other checkpoints. Doing so 
will allow us to focus on one thing in 3.3: clear writing.

Thus for purposes of this checkpoint we can set aside issues that are 
explicitly covered elsewhere, such as graphical illustrations (3.4), 
annotations and definitions (3.5), and much of the advice about 
document layout and presentation (1.5, 3.1, 3.2).

I also agree with Loretta and Lisa that support for decision-making 
and task-completion (including forms) merits its own checkpoint. Such 
a checkpoint might belong under Guideline 2 rather than 3.

Checkpoints in the working draft of WCAG 2.0 are presented with the 
following components:

1. Success criteria
2. where necessary, Definitions of terms that appear in the 
Checkpoint (informative)
3. Benefits (informative)
4. Examples (informative)

Definitions in WCAG 2.0 provide explanations of specialized terms 
used in the checkpoint itself, and not all checkpoints are 
accompanied by definitions. Looking at 3.3, I do not see any terms 
that require definitions, with the possible exception of "content" 
(Charles, do you think that a definition should be provided for 
"content"?).

As we discussed as a recent telecon, many of the items included in 
the 3.3 draft as definitions actually look more like success 
criteria. I will attempt to pull these items out for consideration as 
success criteria, unless they are already covered in other 
checkpoints.

The Benefits section of 3.3 has not been updated since the working 
draft of 24 August 2001. We will need to revisit it. Among other 
things, I would like to capture the benefits for people who use 
alternate modes of browsing (such as listening with a screen reader, 
reading a braille printout). It would also be good if we could 
provide more detail in the Benefits section about the ways in which 
cognitive, learning, and reading disabilities can affect how people 
process written text. Some of the expert material posted to the list 
in recent weeks will help us add specificity to the Benefits.

The Examples have been discussed somewhat but remain to be written. 
The Examples section is where we typically discuss the application of 
a checkpoint to different kinds of content. For instance, 3.2 offers 
examples for "documentation for a product" and "a data table." Once 
we have given more thought to the different categories of written 
content, we will be better able to select the most useful examples.

Of course, the variety of written content is almost infinite, but 
let's start by dividing "written content" into two categories:

1. First, we have content that cannot be altered by the web author.
This category includes such things as works of literature, 
proceedings of the Hague tribunal, the budget plan for the Ministry 
of Health, or anything that exists in published form elsewhere and 
cannot be amended or tampered with. In these cases, the web author 
would not be obliged to rewrite the content (she can't). Rather, she 
would need to annotate and supplement the content in a way that 
facilitates comprehension. Techniques she could use include 
summaries, outlines, links to dictionaries or specialized glossaries 
(internal or external), explanations of non-literal language, proper 
markup of all structural divisions within the existing material, and 
all manner of talmudic marginalia, depending on how much explanation 
the content requires and how far the web author is willing to go.

2. Then we have content that is being created (or re-created) 
specifically for the web.
Most commercial sites would fall into this category, as would an 
increasing amount of material from governments, educational 
institutions, individuals, etc. Here we can ask the web authors to 
follow the editing and web-writing advice that they are not free to 
apply to content that cannot be rewritten: break up long sentences 
and long paragraphs, make sure each paragraph contains a single idea 
expressed in the topic sentence, choose words that are commonly 
understood, etc.

This second category can be further subdivided, and for our present 
purposes I think the most significant sub-set of Category 2 is 
step-by-step instructions. Instructions are such a specialized form 
of writing, and there are so many techniques that apply specifically 
and solely to instructions, that I wonder whether we should pull them 
out and give them a checkpoint of their own rather than trying to 
encompass them in the success criteria and examples for 3.3. A 
separate checkpoint devoted to instructions might allow us to treat 
them more fully, and might also be appreciated by web authors who are 
trying to create accessible instructions. And I'm not sure, but it 
might also help us as we tackle the success criteria and examples for 
3.4, since effective illustration of instructions is one of the 
things we've been trying to address in that checkpoint.

Does anyone have thoughts on the matters discussed above?

Next, I have been attempting to pull out of the current 3.3 draft 
anything that looks like a success criterion, restate it as clearly 
as I could without changing the meaning, assess its testability, and 
comment on its appropriateness/usefulness as a success criterion. 
Some general comments:

As we've been working on success criteria for the checkpoints in 
Guideline 3, we continue to run into a vexing problem: some criteria 
are testable but not particularly useful or sufficient, and others 
contain supremely sound advice but are, alas and damn it, not 
objectively testable. Again and again we have circled 'round to this 
fact: we have a wealth of good advice that needs to be published, if 
not in the criteria, then somewhere equally prominent where people 
will find and use it. We do not want to throw this advice out or bury 
it in techniques documents simply because it does not meet our 
standards for objective testability.

3.3 is certainly a case in point. Some of our useful success criteria 
are indeed testable. However, many are not. We are going to wind up 
with several sound principles regarding word choice, editing, 
brevity, information-chunking, and usability that defy our attempts 
to cast them as testable success criteria. In fact, I think we will 
need to decide just how far we wish to pursue the subject of web 
writing. (The question of how far the Web Content Accessibility 
Working Group should stray into the area of general usability 
continues to come up).

If we do wish to create more supplemental materials to help authors 
write clearly and edit their writing for the web, we have a wealth of 
resources upon which to draw. Richard Lanham's _Revising Prose_ is 
one good source. So are the style guides for newspapers, which (in 
the USA, at least), have to aim at a sixth- or seventh-grade reading 
level. Lee has collected additional research. And of course the 
burgeoning field of usability studies offers much that we can use, if 
we want to.

I will address the 3.3 success criteria individually in a subsequent 
message, as this one is getting extremely long.

Final note: recently there has been further list discussion of 
interface design issues, particularly as they affect people with 
cognitive disabilities. Perhaps in a future telecon (or on the list) 
we can start to talk about where the various pieces of 
interface-design advice can best be incorporated into the Guidelines. 
Clearly, not all of them belong under 3.3.


[1] http://www.w3.org/TR/2001/WD-WCAG20-20010824/

--
Jo Miller


>Checkpoint 3.3 Write as clearly and simply as is appropriate for the content.
>
>
>
>
>
>Definitions (informative)
>
>
>
>Clear and simple writing requires planning and work on the level of 
>the document each sentence and individual words. Clear and simple 
>text has been broken up beyond the level requirements by good 
>markup.
>
>A clear document has a structured flow of ideas.
>  A clear document provides the flow of ideas summarized in a 
>summary, diagram or page map  to help the user orientate themselves 
>within the document.
>A clear document specifically states each step within the flow of 
>ideas and does not leave stages inferred or implied.
>A clear document has an easily scanable layout with key information 
>highlighted through presentation and positioning.
>  A clear document contains tools to aid comprehension including:
>
>Illustrations:illustrations of instructions, illustrations of flow 
>of concepts,
>Support of decision making:  Provide forms element examples. Provide 
>calculation assistance. Provide prompts for procedures, cues. 
>Support "wizards" which offer help, simplify configuration, and 
>assist with sequences. Structured tasks, cued sequences, and 
>step-by-step instructions.
>Reduction of decision making: Automated complex sequences like user 
>registration. Reduce the need to calculate Providing forms element 
>defaults  and make it easy to re-establish them.
>
>Note: Loretta suggests moving this whole "provide additional support 
>" part to an extra checkpoint. I think that that may be wise.
>
>A clear paragraph expresses a single idea that can be summarized by 
>its first sentence.
>A clear paragraph has an easily scanable layout with key information 
>highlighted through presentation, markup and positioning.
>A clear sentence contains a single point.
>A clear sentence is as short as can be used to expressed a single point.
>  A clear instructions focuses on concrete rather than abstract 
>indicators using absolute reference controls rather than relative 
>ones.
>
>Simple word are words that easily understood. This means that words 
>should be of short and of common usage.
>Use of jargon may be simple, were as the long term may complicate 
>the sentence (eg: ROM or read only memory) however translations of 
>jargon should be provided with each instance.
>Clear words can not be misinterpreted by someone who is unfamiliar 
>with the language or can not process metaphorical sarcastic or non 
>literal use of language. Such unclear use of language should be 
>marked as such.
>Clear words are meaningful and specific.
>
>It is sufficient to provide a  mode with minimum and clear 
>functionality that eliminates or hides what isn't necessary for 
>completing the site's goals.
>
>
>
>Success criteria
>
>
>
>Document:
>Provide overview
>For flow: look at overview ( summary, diagram, heading outline or 
>page map)- It is possible to map the document to pieces that are in 
>the summary
>Highlight key information  using markup ( eg headings and emphasis) 
>-  when the highlighted text
>stands alone does it summarize the key ideas.
>
>Paragraphs:
>Short paragraphs - Paragraphs should have with fewer than five 
>sentences . Use lists to break up long paragraphs.
>can sentences be replaces by bullet points? If so markup sentence as a list
>First sentence summarizes the point of each subsequent sentence - 
>does each sentence in the paragraph directly relate to the first 
>sentence?
>one idea per sentence- Test: replace each paragraph with a one idea 
>sentence. Does the document
>STILL make sense?
>
>Sentence:
>     -All:
>  Use short sentences - Write sentences with 20 or fewer words and .
>  Use lists to break up long sentences -can comas be replaced by 
>bullet points? if so markup sentence as a list
>Sentence   -Headings
>Should be meaningful out of context
>Headings should be unique
>    
>Sentence - Instructional
>It should be possible to identify a graphic representation of an
>  instruction. I.e. you can draw the picture.
>Each step is clearly stated. You could you represent the flow  chart 
>and successfully perform a dry
>run.
>Pictorial representation should be provided of each instruction
>Use active rather than passive expressions
>Sentences contain no more than one relative clause
>Use goal/action structure for menu prompts.
>
>Words:
>Non-literal text is identified and a literal translation is identified -
>test by literal translating to another language and re- literal 
>translating back. Does it make
>sense?
>Jargon that is expected should be linked to a glossary / explanation.
>Use simple words: Substitute common words for uncommon words
>(without significantly expanding the size) does not change the meaning. Note
>that this requires a dictionary that marks the "difficulty" of a word.
>
>Words - anchors (links)
>hypertext anchors should be meaningful out of context
>
>Forms
>All form elements should have a default or example provided
>calculations should be performed automatically (eg severside)
>Provide definite feedback cues
Use a two-step "select and confirm" to reduce accidental selections. 
(IE nothing happens when an option is selected until a confirm/go/OK 
button is clicked)

Received on Thursday, 28 February 2002 12:16:21 UTC