Re: [user-assistance-discuss] Thoughts on Graphical Callouts

[marbux <marbux@gmail.com>]

I apologize for my absence from this discussion. I encountered some medical
issues that required my undivided attention. I will work on catching up over
the next few days.

[More]

On 5/8/06, Jeremy H. Griffith <jeremy@omsys.com> wrote:
>
> On Mon, 8 May 2006 16:19:01 -0700, marbux <marbux@gmail.com> wrote:
>
> Thank you for this thoughtful post.


I thank you as well. A frank discussion of issues and potential solutions is
normally far more useful than denials that one is positioned to contribute
to those issues' resolution. Your frank and thoughtful post lights the path.

[More]

I always considered
> myself a proponent of disabled-access rights, but when I
> found myself in a wheelchair for several months it was a
> whole new revelation.  Who'd have thought a 3" threshold
> was a barrier as effective as a brick wall in keeping a
> person in a non-power chair out of a house, or store, or
> office?  Broken sidewalks, missing curbcuts, too-steep
> ramps, all became showstoppers.  And I live in a town
> nationally known for its positive intentions for access...
>
> I can only imagine now, being sighted, what visually-
> challenged Help users experience.  But I suspect that
> the alt attributes added to graphics are hardly up to
> the task of replacing the functionality of the graphic.
> How many of us use alt="block diagram" and consider
> ourselves done?  I'm guilty myself.
>
> IMHO, you are correct to say that the Help needs to
> work without the graphics, so that the text contains
> a complete description.  Then adding graphics back
> would be harmless, meeting your criterion of purely
> "decorative" use.  But we may indeed need a period
> in which we simply exclude them entirely to reach
> that point of effective communication.


I was not easily driven to my conclusion that a return to first principles
is necessary. But making it easy for the software industry to ignore the
needs of disabled persons is only part of a general deterioration in
documentation quality enabled through typographical gadgetry. When
enablement of gadgetry takes precedence over communication  content and
communication of it, it should a wake-up call for all concerned.

[More]

Of course, one can easily come up with examples of
> tasks where visual information is essential.  This
> may apply to work which visually-challenged people
> simply cannot perform, such as airplane pilot...
> Likewise, in my wheelchair, I can't expect to be
> considered seriously as an applicant for an iron-
> worker's job in constructing an office tower.  But
> there are fewer such sitiations than we think.
> There are, for example, blind doctors and lawyers.


One inspiration who helped me endure 27 months of combat service in Viet Nam
without ever knowing it was a childhood friend's father. He was the county
prosecutor. He managed his office, prepared cases, and prosecuted them from
his iron lung. He always had time for me as a child. I now think of the more
than 1-1/2 years I spent in hospitals recovering from my Viet Nam experience
as my life's largest confrontation with reality. What a sea of disabilities
I was exposed toI  I lived in an ocean of young men laid low in their prime.
Paraplegics, quadraplegics, men with jaws blown away, the blind, the deaf,
men who had lost their genitals, the otherwise afflicted. Many of the other
patients became close friends during that time. The notion that they should
not be enabled to live their lives to the fullest -- including their use of
computers -- is scarcely defensible, hence the squirminginvolved in this
discussion.

Once sensitized, it is difficult to ignore the societal obligation to
provide the disabled with the means of survival and a fruitful life. Mankind
is not a species of loners; our species is communal. There was a long
period  when Mankind had scant choice but to abandon those with extremely
serious disabilities. But I suspect that one of the greatest traits
distinguishing humanity from other life forms is our commitment, wisdom, and
resources that we have devoted over the eons to caring for each other
despite disabling conditions.

I have no doubt that those on this list who would shirk even considering
that responsibility have scant concept of just how offensive and morally
reprehensible their words are. It is a commonplace for those whose lives
have never been severely affected by disabilities not to comprehend the
wisdom of the ages: There but for the Grace of God go I. But comprehend they
will before their lives end. The only ones who can escape that awareness are
those who die sudden deaths. And a very few complete idiots.

[More]

>The custodians of that oral tradition at the time,
> >the journeyman typographer...
>
> Indeed.  And I was one of those once too, coming
> from tech writing on my way to programming in 1975
> by way of software that used a mainframe to drive
> a photocomposer.


Hail, brother. ITU 634 was where I spent most of my time, but I tramped for
a few years.

[More]

