Designing for screenreader access (was: New Topic)

At 08:22 AM 6/6/2001 , David Poehlman wrote:
>I'm not sure I understand.  when I use jaws, if the linav links are at
>the bottom of the page, I can just stop before I get there and go to the
>next page.

An approach we use when building sites -specifically- for 
screenreaders (thanks to transformable user interfaces) at Reef/
Edapta goes something like this.

Each "chunk" of content is labeled with a title.  This might be
"main content" or more likely a descriptive title such as "Description
of our Services."  Another chunk might be "Sidebar: More About Our
Health Plans".  A navigation could be "Navigate Our Site" and
another might be "Explore This Section."  Each chunk is given an
"index number" as well to indicate the relative importance within
the page.

These chunks are all stored in an in-house XML format, and then
converted to the appropriate markup language for output to a variety
of devices.

When we identify a user as employing a screenreader, we create an
interface which builds a menu at the beginning, in priority order.
In the example sketched out below, this would produce a page like
this:

      Welcome to Our Medical Company

      1.  Description of Our Services
      2.  Sidebar:  More About Our Health Plans
      3.  Explore This Section
      4.  Navigate Our Site

Those are all hypertext links to anchors further down in the page.

We feel that this has several useful effects:

(1) It allows direct access to the primary material of the page,
     which is the -main- reason for a "skip links" requirement in
     the first place.

(2) It allows direct access to navigation and other content on the
     page by building a navigable menu which does not exist in the
     graphical version of the site.

(3) By virtue of being a "virtual table of contents" for a page, 
     this approach allows a screenreader user to capture that very
     important aspect of web surfing that is often lost:  Context.
     As has been stated in this thread, often a screenreader user
     has to experience the entire page before knowing that she's
     reached the end!  The contents listing gives her the necessary
     knowledge of what's on the page before she listens to the whole
     thing, which is also useful so that she can identify if she
     is at the right place.


Note that most of these benefits are actually closer to "usability"
than "accessibility" -- without them, the content is _still_ there,
and _can_ be accessed, it's just not the best interface possible for
that user.  And the "best possible user experience" is our ultimate
goal (at Reef); we don't want to think of ANYONE as being deserving
of less than a well-designed UI.

Which of course begs the question of "is this the best interface"?  I
think it probably is, but honestly neither Reef nor Edapta has had
much time or money for doing usability testing yet.  So your
comments on this would be appreciated.

The topic of "how do you design a good UI when you know you are dealing
with a SPECIFIC audience with disabilities, not designing a one-size-
fits-all UI" is mostly unexplored territory.  I know all about how to
make a graphical UI that "degrades gracefully" to a poorly done
screenreader UI; that's old hat and we've been doing that for years.

The challenge facing us at Reef is one of thinking outside the
"universal design (of an interface)" box and looking instead at what
is the _best_ interface rather than the _compromise_ solution.

Comments, feedback?  Volunteers to play with our test sites, once we
get them up and running? :)

--Kynn


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

Received on Wednesday, 6 June 2001 11:51:40 UTC