RE: Skipping navigation tactics

Kynn,
That's exactly what I meant without developing fully: "Make the
accessibility user centric", have each
user configure what they want and let the tools (readers, browser, speech
engines, etc) do the rest.
Conceiveably, since disk space is cheap, 1 can point to CSSs and pages based
on many classes of users from an accessibility perspective. At first access
the user would choose and config what Accessibility class they want to use.
From then on the tools take over. 
athmane
 
 

-----Original Message-----
From: Kynn Bartlett [mailto:kynn@reef.com]
Sent: Sunday, April 08, 2001 2:30 AM
To: Nouiouat, Athmane; 'jim@jimthatcher.com'; Graham Oliver; Charles
McCathieNevile; Davey Leslie
Cc: Kelly Ford; w3c-wai-ig@w3.org
Subject: RE: Skipping navigation tactics


Another long Kynn spiel.  Skip it if you're tired of hearing me
describe my philosophy on alternate site versions. :)

At 11:32 PM 4/7/2001, Nouiouat, Athmane wrote:
>Hi,
>
>What about switch for accessibility? For example the first home-page would
>ask the user if they
>want Full-WAI-accesibility if so send them displays with accessibility
>features, if they don't
>display to them withoout any worry. If the site is carefully designed, one
>can assume, that stitically
>(or dynamically with ASP/JSP) two versions of the site (1 for accessiblity
>the other without) is achievable!
>athmane

Hi, good concept, but it's not quite all the way there yet.  For
example, the idea of having an "accessible" version and a
"non-accessible" one makes no sense -- because accessibility is
all about -people-.  Who is a particular version of a site
accessible to, and who is it not?

These are the terms we think of when designing alternate versions
of a web site.

In your case, you would make one that is "full WAI accessibility"
(note:  there is no such concept in the W3C) and one which,
presumably, is not.

A better model is to identify for whom you are making an alternate
version, and work from there.  This is a user-centric view of
alternative site versions!

For example, many people would consider the site you describe
above, that is "more accessible", to likely be one which is designed
to work with a screenreader.  That may -not- be the "more accessible"
version for certain _other_ audiences, such as limited textual
comprehension users, or limited dexterity users.  So casting things
in terms simply of "more accessible" and "less accessible" is not
the way to go.

Instead, let's consider how we can make different versions which
_meet the needs of users_.

We'll start with the "default" version -- what we called at Edapta
the 50% user.  This is the basic graphical version; most likely it
is not "basic" and all and may be the most complex of the lot!  Now,
since we have the information (somewhere) necessary to generate
"more accessible" versions, we have no real reason _not_ to include
those accessibility-helpful features (elements, attributes, etc.)
which can increase the number of people who can use our "default"
version.  In fact, since some people may not be switching right
away (or may not be able to find the switching mechanism) it may
be a good assumption that people with various disabilities may be
using this version.  So we'll make it a good one -- as WCAG
compliant as possible, for example.

But then we'll move on and create other versions of the site which
not only provide accessibility, but provide usability for specific
audiences.  We'll start with screenreader users, and provide a
version of our site which is made to work well with screenreaders.

What are the problems facing screenreader users?  Well, here's a
few (this isn't a comprehensive list):

1.  Simple, basic access to content -- images which are not labeled
     with ALT text.
2.  The order of the content can be confusing and un-usable (in the
     "usability" sense of things) because the order is a derivative
     of the graphical layout.
3.  It's hard to get a good sense of context; to know where you are in
     a page.  Also, because of the linear nature of screenreader use,
     you generally have to experience the entire page to find out what
     the content is.

Now, these can all be worked around to some degree -- which is why our
graphical "default" layout can be made accessible.  However, we can
make it even easier -- without complex work-arounds -- if we simply
design a new user interface for the screenreader version.

Here's how I'd address those needs:

1.  Well, this is actually solved.  We said that our "default graphical"
     version has access to information such as ALT text; therefore it's
     not going to be hard to include that in the screenreader version.
     So this is pretty much a gimme.
2.  We'll re-order the page to make sense; if we can set things up so
     that the user has the ability to enter an index of "this is the
     most important, here's the next, etc" for each bit of content,
     so much the better.  If not, we'll make educated guesses based on
     what we know about layout.  (In other words, in the typical web
     layout of "Something on the top, something on the left, something
     on the right, something in the middle, and something on the bottom",
     we can usually guess that the top will be identification and perhaps
     a banner ad; the left will be primary navigation; the right will be
     secondary navigation and sidebar content; and the bottom will be
     tertiary navigation and indicia.  The middle is what we're after;
     that's where we can usually find the meat of the content!  This is
     exactly how graphical web page users' visual processing of page
     content works, and we'll try to model it, either through guesses
     or through explicit author identification.)
3.  Finally, we'll construct a "table of contents" for the page and make
     sure we have intra-page anchors and other identifying marks to
     give structure which wouldn't make much sense to graphical layouts
     (which already have this information represented simply in the
     graphic design).  A good example:  We'll put text at the end of
     the page which says "end of page".

So what does this accomplish?  We now have two interfaces -- one for
graphical use which relies on traditional "graceful degradation" for
diverse access, and one which is specialized for screenreader users.

Neither one is "more accessible" or "less accessible", at least, not
if you are using those terms alone; a version may be more accessible
OR less accessible to a _specific person_ based on that person's
particular ways of using the web.  Only when you speak of "more
accessible to WHOM" or "less accessible to WHOM" does that type
of comparison make much sense.  (The same applies to "usability.")

This approach allows you to create, for specific audiences, interfaces
which are designed to be more accessible and/or usable to _that
specific audience_ without having to worry about the implications for
other audiences (whose versions of the site remain "intact" and
unchanged no matter what you do to the other versions).

I have hopes that this type of concept will be able to crack some
of the "tougher nuts" in web accessibility, such as how to solve the
thorny issues related to cognitive disabilities, where the changes
suggested might result in "completely unacceptable" alterations to
the "default" interface if you are not doing something like this.
(Under a system such as the one described, the default interface
can remain unchanged and a new one simply generated for those with
specific needs.)

--Kynn


-- 
Kynn Bartlett <kynn@reef.com>
Technical Developer Liaison
Reef North America
Tel +1 949-567-7006
________________________________________
ACCESSIBILITY IS DYNAMIC. TAKE CONTROL.
________________________________________
http://www.reef.com

Received on Monday, 9 April 2001 09:05:35 UTC