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

Web Content Accessibility Guidelines - Reformulation (TAKE 6)

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Fri, 02 May 2003 15:17:58 -0500
To: w3c-wai-gl@w3.org
Message-id: <012201c310e7$ec5bb9f0$ac17a8c0@TOSHIBATABLET>

Web Content Accessibility Guidelines - Reformulation


At the WCAG face-to-face at the CSUN conference, a quite different approach
to web accessibility was raised with the group in connections with the
discussions around conformance.  This approach actually consisted of a
number of different concepts.  Discussions at the face-to-face and
subsequently have embraced some, modified some and rejected or not adopted
others.  This document is an attempt to capture the current thoughts
suggestions and issues of the working group members at this time.  In order
to not confuse the reader, the original proposals and forms are not
presented.  Instead, the description tries to focus just on the current
thinking and areas of consensus or interest.


It must be emphasized that the group is still thinking this through, so the
description below is not a final, concise and fully integrated proposal or
approach.  It should give the reader a good idea, however, of the concepts
being considered.



The revised approach to the guidelines is based on a number of observations
and underlying principles.


Observation #1:

The overall checkpoints and success criteria can be divided into two general


A) Those guidelines that talk about adding supplemental (hidden) mark up,
tagging or information which makes the page more accessible (e.g. Alt text,
table/header mark up, making sure that any structure in the document is
machine readable, etc.), but does not prescribe the default presentation of
the page.  


B)  Checkpoints and success criteria that make pages more accessible by
prescribing how the default presentation of the page would be constructed or
appear.  (e.g., "add structure", "use or avoid specific language", "visually
emphasized structure", supplement text with images, etc.)


Observation #2:

The recommendations also varied in terms of their general applicability.
Some of the checkpoints and success criteria could be applied to all
websites or content while others could not.


Observation #3:

Putting checkpoints and success criteria into the required category that
could not be applied to all sites would mean that some sites/content could
not make any accessibility claim.


Observation #4:

If the checkpoints and success criteria were included in the minimum which
prescribed the language or appearance or presentation of pages, then it was
likely that we would run into problems in ratification of the guidelines and
even possibly challenges as restricting free speech.  If we wanted to have
the "minimum required" portion of the guidelines be consistent across
implementers, agencies, countries, etc.  Then, we would need to be quite
careful about what we put into the minimum category.


Observation #5:

Different countries and agencies are interested in going to differing
degrees of comprehensiveness with regard to their individual requirements.
That is, different countries have shown an interest in wanting to create
guidelines which had slightly different emphasis in terms of the overall set
of guidelines they would require.  Flexibility in determining what they
wanted to have as a set of requirements was therefore seen as important.


Observation #6

There is great concern among web developers that countries not each create
different sets of guidelines which are either mutually exclusive or
contradictory since they often have to create web sites that would be
viewable from different countries and/or mirrored in different countries.
Web developers also find it impossible to keep track of all the variations.
However, if the only variation between entities was the items they chose
from a standard set of guidelines, then at most, they would need to create
pages which complied with the union or complete set of guidelines
represented by the various jurisdictions they were interested in conforming
with.  They could just form a superset and build the web pages to that and
they would comply with all of the various jurisdictions since they would all
be proper subsets of the WCAG guidelines.  Presumably, each of these
different jurisdictions would use the minimum required set, plus some proper
subset of the remaining WCAG ) checkpoints and success criteria.


Observation #7:

Once you got past the minimum, it was useful to have some other targets to
shoot for.  That is, it is useful to have some other group of guidelines
beyond the minimum which a person could strive to "meet all of".  This was
likely to yield better conformance than simply having an open ended claim
once you got beyond the minimum level.  However, it might be possible to
simply have something that would provide a measure beyond the minimum (e.g.
compliance plus twelve) which might provide a similar motivation for people
to keep trying to improve their sites.


Observation #8:

