W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2002

Re: 3.3 action item

From: Wendy A Chisholm <wendy@w3.org>
Date: Fri, 18 Jan 2002 16:35:23 -0500
Message-Id: <5.1.0.14.2.20020118163026.023cd780@localhost>
To: Lisa Seeman <seeman@netvision.net.il>, w3c-wai-gl@w3.org, jomiller@bendingline.com
Lisa,

The National Cancer Institute has created a set of design guidelines based on research.  Each guideline lists the research that it is based on. 

One guideline that is related to checkpoint 3.3 is:
Write sentences with 20 or fewer words and paragraphs with fewer than five sentences. Use lists to break up long sentences.

These statements are easily testable. 

They provide a good example.
http://usability.gov/guidelines/content.html#two

Your statement is not as easily testable as what they have suggested.
> Use short sentences . Short sentences success criteria proposal: sentences
>contain no more
> than one relative clause at least for instructions.

just fyi,
--wendy

p.s. Jo, did you have anything to do with this site?

At 11:43 AM 1/18/02, you wrote:
>OK - Checkpoint 3.3 Write as clearly and simply as is appropriate for the
>content.
>
> I have split up previous work into four  categories.
>-Brake up the text,
>-chouse the right words
>-highlight
>-provide support.
>
>I think that the below are testable, even though you can probably fulfill
>all the test and provide an unintelligible page (if you put your mind to
>it). That is probably true to some extent in lots of Checkpoints.
>
>
>
>
>>
>
>1 BRAKE UP
>  Use a two-step "select and confirm" to reduce accidental selections,
> especially for critical functions.
>
>  Structure tasks, cue sequences, and provide step-by-step instructions.
>
>
>
>One idea per paragraph: Test: replace each paragraph with a one idea
> sentence. (the first sentence, or a rewrite of that) Does the document
>make
> sense still?
>
>
> first sentence must match the (single) idea expressed in a paragraph.
>(success as above)
>
>
> Use short sentences . Short sentences success criteria proposal: sentences
>contain no more
> than one relative clause at least for instructions.
>
>
> Instructions should be step by step, and include visual references. Success
>Criteria: could you represent the instruction as a drawing - flow chart dry
>run.
>
> It should be possible to choose the detailed or the shortened
>instructions
>
> Use markup to identify flow of instructions
>
>
>
>
>provide flow of ideas in a summary, diagram or page map
>Success Criteria: It is possible to map the document to pieces that
>are in the summary (exec summary, or heading outline, or ...)
>
>
>
>Automate complex sequences like system backup, application launch, and user
> registration.
>
>
>Avoid functions that require simultaneous actions to activate or operate.
>
>Use goal/action structure for menu prompts.
>
>
>
>
>2 choose  WORDS
>
>2.1 metaphorical language
>avoiding metaphorical language which may be understood literally by people
> with autism.  If you do use metaphor or irony or another style which may be
> misunderstood, consider adding an explanatory note
>
>success criterion: non-literal text is identified and a literal
> translation is identified
>test by translating to another language and re- translate. does it make
>sense?
> technique for 3: Use of Ruby.
>
> <p> The Prime minister is wanting to
> <ruby>
>   <rb>have his cake and eat it too</rb> <!-- the metaphorical
>expression -->
>   <rt class="http://wordnet.org/literally">get the benefit of seeming
> inflexible now, but be able to change
>       his mind again later</rt>
>    <!-- the rt element can be rendered alongside, or instead of, the rb
> content, according to the styling -->
> </ruby> in this instance.</p>
>
>2.2 meaningful words
>Use highly descriptive words as hypertext anchors. Avoid the "click here" s
> syndrome.
>
>Headings should be unique, and meaningful on their own ( related to the
>requirement that links should make sense
>on their own)
>
> Jargon that is expected should be linked to a glossary / explanation
>
> Use the jargon. This has to be linked to (depends on) 5: and should be
> linked to 4:
>
> I would add that I do not think it ok to restrict translations of jargon
>and
> annotations of abbreviations to the fist occurrence. I can not remember
> annotations that I have used since high school, and am still dependent on
> the spell checker for ect/etc ....(etc....)
>
> Linking to a glossary is not as cool as providing the information in a
> ruby so it can be shown/hidden fast.
>
>( Technique: Use Ruby Technique: Use a rel="glossary" link.)
>
> It should be possible to identify a graphic representation of an
> instruction. i.e. you can draw the picture.
>
> CMN thinks that 10: is also useful for being able to translate to sign
>language.
>
>
> Use active rather than passive expressions - this doesn't have massive
> support.
>
>
>
>2.3 Easily understood words
>Use short words in common vocabulary.
> Success criterion: Substituting 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.
>
>
>  Provide concrete rather than abstract indicators. Use absolute reference
> controls rather than relative ones.
>
>Grammar-based success criteria are language dependent
>
>3 HIGHLIGHT
>
>Highlight key information  Success criterion:  when the highlighted text
>stands alone does it summarize the key ideas.
>
>provide easily scanable layout such as bullets for multiple points. Success
>criterion:  can comas be replaced by bullet points? can paragraph marks be
>replaces by bullet points?
>
>use goal/action structure for menu prompts,
>
>
>4 AND provide support and help
>
>Support "wizards" which offer help, simplify configuration, and assist with
> sequences.
>
>  Provide defaults and make it easy to re-establish them.
>
> Provide calculation assistance, or reduce the need to calculate.Success
> criteria
>
>  Provide definite feedback cues: visual, audio, and/or tactile
>
> provide a mode with minimum functionality. - Eliminate or hide what isn't
> essential.
>
>
>Use prompts for procedures and support decision making.
>
> Provide for consistent formatting that doesn't put people off.
>
>pictorial representation should be provided of each instruction, (if
>you
> can not do it in one picture, it is time to split up the instructions)
>
> diagrammatic representation should be provided for relationships and
>flow
> of ideas.
> Supply a page map/ structural diagrams of the flow of concepts through a
> document.
>
> for long documents the subject could be shown at the center, with the
> various ideas
>radiating outwards. Branches and sub-branches indicate the hierarchical
> relationships between ideas, and visual cues are used to associate ideas
>with easily recalled symbols
>
>
> success criteria: can you map all the ideas in the document to the page
>map?

-- 
wendy a chisholm
world wide web consortium 
web accessibility initiative
seattle, wa usa
/--
Received on Friday, 18 January 2002 16:33:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:18 GMT