- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Mon, 13 Aug 2001 00:12:05 -0500
- To: "GLWAI Guidelines WG \(GL - WAI Guidelines WG\)" <w3c-wai-gl@w3.org>
I would like to float something to the list. While going through the guidelines in grammar and cleaning it up I discovered that with 4.3 we had requirements in the benefits section and not all the criteria are criteria. For example the benefits section reads Benefits Ensure that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc. When an embedded object has its "own interface", the interface -- like the interface to the browser itself -- must be accessible. If the interface of the embedded object cannot be made accessible, an alternative accessible solution must be provided These are not benefits, but requirements. And the Success criteria reads Success criteria You will have successfully designed an assistive-technology compatible user interface if you: 1- use accessibility conventions of the markup or programming language you are using (API's or specific markup), 2- have tested the interface using a variety of assistive technologies and preferably real people with disabilities who use assistive technologies to determine that assistive technologies can access all information on the page or hidden within the page, 3- design an application that runs within a browser that conforms to the User Agent Accessibility Guidelines. Criteria # 1 and 3 are good. while #2 is a good thing to do, it is not required in order to conform. In addition it is not practical for most web designers. Very few people have or can afford to have the variety of assistive technologies that would be required to do this meaningfully. It is good for large professional shops but should not be required for all. I suggest that this requirement be moved down to discussion and rewritten as "For large professionally developed sites, it is good to have the site tested using a variety of assistive technologies, and preferably real people with disabilities who use assistive technologies, to determine that assistive technologies can access all information on the page or hidden within the page"s and the requirements in the benefits section should be moved up. This would give us a 4.3 that looks like ---------------- Checkpoint 4.3 Design user interfaces compatible with assistive technology Success criteria You will have successfully designed an assistive-technology compatible user interface if you: 1- have used accessibility conventions of the markup or programming language you are using (API's or specific markup), 2- have designed an application that runs within a browser that conforms to the User Agent Accessibility Guidelines. 3- have provided device-independent access to functionality 4- if an embedded object has its "own interface", the interface follows UAAG 1.0. If the interface of the embedded object cannot be made accessible, an alternative accessible solution must be provided Note: (informative) It is very helpful to test interfaces using a variety of assistive technologies and preferably real people with disabilities who use assistive technologies to determine that assistive technologies can access all information on the page or hidden within the page. { there is not BENEFITS section to 4.3 after the edit.} ------------------------ Comments? This is the only checkpoint that really seems all scrambled and we didn't clear up in discussions. -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Human Factors Dept of Ind. Engr. - U of Wis. Director - Trace R & D Center Gv@trace.wisc.edu <mailto:Gv@trace.wisc.edu>, <http://trace.wisc.edu/> FAX 608/262-8848 For a list of our listserves send “lists” to listproc@trace.wisc.edu <mailto:listproc@trace.wisc.edu>
Received on Monday, 13 August 2001 01:19:41 UTC