When a report arrived in the office the other day entitled Access to graphical user interfaces by blind people it raised a few, guiltily stifled, chuckles. But for the blind and partially sighted, the advent of graphical user interfaces, with their multiple windows, drag-and-drop operations and cryptic icons has proved, shall we say, disadvantageous. The problem is compounded since keyboard skills needed for computing have made the industry a natural choice for a good number of blind workers. In the past, a number of ingenious devices have been developed to cope with the character-based interface – Braille outputs, for example use matrices of rapidly-shifting pins to represent the text output, while other users prefer to use speech synthesis to read back the contents of a screen. In pre-mouse days absolutely everything could be accomplished through keystrokes. But today’s industry is becoming increasingly reliant on the visual metaphor for data manipulation and this reliance is likely to increase: drag and drop and visual linking are still in their infancy in the average office. Already, the old techniques do not suffice, so the visually impaired are faced with either having to stick with MS-DOS version of software while the rest of the office moves to Windows or finding some way to work with the new software. The aforementioned report, written by the European Community’s GUIB textual and Graphical User Interfaces for Blind people project as part of its TIDE Technology Initiative for Disabled and Elderly people initiative shows that sticking with MS-DOS is unlikely to work in the long term. A survey discovered that only 27% of software developers working on new graphical user interface-based offerings plan to have a text-based alternative.
Glancing The problems the blind encounter when facing a graphical user interface are split evenly between the input and output. We’ve mentioned some of the input problems already – clicking and dragging requires good hand to eye co-ordination, for example. It is the output side that perhaps presents the more subtle difficulties. Graphical applications are often littered with multiple text and graphics windows and users are expected to to select the required information by glancing around the screen. At the same time the graphical user interface includes a lot of control information, such as the cursor, scroll-bars and icons for resizing windows – of these graphical elements, the report asks: what can or should be converted into text form so that it can be presented as speech or Braille and what can, or should be presented to the user directly in a graphical form and how can that be achieved?. There are several plausible ways for getting information across. One of GUIB’s first productions is the Guide display, a workstation that, ironically enough, is much easier to describe in pictorial form. Guide has a standard keyboard, in front of which sits a two-line, 80-character active Braille display. Above each Braille character is a small button and pressing on this moves the cursor to this point in the text. To the left of the keyboard is another Braille-and-button line, but this time vertical. This can be used to display an overview of a window’s contents or represent a vertical scroll bar – pressing a button in the latter mode brings up the appropriate lines of text on the horizontal display. As an alternative method of navigation, Guide has a pressure-sensitive pad located. Light finger pressure moving around on the pad will change the lines of text showing on the Braille display.
By Chris Rose
Heavier pressure will move the application’s mouse pointer to the postion indicated. A couple of conventional mouse buttons are mounted below the pad – double clicking will select text in the conventional way and text can also be highlighted by double clicking on the Braille display’s button. And if you are wondering how you highlight a Braille character – dots 7 and 8 of the display are raised in addition to the normal character pattern. At any time a voice synth can be used to review th
e current display’s contents, but most things can be assigned Braille representations in one way of another: thus a scroll bar with drag box becomes:
<——–O—–>,
while a Yes, No Cancel dialogue box with buttons becomes:
Content from our partners
[Y
