W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2000

Re: A Fresh Look at Accommodating Cognitive Disabilities

From: Greg Gay <g.gay@utoronto.ca>
Date: Sun, 07 May 2000 13:28:45 -0400
Message-ID: <3915A7CD.A568278E@utoronto.ca>
To: w3c-wai-gl@w3.org

>  I've previously suggested that guideline one specify
> that graphics be required as an alternate to text. I'd like to see a
> minimum requirement of one illustration be included on a page and that
> illustration should be placed so that it is seen when the user first opens
> the page. It's only a start of what needs to be addressed regarding
> inclusion of graphics so they can aide comprehension of text.

I agree that graphics are a must on web sites, however there are
limits to what we can ask web developers to include in graphical
form. I also agree with your observation, and WL's, "*unexplained* visual aids
might be as confusing (difficult) and frustrating". I think an approach like
guideline (14.1) can be applied here, when it's wording clearly reflects the nature
of the site's audience and the appropriate use of alternative formats:

Depending on the Audience
14.1 (P1)
Use the clearest and simplest language appropriate for a site's content
14.4 (P1) could read:
Use  multiple formats appropriately to aid comprehension, suitable for a site's content and audience.

For example, a site intended for those with cognitive disabilities should include plenty of
visual (and auditory/text) alternatives, while a site intended to convey scientific
information (eg. an online paper) should only include a few visual
aids to improve comprehension for important or difficult points.

Gregg mentioned ".. there will be some groups of people with cognitive
[disabilities] that will never be able to use a web page even if you did
everything to it." and, "there are some types of information on the web
that we can never really make accessible to people who are blind." I believe his
point is that we can never really expect Web designers to accommodate every last person who
might visit a site, but we should expect them to adequately accommodate the intended
audience. This will be an important point in formulating guidelines for
providing accessibility for those with cognitive disabilities.


Navigation vs Content
You can also distinguish between graphics that are navigational
elements and those that are content; generally, the first is
functional and the second is a unit of knowledge. In cognitive lingo, one
is procedural and the other is declarative. At one level
developers can be asked to include visual navigation tools that
provide visual cues (e.g.. icons, buttons, image maps) or structure
the content of the site into a form that can be visualized ( e.g., a
site-map, index, table of contents). At a second level developers
can be asked to include visual alternatives for content. On the one hand concrete
content, such as directions for assembling something, is
relatively easy to create, but on the other hand abstract content, such as a definition
for "liberty", are not easily created or effectively conveyed in a visual format.

We can't "require" designers to provide visuals for abstract content, and how
much of the concrete content should include visual alternatives
will be difficult to agree upon.

We will have more success asking designers to include
visual navigation alternatives, since navigation tools are generally
created only once. The amount of work involved in creating
alternative navigation systems will be much less than that required to
create visual alternatives for content. As Gregg mentioned, currently
"P1 P2 and P3 are based entirely on the degree of access they provide and not
at all on ease of implementation." For this reason using alternatives for navigation should
be a higher priority than including alternatives for content.

14.4a (P2) could read:
Use redundant alternative navigation, appropriate for a site's content and audience
(buttons, icons, text links, image maps, sitemap, index, search)

14.4b (P3) could read:
Use redundant alternatives for content, appropriate for a site's content and audience
(audio, video, images, text)

(14.4a could fit into guideline 13, and 14.4b could fit into guideline 1)

> Regarding TTS, as long as it doesn't properly render boxed text/tables,
> doesn't allow visual access to graphics/text while the text is read, and
> remains too hard for folks with normal hearing to understand, it shouldn't
> be considered a significant accommodation for LD/CD folks. Citing TTS
> suggests the problem has been solved, when in fact it does no such thing.

I disagree with your opinion that TTS is not an important
accommodation. Perhaps not for everyone, but definitely
helpful for many. Many of the college age LD students I have
worked with use it regularly, not to mention a variety of useful
tasks TTS can be used for, for anyone (e.g.. proof reading,
multi-tasking, a preschool reading teacher,... ). Marshall Raskind has conducted
numerous studies that show how TTS benefit those with LD. Perhaps a less
rigid approach would be more effective. Such as "TTS is helpful
for a portion of those with LD, those with auditory and verbal
processing intact, but will be less useful to those who's cognitive
disability is rooted in either one of those processes."

I also agree with the reasoning, outlined by Jason, that part of the responsibility should be placed on the developers of adaptive
technology to design their products to process components such as tables. It would be unreasonable to ask Web designers to give up
using tables to format layout. I think however, that layout of text in tables should receive a priority 2 ranking, since from the
view point of adaptive behaviour, comprehension is improved with a simplified and consistent layout (see guideline 13), and with the
current state of these types of programs (i.e.. TTS), few of which read table correctly, changing these programs will be a more
difficult undertaking than for their developers, than asking Web designers to provide linear formats readable by current TTS
programs. Once the TTS developers have "caught up", as most screen reader developers have, the priority can be reassigned a P3

Received on Sunday, 7 May 2000 13:33:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:32 UTC