[Accessibilite] Re: Lu dans Communications of ACM: Why is Accessibility so Hard?

[Samuel Thibault <samuel.thibault AT ens-lyon.org>]

Bonjour,

Samuel Thibault, le Sat 17 Nov 2012 20:45:03 -0700, a écrit :
> C'est donc dans Communications of ACM que Vinton Cerf en personne fait
> un constat sur les difficultés d'avoir des logiciels accessibles:

Voici ci-dessous (en anglais) le contenu du texte. Pour info, c'est
converti depuis un scan à l'aide du logiciel libre tesseract, j'ai
juste corrigé un "ChQi.C€S." en "choices.", je n'ai pas relu le
reste, mais vu de loin ça n'a pas l'air horriblement mal converti.

Samuel

Why is Accessibility so hard?

I sometimes think that, of all the
disciplines, ours ought to be the most
effective at adapting to the varied
needs of users, including those that are
challenged to interact with computing
systems in one way or another. From
low to no vision, deafness or hearing
loss to carpal tunnel syndrome and
various other physical limitations, we
really should be able to configure our
software to adapt. And in many cases,
some very useful, clever, and general-
purpose software adaptations have
been achieved. But the problem per-
sists, and it is still not the case that one
can hold high expectations of acces-
sible adaptation for a random applica-
tion that happens to become necessary
or, at least, of high interest.

 I think I understand some of the
problem, but this column is an attempt
to begin a dialogue about improving the
state of accessibility in our field. This is
not only important from the purely ethi-
cal perspective, but it is also pragmatic
given the demographics of our society
and the increasing incidence of need
for accessible applications. We are an
aging society and we are welcoming
home many wounded warriors with the
need for assistive response, to mention
only two obvious beneficiary groups.
One reason this seems to be so hard is
that software has unlimited variations
and interfaces to applications can take
virtually any form. Moreover, we are ex-
tending the modalities of interaction to
include speech, gestures, mice, touch-
screens, other “pointers,” keyboards,
and so on. We have Web-based appli-
cations that take advantage of a wide
range of presentation and interaction
choices. Not all applications take into
account the need to offer distinct and
configurable user interfaces and even
when some or many such adaptations
are offered, some work a lot better than
others. The other side of this equation is
that the users also manifest unlimited
variations in their abilities and it seems
unlikely that programmers can be fully
cognizant of the nuances of each.

Another theme is the proliferation
of platforms through which we may
interact with computer—based services
and applications. It becomes increas-
ingly difficult to design in detail every
mode of interaction, including acces-
sibility variations, for every platform
and application imaginable. And even
if our imaginations were that good,
someone is bound to invent a new ap-
plication requiring assistive responses
that we have not thought about before.

One popular tactic has been to try
to create general-purpose tools such as
screen readers to assist blind users or
automatic captions to help deaf users.
Another tactic is to “parameterize” the
interfaces so users can pick and choose
the variations best suited to their needs.
In my experience, the range of param-
eters devised is fairly large and it is easy
to get lost in selecting configurations or
even anticipating how well they will fit
user needs. Still, these tactics seem im-
portant for practitioners to apply when
appropriate. The challenges strike me as
fundamental, given the range of needs
and potential interface designs.

This is by no means a new problem.
There cannot be much debate that pro-
grammers and user interface (U1) and
experience (UX) experts need to think
fairly broadly and deeply about poten-
tial use cases before settling on an in-
terface design. While the use of librar-
ies intended to confer “accessibility”
on arbitrary applications may be help-
ful, it seems to me that no amount of
automatic adapting will make a poorly
designed interface accessible. For
some of the same reasons that security
ought to be “built in” to the initial de-
sign, so should accessibility. If UI de-
signers had to try their designs while
blindfolded or use their applications
with the sound off, they might gain in-
sights into the nuanced demands that
accessibility places on good design.

One feature of good interface design
is anticipating what the user is likely to
need to do next and to prepare for that.
A similar notion might inform thinking
about accessibility. One is struck by the
seemingly impossible challenge faced
by blind users and UI designers for
them. In the Web-based world, two-di-
mensional displays, touchscreens, pop-
up windows, drop-down menus, color
highlighting, and other signals seem
utterly out of reach. One must think
how a user interface will behave when
it is serialized for audible presentation.
In addition, consistency of format and
audio feedback from screen to screen
also seems like a helpful philosophy.

I would like very much to hear from
ACM members, SIGs interested in this
space, UX design experts, as well as us-
ers of accessibility features about their
experiences and their ideasf‘ Somehow
we must find ways to approach this
problem with a richer combination of
design principles, pragmatic tactics,
and artful implementations than we
have in hand today.