RE: Kynn's Analysis of CD Web Accessibility

Great idea (both the browser and the vacation :-)

Given the amount of confusion in this group on CD, and the difficulties that
Web Designers/Developers have had understanding the need for much more
concrete concepts like audio interface, I agree with Kynn that it's
impractical and unrealistic to expect all Web Designers/Developers to
understand CD and be able to design interfaces for it.  Web designers live
in a world where time-to-market is the single most important thing, often
determining whether your company lives or dies.  If we post a requirement
that has significant impact on that, it will be ignored.  That's the reality
of the market.

If, however we can provide simple, concrete ways to meet the requirements of
the Cognitively Disabled with minimal time investment, many more Web
Designers will do it. Creating a specialized browser or plugin and some tags
it can read does exactly this.  Only the developer of the specialized tool
has to understand the needs users with CD, which, I think the discussion on
this alias demonstrates, is a pretty specialized skill.

--Cynthia

-----Original Message-----
From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
Sent: Saturday, April 01, 2000 7:45 PM
To: 'Kynn Bartlett'; w3c-wai-gl@w3.org
Subject: RE: Kynn's Analysis of CD Web Accessibility


Interesting thoughts Kynn.

So it shifts to   "How do we mark up a page to work with tools a person with
different cognitive disabilities might use?"

Maybe we should all take a vacation.   Lets think about this some more.  I
think you have an interesting idea.

By the way - there is another difference.
- we can make most pages accessible to someone with a visual disability or
no vision
- we can make most pages accessible to someone with a hearing disability or
no hearing
- we can make most pages accessible to someone with a physical disability or
no physical ability (via neuro or eeg link)
- we can make most pages accessible to someone with a mild cognitive
disability, but only some with a severe cognitive disability and none if
they have no cognition.

Thus - we will be much more limited in our ability to address access to the
web in general by people with serious cognitive disabilities than for people
with serious visual, hearing or physical disabilities.

But your approach is interesting.....

A browser for people with cognitive disabilities.... Hmmmm
Or several for different types.. (but maybe one with adjustments)

Lots to think about here.   I think there are limitations to what we can do
today - but it will increase over time as we get better semantic analysis
tools.

We still need the guidelines we have.... But this might allow us go further.
Trying to do it will certainly be a challenge though.


By the way:  the 508 guidelines just came out and there is no cognitive
guidelines left in it anywhere that I could find.    So this will be even
more important to see what can be done in the way of a browser - or user
agent.

Gregg




-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Dept of Ind. Engr. - U of Wis.
Director - Trace R & D Center
Gv@trace.wisc.edu, http://trace.wisc.edu/
FAX 608/262-8848
For a list of our listserves send "lists" to listproc@trace.wisc.edu

 -----Original Message-----
From: 	w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]  On
Behalf Of Kynn Bartlett
Sent:	Saturday, April 01, 2000 7:33 PM
To:	w3c-wai-gl@w3.org
Subject:	Kynn's Analysis of CD Web Accessibility
Importance:	High

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 Thursday, 6 April 2000 23:31:53 UTC