Kynn's Analysis of CD Web Accessibility

Having taken a vacation this last week, both physically and
from the net, I've had time to consider the issues related to
accessibility for people with cognitive disabilities.

One key question I've been wrestling with has been "is this
different than enabling access for people with other
disabilities (e.g. those with mobility/dexterity, vision, 
or hearing impairments), and if so, why is this different?"

It certainly has *felt* different to me, and so I've had to
consider why exactly that difference may be.

Here's what I concluded:

     When creating a web page that can be used by people
     with other disabilities, we are not making the page
     -directly- accessible to them, we are making the page
     accessible to their assistive technologies.

For example, when I create a page that can be used by someone
who is unable to see, I am not actually creating the sound
files and sound-based navigation structure she needs in order
to achieve accessibility; instead, I am ensuring that my page
interacts properly with her screenreader and/or specialized
web browser that can provide for her what she needs.

To enable access for a user without mousing ability, I don't
have to write a keyboard driver or explicitly program a
javascript keyboard-based interface for my page; I simply need
to make it compatible with the user's assistive technology.

However, when dealing with people with cognitive disabilities,
I'm not dealing with the assistive technology -- instead, I've
got to make the page *directly accessible* to the user.  

This puts me in the position not of a web designer seeking to
make his page interoperable with someone's access device, but
instead, one meta-level *up* -- I -am- designing their assistive
technology!

I believe this helps explain many of the problems faced by the
Web Accessibility Initiative regarding the issues related to
CD accessibility -- putting us in the position of directly
creating the interfaces.  An analogous situation would be if
the WAI were trying to design a screenreader or voicing browser.
(Now, the WAI -does- suggest requirements for web browsers --
but that's generally been done in the User Agent working
group...)

This line of thought led me on to the question (as long as I'm
being asked to be an accessible interface designer!) of:

     If I were creating a browser or other designed to enable
     web access for people with cognitive disabilities, what
     would that browser be like?

Now, of course, there's a need for a breakdown of "people with
cognitive disabilities" into smaller groups, because as we know,
that grouping covers a pretty broad range of disability types.
And I personally don't have the expertise to describe their
needs or how to meet them, but I can suggest some ways in which
various theoretical needs may be met.

PRODUCT SPEC:  CogWeb 1.0

     This describes a theoretical user agent, CogWeb 1.0, 
     created to meet the needs of users with cognitive
     disabilities.

     * Screenreader Compatibility:  CogWeb interfaces with
       any screenreader or accessibility technologies
       installed in the user's operating system, allowing
       for words, phrases, and web pages to be read out
       loud to enable access for non-readers.  A button 
       on the toolbar allows for the current highlighted
       text to be read out loud.

     * Graphical Icon Library:  At the user's request, 
       CogWeb will include additional graphics when displaying
       a web page.  These graphics will be chosen from a large
       (5,000 images or so) library of images that come with
       the CogWeb program.  AI-style text analysis allows 
       for subtle differences in context and meaning to be
       expressed.  The text of each icon appears below the
       icon a la "Ruby."  Web designers can also specify their 
       own image sets and/or embed graphic "hints" for unknown
       words.  

     * Definition Engine:  A powerful context-sensitive
       English dictionary -- written at a relatively low
       reading level (say, a children's dictionary) -- allows
       the user to select a word and then click on the 
       "define" button.  The definition is either popped up
       in a new window or read out loud, according to the
       user's needs and desires.

     * Page Layout Simplification:  By restructuring the
       display of web pages, CogWeb makes comprehension of
       a site simpler and easier to navigate.  Content
       analysis identifies the navigation components of the
       page, unstacks overly confusing layouts (such as
       overuse of tables), and builds simplified navigation
       schemes, such as graphically-labeled "next" and
       "previous" buttons in the toolbar that allow for
       standardized access to site contents across a variety
       of sites.

Okay, so if this is my theoretical assistive technology
device -- how do I, as a web designer, provide the information
it needs in order to present an accessible view of a page to
someone?  Here's some techniques I'll have to keep in mind:

     * Follow the methods (such as ALT text for images, etc)
       that enable screenreader access to my content.

     * Identify long words and mark them up with either the
       URI of an icon or a list of related words/concepts:

       <span cog:uri="http://www.kynn.com/icons/tibmastiff.gif"
         >Tibetan Mastiff</span>

       <span cog:keywords="dog, fuzzy, black, large, guard,
         pet">Tibetan Mastiff</span>

       This allows CogWeb to either download and display the
       icon (which must be 100 x 100 pixels in size), or to
       choose the best icon from the graphics library that
       matches the keyword -- for example, choosing a larger
       black dog icon (say, a Newfoundland) instead of a
       smaller, white dog (poodle).

     * Designate at least one additional web-based dictionary
       on pages that use complex language (dictionaries
       defined in an XML-based markup syntax):

       <link cog:lexicon="http://www.kynn.com/lexicons/lex01.xml" />

       Identify words or phrases that might be problematic and
       provide links to definitions; as well, list alternative
       text definitions inline:

       <span cog:lexicon="http://www.dogshow.com/vdslex.xml#catalog"
         cog:def="pictures of dogs" >Catalog</span>


     * Create pages where the navigation scheme is explicitly
       designated in the markup; use the link elements and the
       rel/rev attributes to designate relationships between
       pages in a collection.  These relationships are displayed
       on the tool bar -- see iCab for an idea of how this may
       be done.

     * Design pages which degrade gracefully when tables are
       removed and which allow for linearization of content.
      
What do you think about this -style of approach- to the situation?
How offensive is it to suggest that the solution is to work with
rather than create the assistive technology?

If that's a viable approach -- who, if anyone, is working on the
research and development of tools especially for our CD friends?
(In my opinion, it's not reasonable to put the entire burden of
providing accessibility to people with CD on the shoulders of
web designers!)


--
Kynn Bartlett  <kynn@idyllmtn.com>                   http://www.kynn.com/
Chief Technologist, Idyll Mountain Internet      http://www.idyllmtn.com/
Catch the web accessibility meme!                   http://aware.hwg.org/

Received on Saturday, 1 April 2000 20:28:28 UTC