- From: eric hansen <ehansen@ets.org>
- Date: Thu, 11 Mar 1999 13:23:47 -0500 (EST)
- To: w3c-wai-gl@w3.org
Following is a revision of the Validation (Testing) section. It has a slimmer intro and adds a few methods. Appendix A: Validation {EH: Title changed from "Testing"} Validate accessibility with both automated and human methods. Automated methods are generally rapid and convenient but cannot identify all accessibility issues. Human evaluators can help ensure clarity of language and ease of navigation. Begin using validation methods at the earliest stages of development. Accessibility issues identified early are easier to correct and avoid. Following are some important validation methods. {EH: I think that this is more direct and to the point. OLD: "Validate pages and assess the accessibility with automated tools, manual tests, and other services."} {EH: Not necessary, older version: "Validate Web sites with various types of browsers, older versions of browsers, and services that emulate browsers. Testing a site with a variety of browsers and other services will provide firsthand experience of some of the issues people deal with."} {EH: Old sentence was not necessary: "Design adjustments based on the results of tests will increase the likelihood that a site will be usable by a wide range of people and technologies.} 1. Use an automated accessibility tool and browser validation tool. 2. Validate the HTML. {EH: Replace "all" with "the".} 3. Validate the CSS. {EH: Replace "all" with "the".} 4. Use a text-only browser or emulator. 5. Use multiple graphic browsers, with: · sounds and graphics loaded, · graphics not loaded, · sounds not loaded, · no mouse, · frames, scripts, style sheets, and applets not loaded 6. Use {EH: Deleted "a"} several browsers, old and new. 7. {EH: Deleted "It may also be helpful to test a site with"} Use a self-voicing browser, a screen reader, magnification software, a small display, etc. {EH: Changed} 8. Use spell and grammar checkers. A person reading a page with a speech synthesizer may not be able to decipher the synthesizer's best guess for a word with a spelling error. Eliminating grammar problems increases comprehension. {EH: Changed to add grammar checker, since it is often found with a spell checker.} 9. Edit for clarity and simplicity. {EH: or "Evaluate for clarity and simplicity"} A good human editor can help ensure clarity and simplicity of written content. An editor can also increase the usability of documents by identifying potential problems such as cultural and ethnic stereotyping or offensive language{EH: I think that it is fine to mention these usability issues.}.{EH: I think that the use of a good editor (or other human judge) is the best way of validating clarity and simplicity.} 10. Examine readability statistics. Readability statistics, such as those generated by some word processor programs {EH: e.g., MS Word}, may be useful indicators of clarity and simplicity. {EH: New and easily done.} 11. Involve people with disabilities as evaluators. Observe and obtain feedback from expert and novice users with disabilities. Evaluators with disabilities can identify accessibility and usability problems and rate their severity. Involving evaluators with disabilities will yield insights for improving the accessibility of Web designs.{EH: or delete "and usability"}{EH: I believe that the absence of this point would be a serious oversight.} ============================= Eric G. Hansen, Ph.D. Development Scientist Educational Testing Service ETS 12-R Rosedale Road Princeton, NJ 08541 (W) 609-734-5615 (Fax) 609-734-1090 E-mail: ehansen@ets.org
Received on Thursday, 11 March 1999 13:27:14 UTC