- 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