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

John Slatin's Rework of 3.1 list of strategies for reducing complexity etc. Appendix E

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Wed, 25 Feb 2004 08:52:02 -0600
To: w3c-wai-gl@w3.org
Message-id: <0HTN0038KAMXI9@smtp5.doit.wisc.edu>


I asked John Slatin if he could rework Appendix E to get them into the
proper form. (they were in guideline imperative form, rather than strategy


He is working on 3.2 (was 3.4) so he took a quick pass at them so we could
review on Thursday and give guidance.  Looks pretty good.   But give them a
look over.   John didn't fix any broken ones - just change the form to the
right form,  -   and add notes where he thought of them. 






Strategies for reducing complexity include, but are not limited to:

In general


1.	Organizing material so it is easy to read and use.
2.	Using a style manual, dictionary, and other reference materials.
3.	Testing documents to learn if potential users understand the
material, and including people with cognitive, learning, or reading
disabilities in the test group.


4.	Using vocabulary that is likely to be familiar to intended readers. 

*        If the resource is intended for people who work in a particular
technical field, consider using a Controlled Language. For example, a
resource designed for aircraft engineers could use a controlled language
like the one used by Boeing Aircraft Company.

*        If a technical resource is intended for translation into other
languages, consider using a Controlled Language.

*        Avoiding professional jargon, slang, and other terms with a
specialized meaning that may not be clear to people outside a specific group
when resources are intended for a general audience or for translation into
other languages,. It may also be helpful to review the document for plain
language, using a checklist like the ones produced by US and Canadian
government agencies. [js note: We should include examples from other
countries and other languages if possible]


5.	Defining words with specialized meanings if it is necessary to use
such terms in resources intended for a general audience. [JS note 2/24: may
be covered now under previous success criteria]
6.	When there is a choice between abstract and concrete terms, using
the more concrete term unless there is a specific reason for using the
abstract term. [js 2/24: we may need to cut this one]   
7.	Avoiding ambiguity unless it is an essential aspect of the
subject-matter.[js 2.24 This may also be covered under success criteria
requiring links/markup to dictionaries,e tc.]


8.	Making sentence-length consistent with common practice in the
language of the document or the primary audience for whom the document is
intended. Textbooks about writing in that field or related disciplines may
be useful when such textbooks are available.


9.	Using the simplest sentence forms consistent with the purpose of the

***** *        For example, the simplest sentence-form for English consists
of Subject-Verb-Object, as in John hit the ball or The Web site conforms to
WCAG 2.0. 

10.	Using bulleted or numbered lists instead of paragraphs that contain
long series of words or phrases separated by commas

Nouns, noun-phrases, and pronouns

11.	Using single nouns or short noun-phrases.
12.	Making clear pronoun references and references to earlier points in
the document 

. example of potential ambiguity:  
The sentence below contains several pronouns whose references are not clear:


"Web developers can't understand those guidelines because they don't speak
their language."


1.      It is not clear which guidelines are referred to as "those
guidelines" (the guidelines you are reading now would be these guidelines)

2.      It isn't clear whether the pronoun "they" refers to the Web
developers or to the guidelines (the rules of English syntax indicate that
the reference is to the guidelines, but common usage doesn't always obey
those rules)

3.      It isn't clear whether the pronoun "their" refers to the language
used by the Web developers or the language in which the guidelines are

The sentence can be rewritten to resolve the ambiguities:


" Web developers can't understand these guidelines because the guidelines
are not written in the developers' language.



13.	Using the active voice for documents written in English and some
other Western languages, unless there is a specific reason for using passive
constructions.  Sentences in the active voice are often shorter and easier
to understand than those in the passive voice.



*        Active: Many people believe that readers understand sentences in
the active voice more easily than sentences in the passive voice.

*        Passive: It is believed by many that sentences in the active voice
are more easily understood by readers than sentences in the passive voice.


14.	Using verb tenses consistently.

For example, do not switch randomly between past and present tense.  In the
sentences, John left the room.  He takes the elevator down to the lobby, the
shift from past tense (in the first sentence left the room) to present tense
in the second sentence (takes the elevator) might create ambiguity about
John's use of the elevator: did he use it in the past or is he using it now?

Logic and relationships

15.	Indicating logical relationships between phrases, sentences,
paragraphs, or sections of the text.

. In some cases, simple words such as and, however, furthermore, and
therefore may be enough to make the logical relationship clear between one
sentence and the next. Other cases may require longer phrases or even
additional sentences.

Instructions and operable content

[js note:I suggest moving the items under this heading to Guideline 2.5
(help users avoid mistakes and make it easy to correct them]

16.	 Thoroughly explaining instructions or required actions
17.	 Using names and labels consistently.
18.	 clarity where the document: [js note: I don't quite understand

. addresses users

. explains choices and options

. labels options to get more information

. instructs users how to modify selections in critical functions (such as
how to delete an item from a shopping cart)

19.	 application of: [js note: Not sure what the items below should be
applied to]

. Use a goal-action structure for menu prompts.

. default settings (and the ease in re-establishing them) [js note: I'm not
sure what's intended here so can't rewrite]

. Using two-step, "select and confirm" processes to reduce accidental
selections for critical functions 

. Providing calculation assistance to reduce the need to calculate (for
example, use a script to calculate the total price for an online purchase)

Alternative representations: summaries, paraphrases, examples,
illustrations, and symbolic languages

20.	Providing summaries to aid understanding 
21.	adding non-text content to the site for key pages or sections
specifically to make the site more understandable by users who cannot
understand the text only version of the site. [delete- covered] [js note:
WCAG 1.0 and Section 508 both allow text-only variants only in cases when
the "original" can't be made accessible any other way, and then require that
the text-only variant be updated whenver the "original" changes.  That seems
to have dropped out of WCAG 2.0, but I think we need to reinstate it.]


22.	Making it possible to convert text into symbolic languages such as
those used by Augmentative and Alternative Communication (AAC) devices. [js
note: say how-through metadata? And we need an example for this one, under
examples. Clearly a Level 3]     




"Good design is accessible design." 
Please note our new name and URL!
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web  <http://www.utexas.edu/research/accessibility/>

Received on Wednesday, 25 February 2004 09:52:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:55 UTC