Re: objectives for guidelines + Needs / Uses

Some thoughts on revamping the page author guidelines:

At the end of the day I believe it is still important to end up with _one_
page author guidelines if at all possible -- even if the page author
guidelines has multiple sections, such as the guidelines and checklist
sections that are in the current page author guidelines.  The sections
could include in their headers brief pointers back to the main document so
that they do not lose context if used as stand-alone pieces. Page authoring
is already part of a larger WAI guidelines set, that includes user agent
guidelines and authoring tool guidelines as well.

I would tend to collapse many of the needs/uses listed in Gregg & Wendy's
original message.  A few can be handled by related activities under the
Education and Outreach Working Group (EOWG) and some of the work falls
under Evaluation & Repair tools groups which will be opened shortly.

Because several areas of WAI work have heavy dependencies on the page
author guidelines -- particularly the WAI Education & Outreach Working
Group -- I urge this group to look for ways to streamline the restructuring
and prioritization of the content of these guidelines.

Comments on specific needs/uses follow, then objectives/requirements,
follow, preceded by JB:

>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.

JB: Could be the "quick reference card" which the EO is developing.
_However_, while EOWG can focus on format/presentation/clarity/etc., we
would need your working group to be able to tell us what the top ten or
twelve (or some such number) priorities are. That judgement is something
that should reside in the Page Author Working Group (your group).

>b).  Guidance in writing a page:
>Someone is creating a page and is interested in what they should
>do to make the page accessible.

JB: Right. Page Author Guidelines.

>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.

JB: A "recommended" set of "priority one" items from the page author
guidelines, clearly viewable when going through the guidelines and also
presented as a reference list in the appendix.  The pririority one items at
least include what's on the "quick reference list" of top 10 - 12 items.
They might include a few more things as well, but no where near the entire
list.  However an important issue here is that the requirements for legal
compliance in every country are potentially different.  W3C/WAI can provide
guidelines which can be _referenced_ by legal or regulatory processes in
different countries, but not beyond that.  What would make it easiest for
legal or regulatory processes to point to W3C/WAI guidelines is to ensure
that there is a prioritized subset which are easily locatable and
recommended to be pointed to for that purpose.  This section of the
guidelines can also include a pointer to the international policy
references area which the EOWG is developing, so people can look locally at
what the requirements are.  A related issue not on this list is relation to
formal standard-setting.  This same "priority one" list would be the most
likely candidate for inclusion in ISO and IEEE CS and other
standard-setting processes that W3C/WAI is already involved in.  Again
though this WG just needs to come up with the priority list.

>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.

JB: Same subset as above at (c), perhaps along with an additional reference
list on retrofitting guidance -- not requirements -- presented in a
separate appendix to the page author guidelines.  Or, maybe this is all
part of the same priority list.

>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.

JB: There should be a subset of the overall guidelines which reflects an
appropriate priority level for evaluation.  It could be the same as the
"priority one" level identified above in (c), or could include additional
priority levels.  I would see it as the task of this working group to
identify the set, and the task of the Evaluation & Repair Working Group &
Interest Group to figure out how to operationalize it. 

>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.

JB: Ditto what I said in (e).  The task of the page author guidelines group
can be to agree on the content of the priority levels.  It's the task of
the Evaluation & Repair Working Group & Interest Group to figure out how to
implement them.

>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.

JB: For the task of this working group, since the checklist is quite good &
well-received, re-using that format with an added element of priority
sorting should give a good testing reference list.  Just keep it in the
appendix of the guidelines.  The Evaluation and Repair Interest Group
should figure out any grading scheme.

>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.

JB: Issue of simple set is redundant with concern above at (a) and can be
met by the same "quick reference card/list" type of approach.  Task of this
group relative to the "quick list" is to identify the top 10 to 12 items.
The issue of a complex set, on the other hand, is addressed by the page
author guidelines as a whole.  Whether you package it so the whole detailed
set is at the front or the back is a matter for your consideration.

>-----------------

JB: A few comments on the objectives and requirements as well:

>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.

JB: Can include some _really_ brief explanatory material among the text of
the guidelines where essential; can include more explanation in an
appendix; can include reference pointers if someone really wants to learn
about accessibility.

>2.  Provides specific guidance as to how to achieve the general
>objectives.

JB: Yes. The model above would do that.

>3.  Can be used to ascertain whether a page is likely to be
>accessible to people with disabilities.

JB: Yes and no.  The page author guidelines should include priorities to
ensure access, but let the Evaluation & Repair tools group figure out the
details of how to assess access.

>4.  Is sufficiently defined that the GL, IG, and W3C can sign off
>and endorse it.

JB: Yes.

>5.  Is practical enough that web designers can and will use it.

JB: Huge issue here.  I think this group needs to work closely and in a
structured way with designers and get input into usability & practicality
of the guidelines from their points of view.  Is there a sub-group of page
author guidelines members who could organize themselves to get this input? 

>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).

JB: Ditto above! -- huge issue, and I think this working group needs to
work with designers on this question in an organized way.

>7.  Can be used to help guide the design of web creation tools to
>facilitate more accessible pages.

JB: Yes, but I'd let the Authoring Tools Working Group worry about how to
use your guidelines.

>8.  Can be used by HTML and web checking tools to identify and
>highlight accessibility problems on a page.

JB: already covered

>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).

JB: already covered

>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.).

JB: yes/important

>11.	Will encourage the design of pages are accessible today by
>users who have old browsers or screen readers.

JB: yes -- also important.  But this working group should also coordinate
with the Evaluation and Repair Working Group to encourage development of
proxy tools and table-cracking code etc as well as technically upgraded
text browsers so that over time there is less pressure on legacy requirements.


----------
Judy Brewer   jbrewer@w3.org     617-258-9741
Director, Web Accessibility Initiative International Program Office
World Wide Web Consortium (W3C)
MIT/LCS Room NE43-355
545 Technology Square, Cambridge MA 02139 USA
http://www.w3.org/WAI

Received on Thursday, 11 June 1998 13:38:07 UTC