Re: skepticism about generic access solutions (was: issues with XWindow)

["L. C. Robinson" <lcr cyberhighway net>]

On Tue, 24 Aug 1999, Jason White wrote:

> It is not a question of providing a "text mode", but rather of
> facilitating the construction of a braille or auditory interface,
> which is not the same as a visual (albeit text-mode) design.

But are there really such interfaces in the real world that operate
apart from text?  If one designed one, what would it be like?
 
> Several reasons have already been advanced in favour of the argument
> that a generic solution, operating at the level of the user
> interface components rather than the application itself, is
> preferable. To summarize, these include: (1) the ability to update
> the application without having to modify the access solution (and
> without maintaining two separate interfaces); (2) the time and
> effort saved by not having to modify the application itself; and (3)
> the possibility of adapting the interface to different users'
> requirements without changing the underlying application.

I think that this is a fairly good representation, in a nutshell, of
the vision that has informed this thread and another recent one.
Jason has finally made the the concepts explicit enough to warrant an
examination.  Thank you, Jason.  Some things have been bugging me
about the whole concept, and I think they warrant some skepticism --
here's my attempt.  I believe that these goals hide some interesting
and questionable assumptions that I hope to make explicit; they are:

0) That you can somehow abstract a reasonably comprehensive set of
"user interface components" that can effectively operate independently
of the application itself, and still have an optimum user interface
for all groups, without sacrificing usability for one or the other
group.  It seems to me that for this to work, there would have to be a
one to one correspondence between the visual elements and a possible
textual representation of them.  We already know that there is not any
such direct correspondence between verbal languages, let alone two
very dissimilar perceptual realms.  We must also assume that
programmers could easily grok the necessary abstractions and
correspondences, artificial though they may be, and all without
passing on the problem of making the connections to the users.  Wow.

1) That when updating an application, the changes would stay within a
carefully limited set of visual and language constructs comprehended
by the interchangeable access interface specification.  But we know
that human communication doesn't work that way.  Programmers would
never stand for that kind of restriction on their creativity and
expression.  Ultimately, the effort to make it work would result in
the proliferation of "user interface components" to an impossibly
complex toolset (not that such is not already a problem in some
programming environments).  The only way to enforce such a thing would
be by a heavy handed and stifling government or corporate bureaucracy:
not available in the international open source culture, thank
goodness.

2)  That such an unwieldy scheme would actually save time and effort,
because, supposedly, you would not have to modify the application.  Of
course, in the real world, attempts to accomplish this actually result
in the access layer trying to catch non-conforming events, and gluing
on application specific modifications on a quasi external level, aka,
flaky, complicated kludges.  I have already commented on the
complexity in the interface layer that would probably result, and
would work against this goal, and there are other associated problems.
In the open source culture, OTOH, we are used to duplicate and
parallel efforts: that's how we guarantee the best quality and
innovation, and tons of experimentation.  This one appears to me to be
a form of the politics of scarcity and control, and is the only real
justification for the whole effort -- rather foreign to the dynamics
of Open Source.  Nevertheless, it will be tried in the hacker culture
-- probably repeatedly -- and perhaps has been in the past.  [Anyone
know the history of such attempts?]

3)  That such a scheme would lead to "the possibility of adapting the
interface to different users' requirements without changing the
underlying application", ie, that we would achieve greater flexibility
by adhering to such a tool set, rather than the (more likely) reverse.
And don't forget the price you may pay by shutting out programmers who
do not have the skills to use such restrictive and arcane
abstractions.  Not that such would be attended to by most of them.

> The important point is to move toward techniques of user interface
> design which ensure that all of the necessary semantics are
> provided, upon which different concrete interfaces (braille,
> auditory, etc.) can be constructed.

These are glowing, and very appealing promises, and have been
effectively sold to a large segment of the computing world.  Who would
not want such an attractive computing utopia?  But like most utopian
visions, it rests on assumptions that range from questionable to
dubious, to ridiculous.  And what is the probable price of chasing
after a faulty utopian vision?  Can we find any real world examples?
I'll leave the answer as an exercise for others.

In the highly developed world of Unix computing (which, contrary to
some marketing hype, has always stayed far ahead of the M$ world), the
real solution is both well established and simple.  Either build
parallel text and GUI versions of applications, where appropriate, or
build programs that sense their environment and operate in the
proper mode.  Perhaps such direct approaches seems less elegant
to those used to other approaches prevalent in systems that are
textually challenged, but they are time tested and reliable.

Notwithstanding the above comments, I believe that a port of a good
win9x screen reader is probably ultimately desirable, if only to run
the win9x applications that will inevitably be ported to linux, via
the wine and willows type shared (dll replacement) libraries.  But I
have serious doubts about the scheme, in terms of creating new
applications.

I look forward to all your perspectives of these ideas; I'm certainly
no expert in these areas.  Some of this seems to be just obvious
common sense, or perhaps, nonsense.   And, no, I'm not advocating
cutting blinds off from anything.  I just believe in a different
approach to accessibility.

LCR

PS.  Please, Jason, don't take any of this personally.  I have been
debating this in my mind for many weeks.  You just stated things
clearly enough, in this last message, to crystallize my thinking.

-- 
L. C. Robinson
reply to lcr cyberhighway net

People buy MicroShaft for compatibility, but get incompatibility and
instability instead.  This is award winning "innovation".  Find
out how MS holds your data hostage with "The *Lens*"; see
"CyberSnare" at http://www.netaction.org/msoft/cybersnare.html