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

Re: How to describe Flowcharts, Schematics, etc

From: <karl.hebenstreit@gsa.gov>
Date: Wed, 25 Aug 1999 18:10:56 GMT
To: smccaffr@MAIL.NYSED.GOVATinternet, w3c-wai-ig@w3.org
Message-ID: <OFC3973FBD.BC10402E-ON852567D0.00724F0D@gsa.gov>

Steve -
This is an interesting response and I'll need some more time to reflect on
everything you're saying, but there's another aspect I'd like to point out.
I certainly hope you realize how "blind-centric" your statement below is:
"Humm, if the text has the same information, what is gained by drawing the
chart at all?".  This is precisely the type of attitude for which the LD
community has been so critical  of the WAI guidelines in recent threads.

A flowchart is primarily a visual tool; even if you could perfectly convey
all the information contained in a flowchart in a narrative text, the
visual representation is still needed because it helps reinforce this
information for visually-oriented people.

 A tool like AllClear could make it possible to greatly improve
communication between a blind person and a sighted person.
A blind person, after hearing a process described, could create a flowchart
based on his/her understanding of what they heard.  The flowchart could
then be used as the medium to convey this understanding to the sighted
person, who would then be able to comment.  In this scenario, I would argue
that a blind person would provide invaluable insight into the accuracy of
the flowchart diagram.

This scenario also brings up a point that I feel is often neglected from
WAI discussions.   Too much of our discussions are focused solely on the
technology, rather than on using technology to enable and improve
communication among people.  While I certainly agree that the goal is to
enable each person to be independent to the greatest degree possible.  Our
discussions are also almost exclusively focused on individuals, although
the increasing complexity we are faced with in addressing societal issues
is demanding greater collaboration among people.

One area I would like to see more focus on is encouraging and enabling
communications among people with disabilities.
 For example, identifying four disabilities -- visual, hearing, cognitive,
