OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

user-assistance-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


On Mon, 8 May 2006 16:19:01 -0700, marbux <marbux@gmail.com> wrote:

>On 5/8/06, Paul Prescod <paul.prescod@xmetal.com> wrote:
>> Are you saying that a help authoring format SHOULD NOT support graphics
>> AT ALL because they are so often (in your opinion) misused?
>
>Yes. The problem is enormous. 

Thank you for this thoughtful post.  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.

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.

>The needs of handicapped end users have been
>all but ignored by virtually every Help system...

Sad but true.

>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.

>Software end users will not be inconvenienced by 
>returning to first principles of typography, conveying 
>the written word. 

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.

>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?

>"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.

>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...

>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.

>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.


-- Jeremy H. Griffith, at Omni Systems Inc.
  <jeremy@omsys.com>  http://www.omsys.com/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]