Post #1 of Proposal for a REstructuring and ReOrienting the WCAG 2.0 Guidelines

 

Last week I made some proposals for looking at accessibility in a different
way. 

The following proposals are preliminary.  Feel free to question, comment and
suggest.

 

They are based on a number of observations and realizations.  Several of
these are documented in a posting to the list a week or so ago by Wendy. 

 

Also inspiring this is a desire to create guidelines that as for what is
needed rather than asking for the solution we currently know of.

 

I am going to post a number of emails to the list with different aspects of
the proposed approach in them.  I will also be posting some new thoughts
based on discussions at the F2F.   Finally I will answer some questions that
have been raised and raise some of my own.

 

 

NOTE:   Some of the ideas in these proposals can be broken out and
considered separately.   Others are tied together and don't work without
each other.    I'm not sure myself which are which - but we can all sort
through these and try to sort it out as we go along.

 

 

 


Principles 


 

1)     That we should ask for what *is needed* rather than *the way we
currently know how to do it*.   This gives everyone the maximum freedom
while focusing on what it needed today and tomorrow for todays and tomorrows
technologies.

 

2)     The guidelines should specify what needs to occur, and a way to
determine if it has occurred - and rely on the techniques documents to
specify ways to achieve these objectives at any point in time.

 

3)     We should acknowledge that some of our guidelines 

A) specify that authors mark up their content, or invisibly supplement their
content to make it accessible.    

                while other checkpoints 

B) specify that authors change their content in order to make it accessible.

 

For example

-          mark up your structure is an example of (A) 

-          add structure is an example of (B)

-          emphasize your structure through presentation is also an example
of (B)

 

The difference here is important.  For example,

-          requiring video to have closed captions (an example of A) is
different than requiring open captions which everyone would always see
(which would be an example of B if we did so)

-          requiring an alternative audio track with video description (and
example of A) is different than requiring that the descriptions always be
there or requiring that the video have less dialog or less action on screen
so that the audio descriptions would all fit (which would be an example of B
if we did it)

 

in our guidelines we currently focus on (A) as much as possible, but have
also created some (B)s.

 

 

In looking at this - one would further observe that Type (A) items are all
compatibility guidelines.  Either compatibility with assistive technology or
compatibility with accessibility features built into mainstream user agents.
(NOTE: technically AT is also a user agent or part of a user agent - hence
the use of the term "mainstream user agents".)

 

Type (B) items deal more with allowing pages to be accessible directly by
mainstream user agents without having to use assistive technologies.  To do
this often requires that content be done in particular ways.   This
restricts the options available or the freedom of expression of the authors.
While this is not something that society needs to avoid entirely, it is
something that we should try to minimize if at all possible.  

 

And that leads to principle number.

 

4)     Try to not require type (B) items as part of our minimum
requirements.

 

For example, on a building an architect may feel that there are certain
restrictions on his design since he needs to be sure wheelchairs can get in.
But as much as possible, one wants to allow freedom in how to achieve this,
and we don't want to force all people entering the building to walk up a
ramp if another method is much more effective for them (e.g. the ramp may be
an optional way to the door, not the only way to the door). 

 

Similarly, we don't want to force everyone to view a movie with the audio
descriptions. 

 

5)     Shift the emphasis from what the source sends out - to what the user
receives. 

 

For example.   If there is a free transcoding server that was publicly and
securely available by everyone from everywhere that could take all the pages
from site X and deliver them in accessible form, then site X would be
accessible.  This would be true even though the pages of site X were not
directly accessible. 


However if the pages did not come out accessible when run through the
server, or if the server was not available or usable by everyone who needed
it, then the pages would not be accessible.   Thus this is not a theoretical
definition, but a very real, practical definition.  If users can access the
content (directly or indirectly) then it is accessible.   This is similar to
buildings being accessible if they are wheelchair compatible.  If they are
accessible using the tools that people will have with them - then they are
accessible.   If they require special technology (e.g. stair climbing
wheelchairs)  that not everyone has, then they are not considered to be
accessible (even though they may be accessible to some). 

 

 

This concept of allowing transcoding servers to be included in the
evaluation of sites for accessibility  needs careful exploration and bug
hunting.  But if it can work, then it be a very powerful way to have clear,
timeless guidelines and time dependent techniques.  It can also allow
companies to more easily introduce new technologies to the marketplace and
have them accessible to all on the day they are released (even though
special technologies are needed to access them).  Any special technologies
can be put on the T-servers and thus be available to everyone from day one
of release.  

 

It also provides the greatest potential I have seen for providing access to
people with widely varying cognitive and language abilities and skills. 

 


Gregg

 -- ------------------------------ 
NOTE: TRACE HAS MOVED TO A NEW ADDRESS

(Same Email and Phone)
Trace R & D Center
2107 Engineering Centers Bldg.
1550 Engineering Drive
MADISON, WI    53706

------------------------

Gregg C Vanderheiden Ph.D. 
Professor - Human Factors 
Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
Gv@trace.wisc.edu < <mailto:Gv@trace.wisc.edu> mailto:Gv@trace.wisc.edu>, <
<http://trace.wisc.edu/> http://trace.wisc.edu/> 
FAX 608/262-8848  
For a list of our listserves  <http://trace.wisc.edu:8080/mailman/listinfo/>
http://trace.wisc.edu:8080/mailman/listinfo/