ALTCOGPRES (was: Fwd: Kynn's Analysis of CD Web Accessibility)

Hello,

At the beginning of April, Kynn described a tool and strategies that were 
along a similar train of thought.  I am reposting this for consideration as 
I found it very interesting.  The assistive technology could either give 
the user a "semantic transformation" (such as the summarizers that were 
floating around on the web a couple years ago) or a "graphical 
transformation" based on language processing.

--wendy

>Resent-Date: Sat, 1 Apr 2000 20:28:31 -0500 (EST)
>X-Sender: kynn@ayla.idyllmtn.com (Unverified)
>X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
>Date: Sat, 01 Apr 2000 17:32:34 -0800
>To: w3c-wai-gl@w3.org
>From: Kynn Bartlett <kynn@idyllmtn.com>
>Subject: Kynn's Analysis of CD Web Accessibility
>Resent-From: w3c-wai-gl@w3.org
>X-Mailing-List: <w3c-wai-gl@w3.org> archive/latest/3324
>X-Loop: w3c-wai-gl@w3.org
>Sender: w3c-wai-gl-request@w3.org
>Resent-Sender: w3c-wai-gl-request@w3.org
>
>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/

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Tuesday, 2 May 2000 07:39:24 UTC