[Blindmath] How useful is a GUI to blind users?

Sat Jan 7 20:13:29 UTC 2012

Hello,
An interesting question and one which probably doesn't really have a 
straight forward answer. I will try and keep personal feelings out and 
present arguments either way.

Firstly it might be worth considering whether users, including blind users, 
are actually still familiar with command line applications, if everything 
else they use is a GUI then the command line system may seem foreign. That 
certainly could be the case for users of Windows which is the vast majority 
of computer users but may be less of a case on Linux where the text console 
is still very alive.

Yes using simple command line interfaces probably will make certain aspects 
of programming easier, but there may also be areas which could catch you out 
and turn out to be harder. The big advantage as you have suggested would be 
that there is no access bridge required and no external libraries to 
include, although you may want to include some extra libraries as I believe 
there are some which aid in command line interface creation.

Where I do have my doubts, could a command line interface really be as rich 
and helpful and easy to use as a GUI? The GUI has many types of controls 
which can lead you through what you are doing. You identified the file 
dialog as one, however there are also things like combo boxes and lists (eg. 
what shapes can one include, well they are all shown in the combo box). 
Menus are also another useful feature, I know the task I want to do, but 
what does the software call it and how do I get at it? Looking through the 
menu I will be able to find it. Then there is for you things like user input 
validation, with a combo box or a selection list the user cannot insert 
invalid data but if they just freely type the input then they can enter what 
they like and you need to validate it and let them know why it is wrong. 
Also there is the issue of knowing how to use the system, instructions need 
to be clear particularly for those where all options are given as command 
line arguments as the application has no chance to tell the user how to use 
it before they start it. I am sure that many of these issues can be 
overcome, for example having suitable help available and may be by using 
some of the libraries available for assisting in commandline interface 
design.

I am now going to expand this from "command line" where one does prompt and 
reply to what I term "text based" where one can do much more advanced stuff. 
You may want to look on Linux to see what sorts of things are done, although 
I will explain some of them. First thing which comes to mind, specifying a 
file name, well tab completion can be really helpful here, even Windows has 
this in the command prompt. However tab completion can be used for much 
more, in the prompt and reply session the user might be able to see the 
options available by pressing tab, if they have partly entered their reply 
then the options beginning with what has been entered could be shown and if 
only one matches then it could be fully completed. I think it can even be 
done for command line arguments, however I think it might be shell specific 
(eg. I think it requires bash or ZSH) and so probably it cannot be done for 
windows.

I previously mentioned about combo boxes and lists, well there are many 
Linux applications which are text based and still use lists, menus and other 
types of controls. The issue with some of these applications though can be 
whether the screen reader can follow the highlight of the selection. Some 
applications move the cursor to the position of the selected item, others 
just use a highlight and keep the cursor in one place on the screen. Speakup 
which is a screen reader for the Linux text console has a number of tracking 
modes which the user can toggle between to try and work with the various 
types of application. This is certainly an area where an accessibility API 
helps, it presents the selection to the screen reader in a nice, definite 
and consistant way. Also it should be noted speakup is a screen reader 
specifically for the text console, many windows screen readers obviously 
focus on GUI accessibility and so can be quite clumbsy at best for working 
with these types of text based applications. In some cases they can even get 
the content of the command prompt wrong, as an example voiceover on the Mac 
can misread the content of a line in vim (the text based vim, not macvim) if 
you have cursored down and up quite a bit. While this seems to be quite 
negative, please don't take this to mean that all text based applications 
using these more advanced interfaces are inaccessible, in fact many are 
perfectly accessible and usable (eg. on Linux applications like lynx, vim, 
alpine, nano and many of the menu driven helper applications of the GRML 
distribution work fine with speakup). I guess my main message here is it may 
not be quite as rosy as you may first expect.

Now I know it has been mentioned you can have shortcut keys in a GUI but not 
in a text based application, well that is wrong, you certainly can have 
shortcut keys in text based applications. As some examples there are 
applications like the vim editor, alpine/pine email clients, lynx the web 
browser and if you have three or more hands and the ability to press half a 
dozen or so keys at a time emacs which supposedly can do almost anything and 
has an extension which gives built in speech output (emacspeak).

I hope the above has been useful. The only other thing I will add is, trying 
to achieve cross-platform accessibility is really hard and it is something I 
have struggled with as well. Normally you have to make a compromise 
somewhere (eg. Java swing is easy to develop with but may be hard for the 
user and may not be perfect in the results, SWT I think you know the issues, 
the command line you are going down a different route to most people and 
still results may not be perfect, web based can be good but then you have 
the hastle of either hosting it or getting the user to run it locally and 
then connect to it or you could just go for supporting one or may be two 
platforms and using either the native libraries of the platform or a third 
party one like QT or GTK). Personally my views for developing with Java go 
towards either SWT or web based applications if you want cross-platform 
accessibility.

Michael Whapples

-----Original Message----- 
From: Richard Baldwin
Sent: Saturday, January 07, 2012 5:45 PM
To: BlindMath Mailing List ; accessibleimage at freelists.org
Subject: [Blindmath] How useful is a GUI to blind users?

It occurred to me the other day that prior to the advent of the Graphical
User Interface (GUI), the user interfaces for all programs were accessible
for blind users so long as they had a screen reader that would speak the
information displayed on the command-prompt screen.

For those who are too young to remember, programs in that day prompted the
user for input and the user responded in a back-and-forth dialog fashion.
Once all of the input data was provided, the program ran and did whatever
it was supposed to do.

Another way that information was provided to the program was in the form of
typed information (commonly called switches) provided by the user when she
started the program running. Batch files were often created with a simple
text editor to make this procedure less prone to typing errors.

The one area where I see the GUI being particularly useful for a blind user
is the file selection dialog. The use of the GUI dialog eliminates the
requirement to type long path and file names. However, if the disk is
organized in such a way as to keep the paths short, even this doesn't
appear to be a significant advantage.

For those who don't know, and without getting into the technical details as
to why, there are major problems associated with creating accessible user
interfaces when programming in Java. Using the SWT to create accessible
user interfaces significantly reduces the power of the Java programming
environment because it precludes the use of many excellent programming
libraries.

This causes me to wonder if, for those programs that are primarily intended
for use by blind and VI users, it might make sense to go backwards in time,
forego the GUI, and write those programs using the "old-fashioned" prompt
and reply style of user interface. I would be interested in seeing some
discussion on this topic.

Dick Baldwin

-- 
Richard G. Baldwin (Dick Baldwin)
Home of Baldwin's on-line Java Tutorials
http://www.DickBaldwin.com

Professor of Computer Information Technology
Austin Community College
(512) 223-4758
mailto:Baldwin at DickBaldwin.com
http://www.austincc.edu/baldwin/
_______________________________________________
Blindmath mailing list
Blindmath at nfbnet.org
http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
To unsubscribe, change your list options or get your account info for 
Blindmath:
http://nfbnet.org/mailman/options/blindmath_nfbnet.org/mwhapples%40aim.com 