W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 1998

objectives for guidelines + Needs / Uses

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>
Message-ID: <000b01bd92e7$295cf320$7b865c90@vanderheiden>


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 GMT

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