Access Tool Requirements

At 4:12 PM +1000 2001/10/27, Jason White wrote:
>gian@stanleymilford.com.au writes:
>  > OTACS-2:
>  >
>  > *  assumes the site will only be accessible using certain tools
>  >
>  >    *  eg. site is accessible only once stylesheets have been rendered.Ý
>  >       What happens if stylesheets are turned off?Ý Will there be a
>  >       clause "...if tools are turned off the site must still be
>  >       functional..."?
>  >      
>The principle doesn't make any such assumption; rather it requires
>that the content itself (markup, text, audio/graphics, user interface
>etc.) include sufficient machine-processable information to enable a
>user with a disability to receive an adequate rendering, possibly with
>the aid of assistive technologies and other client-side mechanisms.

I think we need to be very careful about this, and "gian" (sorry, don't
remember the name) has a good point here.

There is a big danger here in just looking at things from a content-
centric standpoint, and that danger is that we may become seriously out
of sync with reality.  The problem is exacerbated, not helped, by new
XML-based technologies and updated specifications.

Basically, the question is:  What if there is, say, a spec for something
but nothing supports it?  Web developers _want_ their web pages to be used
by everyone, including people with disabilities.  But if we say "you
should use LONGDESC" and then they ask "how many browsers support
that?", we lose credibility if it doesn't actually enable access for
people with disabilities.  If we say "use CSS 2!" but it doesn't work,
then we've got a problem.  If we say "use the newest version of Adobe
PDF!" but few people out there can access the content, there's a
problem.

The less practical our suggestions are, the less credibility we have.
"These guidelines will help make your content more accessible to people
with disabilities, except that they really don't actually help any
people with disabilities -- but maybe in the future someone will build
assistive technology which could read it!"

Consider this -- what if I start serving up pure CORAL documents?
CORAL is an XML-based content language used internally at Reef, and it
was designed specifically to contain accessibility information and
the necessary metadata to do multi-device transformations.  Therefore
the argument can certainly be made that all necessary information is
available in a machine-readable format -- but clearly no user agents
out there can understand CORAL and render a CORAL site for a web
user.

My point, summarized:  We really _must_ consider things not just from
the context of the content, but also from the view of the user, and
specifically the user with one or more disabilities.  If something is
accessibility "according to specification" but not according to
practice, then we can't simply say "you should be using the one
screenreader which supports this" if our concern is access for that
user rather than dogmatic purity.

--Kynn

-- 
Kynn Bartlett <kynn@reef.com>
Technical Developer Liaison
Reef North America
Accessibility - W3C - Integrator Network
________________________________________
BUSINESS IS DYNAMIC. TAKE CONTROL.
________________________________________
http://www.reef.com

Received on Saturday, 27 October 2001 12:11:03 UTC