I consider that the first principle of tech writing,
> not only of typography.  Indeed, in 1960, one could
> not get a job as a TW without demonstrating an ability
> to use the written word that seems all too rare today.


There is a certain seductiveness in gadgetry, which is why many software
developers engage in the marketing device of feature bloat. In many ways,
the generally higher quality of documentation in the past was the product of
a clean division of responsibilities between word smiths and typographers,
as well as other specialties, each focusing on an area of expertise.
Regrettably, the notion that the Jack of All Trades can be competent in any
of them has been only one bit of the foolishness wrought by software
marketing specialists. "Where do you want to go today," indeed. It takes far
more than an ability to operate a mouse and a keyboard to make a journeyman
craftsman.

[More]

>Flashy graphics were not needed before and they are not
> >needed now. Only Help authors "need" them...
>
> And authoring-tool vendors who think having the flashiest
> new features is the best way to sell software.   Too bad
> they are often right, eh?


Precisely.

[More]

>"Encouragement" is scant comfort for the disabled worker
> >whose documentation needs have been ignored by software
> >and Help developers. Employers who reject, demote, or
> >discharge employees for such reasons act unlawfully and
> >are liable for damages.
>
> And such actions are increasing in number.  Then there's
> 508, significant to anyone who sells to the federal gov.
> Which is practically everybody, in high tech.


Maintaining awareness of the business environment and adapting to its
changes is generally the wiser course. In Viet Nam, I was fortunate to have
enough intelligence not to ask, "where" when someone hollered, "Duck!" (We
were not there to observe waterfowl.) On this mailing list, there are those
who still have not realized that they have it backward on who the dinosaurs
are. To complete my unashamed mixture of metaphors, occasionally in life and
in business the wiser course is to focus on survival rather than developing
sighting reports for the Audubon Society.

[More]

>This discussion would be more useful were it focused on
> >how to programatically ensure that Help authoring systems
> >produce *only* handicapped-accessible Help files.  I have
> >proposed one solution. Do you have another?
>
> Not yet, but I certainly see the problem.  I'm not so
> sure there's a tech fix to it.  You can exclude graphics,
> but how can you ensure that the text provides an adequate
> explanation?  And if you can't, what happens when legacy
> docs lose graphics and become "compliant", with no added
> text explanations?  Very sad...


There is no way, I suspect, to ensure that text provides an adequate
explanation; however, it is possible to design software so that at least
some text is entered in required fields before a workflow is allowed to
complete. Why, I have even encountered web forms that require a city name to
match its proper ZIP mailing code, if you can imagine that, which places a
research duty on those like me who ordinarily would rather not entrust
strangers with my mailing address.

That illustrates a principle of office system design that I have used for
many years: The right way should be the easiest way. So long as Help file
conversion software is willing to complete processing of graphic image
coding without "alt" tags and without those tags being occupied by text, the
easiest way is the wrong way: Don't bother with accessibility issues.

Depriving Help authors of gadgetry that frustrates first principles should
do wonders in helping them focus on the essentials of their craft, the
development of information and how to communicate it effectively.  Designing
for accessibility is a cart and horse issue, not a chicken and egg problem,
and -- in the context of a standard for converting document files in many
formats to documentation formats -- designing for accessibility most
certainly is not the buck-passing of responsibilities espoused by some on
this list. Many wounds can be prevented; we need not depend entirely on the
Band-Aid solutions they propose.

[More]


>A better approach might be to encourage some key accessibility
> >software developers to participate in this proposal's discussion.
>
> You clearly know people in the community; are you willing
> to issue invitations to those likely to be interested and
> helpful?  That would be a very good start.


I have the means of enlisting aid. My big question at this point is whether
we need to deploy a combat team to clear the way for those with technical
skills. So my task at this stage is exploratory, a needs assessment.

[More]


>No personal disrespect intended, but this proposal involves
> >niche industries that have operated outside the law and the
> >bounds of ethical behavior for many years. A strong shake-up
> >is long overdue. The Help authoring system development industry
> >should not require a court decision to recognize the economic
> >foolishness of delivering products that make it easy to violate
> >the law.
>
> Quite right.  And this initiative is an excellent opportunity
> to do just that.


Thank you for your informed concern. I share your assessment. Long ago, I
learned to select pressure points carefully. This is one of those situations
where a little snowball will likely be a full scale avalanche by the time it
reaches the bottom of the mountain.

Best wishes, Jeremy. I will be around.

-- Marbux