- From: Gregg Vanderheiden <po@trace.wisc.edu>
- Date: Mon, 8 Jun 1998 09:10:15 -0500
- To: "GL - WAI Guidelines WG (E-mail)" <w3c-wai-gl@w3.org>
Needs, Uses, and Objectives for the guidelines Part of the problem in trying to design these guidelines is that we are trying to meet several different types of needs or uses simultaneously. A listing of potential uses of the guidelines is provided first, followed by a draft listing of objectives for the guidelines. The objectives, of course, should reflect the needs or uses. -------------------------------- Needs/uses for the guidelines a). Awareness/instruction: Someone is interested in a short summary of what it takes to make a web site accessible, and why. b). Guidance in writing a page: Someone is creating a page and is interested in what they should do to make the page accessible. c). Page author legal compliance: A company has just received a contract to create a new web site, but has been told by the customer that it must be accessible. They got the contract on a low bid basis. They're interested in what the minimum amount is that they need to do in order to have a site that is classified as "accessible." The site is also supposed to be very dynamic, attractive, etc., so they want to be able to use all of the latest web techniques. d). Legacy site accessibility: A web master of a 10,000 page web site has been told by their boss that they need to make sure that the web site is accessible. This not only means new pages being written, but also the rest of the 10,000 page site, much of which is little used. e). As a rule set for testing tools: Several different groups and companies (Bobby, other HTML checkers, etc.) would like to create accessibility checkers or include accessibility checking as a part of their HTML checkers. They need to have a set of rules that can be coded into their checkers. f). Web page and web site evaluation tools: Bobby and other checker tools may want to give essentially a pass-fail grade, or an A/B/C grade to web sites automatically. This would require a set of guidelines that can be applied in a law or regulation-like fashion, with sites getting either a passing or failing grade based on compliance with the guidelines. g). Human web site evaluation and certification: This is the same as the automated evaluation. It involves a human being doing the testing, which relieves some problems, but still requires a set of guidelines that can be used to create objective judgements as to whether a site does or does not pass. Also, a set of criteria for deciding when a site does or doesn't pass, or should get various grades. h). Simple and complex guidelines People are interested in having both a simple set of guidelines that can be used by beginning coders, young children, etc., and also guidelines that cover all of the advanced techniques and technologies. ------------------------------ Objectives and requirements This is a draft list of objectives and/or requirements for the guidelines. The purpose of this list is to help define the target we are trying to create. To create a set of guidelines that: 1. Will help authors understand the underlying concepts for creating an accessible web page. 2. Provides specific guidance as to how to achieve the general objectives. 3. Can be used to ascertain whether a page is likely to be accessible to people with disabilities. 4. Is sufficiently defined that the GL, IG, and W3C can sign off and endorse it. 5. Is practical enough that web designers can and will use it. 6. Is flexible enough to allow web designers to create dynamic and interactive pages (i.e., not put them at a disadvantage compared to competing web designers who are not using the guidelines). 7. Can be used to help guide the design of web creation tools to facilitate more accessible pages. 8. Can be used by HTML and web checking tools to identify and highlight accessibility problems on a page. 9. Can be used by people generating web evaluation and rating tools to determine whether a site is accessible (or class A, B, C accessible). 10. Will foster the inclusion of mark-up in pages that is not useful today but which will foster more accessible pages in the future (e.g., longdesc, table mark-up, etc.). 11. Will encourage the design of pages are accessible today by users who have old browsers or screen readers. This is a draft listing of the objectives/requirements. Please suggest items that are missing from the list as well as possible notes or caveats to the items here.
Received on Monday, 8 June 1998 10:10:30 UTC