Re: skepticism about generic access solutions

[Alessandro Rubini <rubini pop systemy it>]

LC, I understand your concerns about this issue, but I suspect they
are mainly the result of a misunderstandment. Discalimer: I am not VI
so I might misunderstand part of the issue.

I don't think Paolo or others are advocating the GUI as the ideal
computer interface for VI people. I feel it more like "since users and
developers are moving more and more towards GUI's, let's try to make
the GUI accessible in the best possible way". Sure not everything is
moving to GUI mode (see other messages in this thread), but
functionalities targeted at the general public definitely are.

> But are there really such interfaces in the real world that operate
> apart from text?

No. And, in practice, even the graphic interfaces are going back to be
very text-based. Nowadays the plethora of unintelligible icons use
to write out their name when you step on them with the mouse. There is
text to support the silly little drawing. Then, menu's are text-based, buttons
are text-based (as iconized buttons are being textualized), ...

Scrollbars and other items are not text-based, but they are usually
not vital to program operation.

Let's enumerate the assumptions you don't agree with:

> 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

There already is a set of such components. They are buttons, menus and
so on. And no, they are not optimal for all groups. However that's
where the market is going. Even though I greatly prefer text-based
applications, sometimes I am forced to use graphics as some feature is
only available in that form. If such applications can be easily made
accessible, that's much better than being forced to write a new
text-based application.

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

Yes, as long as the application is based on a toolkit (and all
applications are based on a toolkit, as already outlined) it uses
those components and not new ones (also, people is becoming used to
thos components and won't easily enjoy new "abstractions" being
introduced too often).

> 2)  That such an unwieldy scheme would actually save time and effort,
> because, supposedly, you would not have to modify the application.

Yes. If the basic GUI components are made accessible, that is
independent of the application. If the ideal user interface for VI
people is different, you'd need to write a new application (you won't
be able to modify existing apps to make the ideal for both worlds).
So it's a good step ahead if every app is at least useable, even if
not optimal. New optimal application will be written if there is
enough demand, but this rewriting will always happen at a later time,
if it happens at all.

> 3)  That such a scheme would lead to "the possibility of adapting the
> interface to different users' requirements without changing the
> underlying application",

Same as above: not optimally, but much better than the current status.

Sure, the "accessible toolkit" can only make accessible well-written
applicatins, but since the issues are in general related to "good
design", bad applications will die anyway in favour of good ones (I'm
repeating someone else's point here).

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

You are right, but sometimes you need something that is only available
in GUI mode. Despite the good Unix tradition you rely on, the quality
of available software is decreasing, as the sudden success of Linux
brought in several new programmers, and most of them don't have the
necessary Unix background. We must expect a huge lot of new free
software, but not always as well designed as it should be. So, while
gdb runs in text mode *and* through a graphic frontend, next year's
new application to handle automatic car repair (or whatever) may well
be GUI-only.

Summarizing, while gspeech won't be the most desirable accessible
interface, being able to hook speech to one of the most used toolkits
is a huge step ahead because it allows new technologies to be used as
soon as they are released (though sub-optimally). Yes, I prefer
lynx to mozilla, but sometimes you have no choices.

/alessandro