Re: skepticism about generic access solutions

[Charles McCathieNevile <charles w3 org>]

There are a number of functions that are now being provided through web-based
interfaces. This is because the web provides a classic example of an
extremely portable (albeit very limited) toolkit - although it is more
restricted than an X toolkit programmers value its portability enough to use
it.

Many of these tools are understood by designers to be graphic tools, used in
a graphic interface, and yet by following the standard rules which ensure
portability they work across different interafaces.

There is constant pressure for further tools which can be used across the web
- in other words an expansion of the available toolkit. Hence the rise of
Javascript and Java, and other even more restricted scripting techniques.

Some very good work has gone into platforms like Java, Gnome, and the X
window system itself, to ensure that it is possible to build accessible
applications - ones in which the GUI is simply one possible interface to the
software, and a text-based interface represents another, and a speech-based
interface represents another, and other interfaces can readily be constructed
if the interaction metaphors can be described.

This points to a world where two different approaches are possible. In one,
you can build a text-only application, or one which simply uses the most
primitive commands available to create a graphic-based application, or
whatever your own interface design medium might be, and not worry about
providing any other form of interface. This would seem, in virtually all
cases, a backward step.

In another approach, you can define an abstract layer between the application
and the interface. X provides toolkits which allow for this. It is usually
regarded as an integral part of good clean program design, and has meant that
it is relatively easy to port well-designed programs between one interface
metaphor and another.

There are extremely functional text-based applications for many tasks. Some
of these are designed to support an abstract interface, making use of
standard toolkits, and some of these are designed in such a way that this is
not practical. Similarly, there are GUI-based applications which are designed
using standard toolkits, which allow a relatively clean interface with a new
type of User interaction metaphor, and there are others which are cobbled
together in such a way that providing a new interface essentially reqires
rebuilding the software.

To ignore applications which are developed in a GUI world is to abandon
interest in the development of that world. Which closes off any chance of
returning and doing something other than saying "oh! If only you had worked
on standard toolkits, and assumed taht people would be interacting through
many different interfaces, it would now be a simple matter to use your new
software".

If a whole community turns its back on another community, those two
communities will not have much impetus (or even much ability) to seek to
accommodate each other. In an area such as programming applications, it would
be a great loss to the programming world if the blind community abandoned all
developing platforms, in part becuase there are so many skilled programmers
who are blind, in part because those people inevitably identify problems
which are not evident to sighted users who are pretending to be blind as a
mental exercise, and in part because a large motivation for ensuring the
continued accessibility of such areas as they developed would be gone.

In actual fact there is probably enough impetus to ensure that good
programming techniques are developed and supported in the complete absence of
blind users - similar needs apply to a large range of devices which sighted
users demand, such as mobile, or audio-based devices.

Nobody should be forced to live on the bleeding edge against their will, but
unless you can halt the progress of it, it is helpfl to try and guide the
devlopment in ways which are beneficial to everyone. I don't think the GUI is
the be-all, end-all interface - speech interface are just starting to become
a real alternative, and all the deaf people out there should be hoping like
crazy that those are being developed with a modular approach - but it is
certainly a rapidly growing area, and is seen as cool and sexy by working
programmers. It seems better to harness that energy and contribute to it and
provide a voice that speaks for your needs within that community than to be
cut out of it, and particularly to cut onself out by choice.

Just my little rant - I'm not sure if I'll get 2c for it...

Charles McCN



