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

Revision of Validation (Testing) Section

From: eric hansen <ehansen@ets.org>
Date: Thu, 11 Mar 1999 13:23:47 -0500 (EST)
To: w3c-wai-gl@w3.org
Message-id: <vines.yRv7+ml+uqA@cips06.ets.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 GMT

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