- 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 form). 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. Gregg 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. Vocabulary 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.] Sentences 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. Syntax 9. Using the simplest sentence forms consistent with the purpose of the content ***** * 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 written. 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. Verbs Voice 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. Examples: * 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. Tenses 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 this] . 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/> http://www.utexas.edu/research/accessibility/
Received on Wednesday, 25 February 2004 09:52:13 UTC