W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

Proposal for 3.4 Success Criteria

From: Joel Sanda <joels@ecollege.com>
Date: Sat, 4 Aug 2001 07:59:53 -0600
Message-ID: <2FECE9363D811B418C3F282834F172A56DBE52@sundance>
To: "'w3c-wai-gl@w3.org '" <w3c-wai-gl@w3.org>, "'Kynn Bartlett '" <kynn@reef.com>, "'Matt May '" <mcmay@bestkungfu.com>, "'Wendy A Chisholm '" <wendy@w3.org>
Kynn & Others;

First - I seem to have lost a chunk of my inbox and I think there was
something in there about 3.3 and 3.4. If I'm covering ground the group has
already trod over my apologies.

Kynn - I had the chance to play with SVG on Friday and was amazed at how
much opportunity it gives web developers and content authors the chance to
use a single source for content, XML, for both text and graphics. It's
amazing stuff. Of course, I hounded our resident SVG expert to show me how
it can render the contents of a table visually. It works. We took a table of
non-sensical data that could be plotted on an x/y axis easily and rendered
that in an SVG presentation that was linked next to the table. The user
could flip the x/y axis to get a different view of the data and keep that
SVG window open, near the table, to reference the relationships.

I have to agree 3.4 is important, too important to not include because we
can't seem to agree upon a means of documenting success. 

Matt - correct me if I'm wrong - but I think the testable criteria you're
talking about is also about how self-evident 3.4 is. It isn't - meaning we
won't know how accessible our stuff is until someone sits down to digest the
information and can't because it's inaccessible to them, for whatever
reason. I managed a QA group for quite a while and shudder to think of how
one would write test plans and test cases for 3.4 as it's written now <grin
/>.

I'd like to propose we make the success criteria of 3.4 closer to that of
3.3. Point 3.4's goals are very close to those of 3.3. I've added two
adjectives to text descriptions: complex and significant. 

Complex meaning an idea that isn't self evident to a viewer who would
otherwise not know. For example: talking about how heat can increase the
temperature of water isn't as complex as talking about the chemical reaction
involved in changing cold water to steam. The former may not need a non-text
supplement, while the later should have one.

I also added the phrase "significantly concrete" to the second bullet item.
What if someone is presenting an idea that is not significantly concrete,
but the examples the author uses to support the idea are? An essay on
democracy could easily use symbols that aren't meaningful to a wide
audience: a country's flag or similar object that country/culture identifies
with democracy. But if the author describes how democracy means candidates
are selected from a pool of people, people vote, the votes are counted and a
winner declared - those are all significantly concrete enough to warrant a
non-text supplmenent. (This idea came to me listening to an NPR story about
proposed voting reforms in the U.S. in light of the last presidential
election. One of the people interviewed remarked that voting mechanisms
would be improved with pictures and symbols of candidates.)

Here's what I've come up with for 3.4 success criteria:

* For any complex description of a process or of relationships, provide a
sufficient non-textual equivalent or link to content that contains a
non-textual equivalent.

* For any page that has a significantly concrete concept whose understanding
can be enhanced with a visual element, auditory element, or interactive
process to enhance understanding provide:

a graphic illustration, and/or 
an audio clip, and/or, 
a virtual simulation and/or, 
a video, 
and/or link to content that contains illustrations of the concrete concept. 
A concrete concept is a person, place or thing. For example, an animal, a
plant, or a product. It can also stand for a class of nouns - cats, birds,
computers, mountains, hotel rooms.

* For a page that describes an organization or concept for which there is a
well known symbol or logo, include that symbol or logo in the content or
link to content that contains the symbol or logo.

* For complex data information signifying relationships or the strength of
relationship, provide a graph, chart, or some other common visual
representation of the data or link to content that illustrates it.

* When referencing sounds, link to a clip of the sound.

You will have successfully supplemented text with non-text content if you:
* anticipate many modes of learning and use more than text to communicate
ideas, concepts, relationships, and processes with non-text content,
* anticipate that your audience will have a wide range of educational levels
and background knowledge and address that with multiple ways of
presentation,
* supplement new concepts or terms, provide additional definition or
annotation using non-text elements, or link to additional illustrative
resources that will help your audience understand the new concepts and
terms.

-----Original Message-----
From: Kynn Bartlett
To: Matt May; Wendy A Chisholm
Cc: w3c-wai-gl@w3.org
Sent: 8/2/2001 1:46 PM
Subject: Illustrations for content

At 10:11 AM -0700 2001/8/02, Matt May wrote:
>I just don't think
>that merely their presence as a rule increases access or usability.
>The point I've been trying to make is that presence does not indicate
>quality.

But the same can be said for alt text.  alt="IMAGE" alt="please download
this graphic!" alt="grf373.gif"

>Maybe Charles and Kynn are right that my issue is really with the
compliance
>scheme, and maybe sometime soon someone can tag me with an action item
to
>come up with tweaking it. But even absent a compliance scheme, I still
have
>trouble applying success criteria to a checkpoint when the true measure
of
>success can only be discovered through testing.

I don't know, testing is a great thing (as you know) and it probably
needs
higher prominence in our guidelines.

I think we all agree:

1.  Illustrations, when used well, definitely do increase the usability
     of a site and the accessibility to people for whom text alone is a
     challenge.  (I've heard nobody object to this, except perhaps for
     Jakob Nielsen, implicitly.)

2.  Illustrations, when not used well, can introduce problems, or at
     best are "not helpful."

3.  Illustrating content is not trivial; it's usually easier for most
     people to create alt text than to create an illustrative graphic,
     for example.

4.  However, lack of illustrations may present a barrier to access for
     certain individuals.

I am fairly certain that nobody here disagrees with those things.  So
the
question simply is how to write a "guideline" or "checkpoint" that is
acceptable -and- which conveys the above wisdom in a reasonable manner.

My fear is that our reliance on being a "checklist" and not a "set of
excellent principles and advice" has so limited our way of thinking
that we are unable to see the value of simply stating the 4 points
above!  Because we MUST draft everything as "checkpoints", we lose out
on the idea of "guidelines" which are good and useful.

A checkpoint saying "fully illustrate all textual material" is
absurd.  However, advice saying "illustrating textual material will
remove accessibility barriers" is amazingly useful and what's more it
_needs_ to be said!

Which is why I am really straddling the line here, but if forced to
decide I would go with Anne's "side" because I believe I would rather
have it explicitly told to web authors that "illustrations can help
people" instead of simply having this folded into vague and generic
statements about multi-modal data structures.

The _concept_ is too important to lose just because we insist on having
a checkpoint structure.

--Kynn

-- 
Kynn Bartlett <kynn@reef.com>
Technical Developer Liaison
Reef North America
Accessibility - W3C - Integrator Network
Tel +1 949-567-7006
________________________________________
BUSINESS IS DYNAMIC. TAKE CONTROL.
________________________________________
http://www.reef.com
Received on Saturday, 4 August 2001 10:00:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:11 GMT