Accessibility Matters - The Value of the Right Script

I am an advocate for accessible design by mainstream developers – I appreciate when everything I need works and is labelled nicely. But I've recently discovered that even the most accessible programs can require some further adaptation.

Such adaptations are known as scripts and are specific to each screen reader. They allow for hotkey access to common application functions or can be used to display most-needed information in a quickly readable format.

Skype, an application for audio, video, and text chats is pretty usable but a bit cumbersome without scripts. Whilst in a text chat window, a user without scripts could get to the message history, but would have to press tab many times and then navigate the list with the arrow keys. With a script, a user can press the alt key and the one through 10 on the number row and hear the last 10 messages in descending order of receipt. It makes the process much more efficient. J-Say, the bridge application I wrote about last week, is a much larger set of scripts for the JAWS for Windows screen reader.

I enjoy using scripts for several mainstream applications. JAWS, Non-Visual Desktop Access, and Window-Eyes all have them. They can make computing an easier process. But I often questioned whether or not they just let developers off the hook. After all, isn't a script specific to a particular screen reader just a way of letting a developer get away with substandard design?

It turns out I needn't have worried, for the most part. I spoke to Doug Lee, a scripter for several screen readers. He scripts professionally, but is best known in the blindness community for his voluntary scripting with Skype and Teamtalk. He believes that scripts can serve two purposes:

1. Alert a developer to an existing problem; and
2. Provide an blind end-user the closest thing to a glance at the screen as possible

The first goal was a surprise to me, but Mr. Lee was adamant that he is always happy when a developer makes a change that allows him to eliminate 500 lines of his code. He also said that a truly bad design can mean that no scripts can save it and the developer will have to make serious design changes before he can proceed.

There's also the possibility that scripts can provide functionality a developer wouldn't have thought of, or that wouldn't be necessary for most users. This is where the idea of simulating a glance comes in. For instance, Non-Visual Desktop Access and JAWS each have options to instantly provide optical character recognition. Keystrokes to announce the time remaining on a Winamp track might not be required for most users. Pulling the five most common fields that a call center operator might need into one viewer improves efficiency for a blind employee but again might not have been considered or required by users who can pick out that information visually.

All told, I learned something in my discussions with Mr. Lee. I saw scripts as an enabling mechanism that was an effective Band-Aid solution for decent but not fantastic application design. I worried they held back a movement for usability for all. It turns out that they provide the same information but in a way their user base can make better sense of and use.

Some scripting points out design flaws, but providing scripts and seeking universal access are not in fact competing goals. After all, accessing something differently than sighted users doesn't make that form of access wrong.