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

Just some of my thoughts -

Not having a firmed-up agenda in front of us, yet, I would propose looking
at any outcomes from the f2f at CSUN.  I know Gregg had said, their group
made some nice compromise efforts that incorporated some of his ideas about
looking at the structure and philosophy behind the ³new way² of looking at
WCAG 2.0.  I¹d like to hear how this group progressed.  I¹d also like to
hear equally about outcomes and directions from the other sub-groups.

Personally, I have been looking at the technology of where transcoding
servers or client-based technologies are at this point and Gregg¹s proposal
warrants some looking into based on what I¹ve read.  We do need be be
somewhat forward thinking in our effort to set guidelines/criteria as we
look at the next steps in making 2.0 (whatever that is) something that can
set the standards and be useful to developers as they build for
accessibility.  Like many have hinted toward ­ we do seem to have become
stagnated and maybe a bold move is in order.  Change is never easy but
looking beyond can be exciting.  Let¹s see what happens!

I assume Jason, Gregg and possible others will set the agenda topics for
this Thursday.  I am just throwing the notion out there that I¹d like to
hear a reporting out from the face to face.  Also, sounds like Lisa wanted
more time to digest and that seems reasonable, but just my humble opinion,
for whatever it¹s worth.  I hope I am not too far off base with these
comments.  

Any thoughts from others in the group?  I¹ll see you all on Thursday.
Again, it was nice to finally meet so many of you in Los Angeles.

Doyle Burnett, MEd
Education and Training Specialist
Special Education Service Agency
Anchorage Alaska

www.sesa.org



On 4/1/03 4:46 AM, "Gregg Vanderheiden" <gv@trace.wisc.edu> wrote:

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