On Wed, 25 Aug 1999, L. C. Robinson wrote:

  On Tue, 24 Aug 1999, Alessandro Rubini wrote:
  
  > 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".
  
  That is obviously the hope and the vision, but it is at present a false
  hope, I think.  It is too late for most present X apps to meet this
  standard, even if it is feasible for future apps.  I only mention this
  because I have noted some misunderstanding among new blinux users, both as
  to the probablity and desirability of such access to old X apps.  Of
  course, many new gnome apps that are little more than text apps with
  decorations, such as menus, editors, and other text processing programs
  could work fine this way, as would many other apps where the programmer is
  just recycling old text mode concepts for the textually impaired.  But why
  should a blind user care about most of these yet future gnome clones of
  what already exists in text mode?  And any new apps that go outside such
  existing functionality are the very types of things that are less likely to
  work within a limited widget set, not to mention that many of them may be
  aimed at objects that are inherently inaccessible to blinds, such as
  photographs.  What does that leave?  Not much.
  
  I think it is very important to avoid distracting new blinux users with
  vague promises of vaporware functionality, which they usually don't even
  need, given the alternatives, when they really need to be concentrating on
  finding out about the thousands of apps that work for them today.
  
  > Sure not everything is moving to GUI mode (see other messages in this
  > thread), but functionalities targeted at the general public definitely
  > are.
  
  This is only partly true, and of little relevance, when so much
  functionality is available already in text mode, for blind people as well
  as others.  I know that the perception is that "everything is moving to GUI
  mode", but that is, in fact, far from the truth.  We are seeing the regular
  intoduction of new text mode apps, and of some that work in both text and
  X, and there is every reason to expect this trend to continue, and not just
  for techies.  
  
  > > 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), ...
  
  Yes, it seems that some programmers and users can't tell the difference
  between decoration and real functionality, and the result is sometimes
  interfaces that are rather cryptic.  In these cases, text interfaces are
  clearly superior.
  
  > 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.
  
  Yes, we all know that such widgets exist.  The question is whether they can
  really fill the demanding utopian role laid out for them.  Most are just a
  decorated recycling of ordinary text elements, and obviously these can
  work.  But what about the rest?
  
  > 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.
  
  Most of the time, a text based counterpart is available, but if not, the
  choice is not necessarily whether to write a new app, but whether to modify
  the existing code for text use: this may be simpler than making an access
  solution work with it.  You are right, though, for run of the mill apps
  that don't need to go beyond using a decorated text widget set, and that
  could turn out to be much greater than 90% of them.  Maybe we just need an
  ncurses (ncurses-tk?) add on to make visual decorations possible, without
  making them mandatory (switchable).  Another alternative that is already
  possible, is web or browser based applications, and they are already
  becoming commonplace.  But then these are fundamentally text mode
  protocols.
  
  > > 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).
  
  Of course you have heavily qualified the cases where this would work.
  I am sure a great many apps can fit within such restrictions (whether they
  should, is another matter).  Basically you are saying that it will work --
  iffff the programmer is willing or able to limit himself enough.  I
  maintain that most applications that will work within such restrictions
  will be little more than recycled text mode apps, and most of this stuff is
  already available in text mode.  Some have suggested that the development
  of new GUI mode apps will out strip the text mode eventually: a dubious
  claim at best, since it has not happened yet, even though we have had
  X-windows for many years.
   
  > > 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.
  
  But these "ifs" are precisely what is in question: can one really satisfy
  such requirements in a satisfactory way, with less work than writing a
  separate interface?  The experiment should no doubt be tried -- again.  I
  expect that it will work fairly well in the limited cases mentioned above.
  Web apps may be even better and easier to write.  We have been getting new
  tool sets for years.  If such a scheme is all that feasible, why are we
  still getting development on apps with both types of interface?
  
  > 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.
  
  Actually we have a number of on going projects where both text and GUI
  things are being developed or extended in parallel.  But yes, the GUI
  versions do often trail the text ones...  :-) 
  
  > > 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.
  
  The current status is excellent, and getting better all the time.  It's
  hard, I guess, to make the switch in thinking to a dynamic open source
  culture where you don't have to make do, and wait around for the
  proprietary vendor to do what you need.  
  
  > 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).
  
  In this context, "well-written" seems to equal "comforming applications",
  by definition.  We are asked to assume that nonconforming applications are
  automatically poorly written, and therefore will die out.  So anything
  innovative or creative that needs to go outside the toolkit is
  automatically junky?  But most tasks that people need done really are kind
  of mundane, so there is some truth to the above, and a successful tool kit
  could make life easier for lots of these things.  OTOH, these are the very
  things that are easy to write in text mode using a scripting language, and
  there are special script archives full of thousands of these things.  And
  yes, I know that many of these scripts run in GUI mode.
  
  > > 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.
   
  > 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.
  
  This is neither relevant or true.  We have always been sorting the quality
  stuff from the junk, and improving worthy stuff in between.  This sifting
  process is a neglected but essential part of the Open Source story.  There
  are huge quantities of junk that no one remembers.  That's a natural part
  of a dynamic growing process.  It will take a genius to build a truly
  usable access system that will not join the junk.  I hope the gspeech
  project is good enough to survive, at least for menus and the like.  Web
  based stuff is already credible, thus raising the bar, as does scripting.
  
  > 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).
  
  I hope it really can fulfill that promise: even if it doesn't, open source
  should make it possible to do a bit of tweaking, at least part of the time.
  
  > Yes, I prefer lynx to mozilla, but sometimes you have no choices.
  
  We always have choices, especially in the open source world.
  
  LCR
  
  -- 
  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
  
  ---
  Send your message for blinux-list to blinux-list redhat com
  Blinux software archive at ftp://leb.net/pub/blinux
  Blinux web page at http://leb.net/blinux
  To unsubscribe send mail to blinux-list-request redhat com
  with subject line: unsubscribe
  

--Charles McCathieNevile            mailto:charles w3 org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA