Re: Kynn's Analysis of CD Web Accessibility

 i second that, vacation!

but i tend to agree.  this is an evolving area where we become engineers who
post a product but pull it back for redesign because techolgoy cahnged or
another idea was just added, but this idea did not have the technology
support yet.  so when do we stop designing and get something down and out
the door? this is the classic trap.

we can keep on desiging but we need to also have the ability to update and
get a recommendation out faster...time to market is going to really hurt us.

just brainstorming

----- Original Message -----
From: Gregg Vanderheiden <gv@trace.wisc.edu>
To: 'Kynn Bartlett' <kynn@idyllmtn.com>; <w3c-wai-gl@w3.org>
Sent: Saturday, April 01, 2000 10:44 PM
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 Saturday, 1 April 2000 23:10:12 UTC