and motor -- would lead to 15 (2 raised to the 4th power, minus 1) possible
combinations.   By the way, this would best be presented to
visually-oriented people in a Venn diagram with four overlapping circles
(I'm still working on drawing this correctly).   These 15 combinations
would include the 4 disability groups by themselves, 6 pairs, 4 groups of
three, and one of all four (which is universal design).   We need to be
careful about our use of "Unversal Design" and make sure that we apply it
appropriately; using the term when we're not focusing on all disability
groups undermines its effectiveness.

One of the most strategic ways we could address accessibility issues would
be through enabling the direct communication among disability groups.
Assistive technology has progressed to the point where we can enable a
blind person and deaf person to communicate directly (a blind person using
a TTY software package with a screen reader).   To what degree can the
other pairs be addressed -- visual and cognitive, visual and motor, hearing
and motor, hearing and cognitive, cognitive and motor?

Karl Hebenstreit, Jr.
US General Services Administration
Center for Information Technology Accommodation
Home Page:  http://www.itpolicy.gsa.gov/cita
E-mail:  karl.hebenstreit@gsa.gov






From: "Steven McCaffrey" <smccaffr@MAIL.NYSED.GOV> AT internet on 08/17/99
      07:17 AM

To:   Karl F. Hebenstreit Jr./MKC/CO/GSA/GOV, w3c-wai-ig@w3.org AT
      INTERNET@ccMTA-GEMS-MTA-01
cc:   Raman@adobe.com AT INTERNET@ccMTA-GEMS-MTA-01

Subject:  Re: How to describe Flowcharts, Schematics, etc





Hello Karl, Charles, Len etal:

Let's take the March 1999 Quality Magazine review as an example of what I
see as some software tools having some possibly marginally useful features,
but, in my view, the emphasis, in terms of making charts and diagrams
accessible to the blind, still misses the fundamental point. As an overall
starting point, let me re-emphasize that the discussion is technically not
how to make the graph or chart accessible, but how to make the
*information* conveyed by such visual presentations accessible.  A
flowchart is a presentation mechanism, not the underlying information
itself.

"            AllClear version 4.5 makes it much easier to create charts from
            text. It also features an easy-to-use tool for converting charts to  Web graphics formats."

Are the resulting web graphics understandable by screen readers?  My guess is no.  In my opinion, is not sufficient to mearly replace a
two-dimensional arrangement of symbols with a linearly spoken sequence of symbols, be they semicolons and other special symbols(apparently in earlier
versions of AllClear) or even some higher level syntax such as control flow words like "while" or "If...Then...".

Note that the main advantage of AllClear 4.5 seems to be the ability to
type in text to draw the chart.  Humm, if the text has the same
information, what is gained by drawing the chart at all? The fundamental
question I asked early in this thread is the one completely ignored by
this, and probably other, charting programs as well.  The first question to
ask when deciding how to make graphs and charts accessible to the blind is
"What information am I trying to convey with this chart/diagram?"  These
chart drawing programs, text entry or drag and drop interface, seem to have
the drawing of the chart the end, and not the means.  In other words these
programs assume the user is asking the question "What would this process
look like as a chart or diagram?"  A good question for a sighted person,
but as a blind person, my question would be "Why do I want to know that?"
Since something must be in the resulting chart that is not in the text
description that gets mapped to the chart, I still think asking what that
something is should be the critical question. In a slightly different
context, Dr. T.V. Raman has written clearly and concisely on the nature of
the information access differences between vision and hearing.  In his
article "AsTeR: AUDIO SYSTEM FOR TECHNICAL READINGS", appearing in  the
November 1994 issue of Information Technology and Disabilities (
http://www.rit.edu/~easi/itd/itdv01n4/article2.html he writes:


"Visual communication is characterized by
the eye's ability to actively access parts of a two-dimensional
display.  The reader is active, while the display is passive.
This active-passive role is reversed by the temporal nature of
oral communication:  information flows actively past a passive
listener.  This prohibits multiple views - it is impossible to
first obtain a high-level view and then "look" at  details.
These shortcomings become severe when presenting complex
mathematics orally."


Precisely.  I wish I could write with such clarity and precision.
It is my view that the same can be said when describing charts and graphs.
I think programs such as AllClear ignores the excellent point len made
about separating structure from content (also a major theme of Dr. Raman's
writing/work)so in short it is NotAtAllClear that such tools are the right
way to go for making visually presented information accessible to the
blind. Personally, I would prefer we move in the direction Len suggested
earlier: ">Yet another way, which goes even further in separating content
from >structure, would be to represent the abstract information (e.g.
>organization chart) as XML and use a  style sheet to translate that to
>graphics.  Then the RDF, and the logic programming, could apply directly
to >the abstract information.
>
>These would all make the diagrams more useful to everyone (and to
machines) >since they wouldn't just be pictures anymore: they would be
information."


-Steve







------
Steven McCaffrey
Information Technology Services
NYSED
(518)-473-3453


>>> <karl.hebenstreit@gsa.gov> 08/16 10:36 AM >>>

Has anyone worked with ALLClear?   This is a flowcharting tool I evaluated
some years ago that has a syntax for describing flowcharts. Semi-colons,
commas, and other punctuation marks denoted different flowchart symbols. If
this or some other scheme was adopted as a standard, then a
visuall-impaired person could generate flowcharts, as well as interpret
flowchart information!  Thanks, Len for providing the link to the latest
version of the software:
http://www.spss.com/software/allclear/

Karl Hebenstreit, Jr.
US General Services Administration
Center for Information Technology Accommodation
http://www.itpolicy.gsa.gov/cita


---------------------- Forwarded by Karl F. Hebenstreit Jr./MKC/CO/GSA/GOV
on 08/16/99 10:27 AM ---------------------------

From: <w3c-wai-ig@w3.org> AT internet on 08/11/99 10:51 AM

To:   w3c-wai-ig@w3.org AT INTERNET@ccMTA-GEMS-MTA-01
cc:    (bcc: Karl F. Hebenstreit Jr./MKC/CO/GSA/GOV)

Subject:  How to describe Flowcharts, Schematics, etc



Most image on the web are decoration or icons with simple meanings like
"next page".  so ALT text and long descriptions are relatively
straightforward.

But some images convey information.  For example,

A simple linear sequence, like a flow chart with input going through a
series of processing stages to result in an output.

A tree diagram, like a  company's organization chart.

A more general diagram showing a bunch of interconnected objects, e.g. a
schematic diagram or an electronic circuit.

The most complex is a 3D machine, in motion if you want to make it even
harder.

Are there any guidelines on how to describe these diagrams?

For example, you could use lists and nested lists for linear sequences and
trees respectively.  Or you could use prose.  More general diagrams are,
well, a more general problem.   What techniques are best for what purposes
and audiences?  What's good wording, especially for prose decriptions?

I'm mainly thinking of speech output here, since that's what most blind
surfers will be using, rather than Braille or tactile graphics.

This is no doubt hard to encapsulate... at some point you just have to get
a skilled technical writer, especially for the prose versions...

Len
-------
Leonard R. Kasday, Ph.D.
Universal Design Engineer, Institute on Disabilities/UAP, and
Adjunct Professor, Electrical Engineering
Temple University

Ritter Hall Annex, Room 423, Philadelphia, PA 19122
kasday@acm.org
(215) 204-2247 (voice)
(800) 750-7428 (TTY)
Received on Wednesday, 25 August 1999 14:11:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:33 UTC