Hi, Here's an FAQ about an auxilliary command line interface as an access approach for blind people using GUI's. Scott PS If you would like to check out a demonstration, please let me know. You'll need telnet access. -------------------------------------------------------------------------- 1. What is an auxilliary command line interface (ACLI)? An ACLI is a type of access technology (AT) which can be used by visually impaired computer users to interact with various aspects of a GUI. The user enters various commands into the command line part of the AT and the AT then performs the requested actions with regards to the GUI. 2. Is the ACLI separate from a screen reader? The ACLI can be implemented in two different ways. One as a stand-alone piece of AT. In this case, the ACLI either produces direct voice output or text output which is then read by a screen reader. The other approach is for the ACLI to be built directly into the screen reader. 3. What kinds of problems does the ACLI address? The ACLI actually addresses a number of problems. The ACLI helps improve the efficiency of a blind person when both learning and interacting with a GUI. The ACLI can also help improve a blind person's understanding of each GUI. A key problem for a blind person interacting with a GUI is coping with the visual cuing that occurs in so many forms. A real basic problem is icons. The blind user often has to compensate by using documentation to learn of the existence, location and purpose of a location. Using an icon means having to remember the location and being able to move the focus to the icon. Use of icons can be a little more confusing when the same icon is used more than once on the screen. In this case, the purpose of the icon is conveyed visually by what other objects are nearby. For example, a right arrow icon could mean both next person or next screen depending on what the icon is near. Another example of visual cuing is color. Suppose that two buttons have the same label, but the backgrounds are different indicating different uses. In an ACLI, each button, icon, etc, has one or more unique command names. The command names can explain the purpose of each button, etc, and reduce the dependency on visual cuing. The ACLI can improve the efficiency of a blind person learning a new GUI. Instead of exploring the GUI which can often be incomplete or misleading if buttons are accidently missed or skipped. the blind user can just ask for a list of command names which helps the blind user get a quick overview of the functionality provided by the GUI. The ACLI can also improve efficiency by reducing both navigation effort and learning requirements. For example, instead of having to remember the location of a button in a GUI and then navigating to it, the blind user could just type the command name associated with the button. 4. Does this mean that a user will need to memorize many commands for all the various GUI's he uses? Actually, the ACLI can have various useful functions built into it to reduce the need for memorization. For example, the ACLI could contain a type of search engine. The blind user could then tell the ACLI to execute a command which contains the phrases "spouse", "first" and "name". The search engine could then search for the desired command. 5. Where do the command names come from? The command names and abbreviations need to be specify when the GUI is being developed. Probably, the developer doing the work would assign the command names and abbreviations for each button, etc. 6. Is there a way that the command names and abbreviations could be automatically generated? Doing this type of work automatically is currently ot very possible in most situations. For example, if the GUI is using a right arrow icon, the program would have to guess what a right arrow means. Does it mean "next"? Is it the "right" direction? Or in another situation, suppose that two button both have the same label, but in one case the background is green for "husband" while in the other case, the background is yellow for "wife". 7. How hard would it be for a developer to assign command names to buttons, etc? The developer could do this quite easily if the proper functionality is provided by the GUI software. For example, if MSAA or Java Access provided a slot in each button, etc, for command names, the developer would just fill in the slot with a string containing a command name and various abbreviation. The ACLI would then request the string with the command name and abbreviations when the GUI starts executing? 8. How would a developer choose command names? Guidelines for choosing command names would be helpful. Also, the command names could be reviewed as part of the alpha or beta testing of the software. Changing the commands would be quite easy since only the string needs to be changed. 9. Would assigning command names introduce the possibility of bugs into the GUI code? Actually, the possibility of introduce bugs into the GUI code is extremely unlikely. The string is used by the ACLI and not the GUI. This means that there's little chance of having the GUI make some wrong decision because of the command name string. 10. Would command name slots make programs much bigger? This is slightly technical, but in general, the answer is no. For example, suppose that each button, field, etc in a GUI has a slot for a string for command names. Let's say that the empty slot uses only 4 bytes (more bytes if the slot has a string). If a GUI hase 100 buttones, fields, etc, that would be an increase of only 400 bytes if none of the slots are filled. In a program of 2 MB, 400 additional bytes is a very small increase in size. 11. Could the user develop his own abbreviations or aliases for commands. The ACLI could provide a couple of approaches. One approach would be for the user to assign command names to macros. Another related approach could be for the ACLI to let the user assign commands to hot keys for each application. 12. Why would a developer take the time to specify command names? Well, basically there is self-interest or a company's interest. The developer could use the command names to create scripts for automating testing and debugging via scripts. Blind users are beginning to put more pressure on ADA Title II and III entities for access to information via technology. These entities will start choosing to purchase software which provides the needed accessibility instead of software which doesn't. If blind employees start demanding accessible software under ADA Title I, this will also put more pressure on developers to build accessible software. Other laws and regulations would add to the pressure. Using command names is probably the easiest way to do provide accessibility without introducing the possibility of bugs. An additional benefit to using commands names is that it would make it a little easier to determine how accessible a piece of software is. A separate program could analyze or monitor a GUI to see if command names are provided or not.