The use of server based services (e.g. transcoders and other services
/processes that transform content) are a powerful new tool that can help to
automatically convert less accessible content into more accessible content
and convert special proprietary formats into general, standard and highly
accessible formats.  In writing the guidelines and the conformance, server
side and "proxy server" or "third party server processed pages" should all
be acknowledged and allowed as effective accessibility strategies for web
content providers where these strategies are available at the same level as
the default serving of pages (e.g. the user requiring these special services
can get them at the same cost, with the same speed, and from the same
locations as a user who is just accessing the "default" pages).


Proposed Restructuring Approaches and Principles

1.	A new conformance approach would be used that divides the guidelines
and success criteria into 1) a minimum required set and 2) a group of
additional guidelines and measures which would increase the accessibility
beyond the minimum set.


2.	The minimum set (Group A) would be restricted to those checkpoints
that do not prescribe the language and presentation form of the default
presentation of the page.


3.	The body of additional checkpoints and success criteria may or may
not be divided into additional groups.


4.	At present, we see the "Extended Guidelines and Measures" as
breaking down into two groups (group 2 and group 3)  

-     one group (Group B) representing those things which do effect
presentation, but which could be generally be applied to most or all sites

-     a second group  (Group C) which represented additional measures which
could be taken, but which would not be practical or possible for all sites
or which might require that the site content be rendered in multiple


5.	The last proposed set of descriptors for this three group model as
of May 1st is: 


GROUP A - Those measures that can provide access without changing or
constraining the presentation of the page - and that it was felt could be
reasonably applied to all web content or sites.  

*      These items address compatibility of the Web content with assistive
technologies for all disabilities.  

*      They also include accessibility that can be achieved using mass
market web browsing technologies but that do not affect the default view of
the content by all users. 

*      These measures would constitute the core required set of checkpoints 


GROUP B. - Those measures that allow access beyond Group A but can be
reasonably applied to all types of web content or sites.  

*    These measures affect the presentation of the pages somewhat in order
to make them more accessible.   

*    They often allow access to some individuals without requiring any
assistive technology. 

*    These do not address all disabilities but allow many to access web
content using mass market web browsing technologies alone. 


GROUP C. - Those measures that improve access, either directly or via
assistive technology, beyond Group A but that cannot be applied reasonably
to all web sites or content.  

*    Some would require multiple presentations of the information or
targeting of the web site to individuals with particular functional

*    Some would be an unreasonable amount of work to expect of all web
content or sites. 


6.	Conformance with the WCAG guidelines would require the minimum or
first group of items all be met.  No conformance could be claimed without
meeting all of these first items.


7.	Entities wishing to create their own set of guidelines based on WCAG
would have to include all of the minimum set or minimum group.  They would
be free to choose include and/or admit any other checkpoints or success
criteria beyond, or from the rest of the WCAG guidelines as they saw fit.
However, in order to avoid conflict, it would be extremely highly
recommended that they not change any of the checkpoints or success criteria,
but rather just adopt or exclude them. (If there were any items in the
minimum set that particular entities had trouble with, it would be optimal
if they could identify the items and the issues before adoption of the final
guidelines so that the issues could be accommodated.


8.	Page author/websites could claim conformance with the guidelines if
any of the following were true:

a.	The default pages from their site met the guidelines.
b.	Alternate versions of the pages (which had the same content and
functionality and were updated simultaneously with the default pages), were
available from the same URI 

This could be done either automatically or from an accessible link on that
same page. 


c.	A link or mechanism at the same URI as the default page was
available that routed the content through a (local or remote) processor that
would change the content into a form which would conform with the WCAG

(i.e. a page that was run through the transcoding server that was available
for the same cost and the same hours and the same speed, etc. as the default

Vendors may opt to either maintain and run such a transcoding/processing
server as a part of their site or may contract with a third party to make
such a server available which would quickly and efficiently process any
pages from their site as required by users.

Received on Friday, 2 May 2003 16:18:18 GMT

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