* The below document is a draft. It isn't yet ready for prime-time.
Please feel free to comment on it. I will revise it as suggestions come in. For instructions on how to make additions and corrections, see my document reviewer's page.
You were directed to this page by a blind or visually impaired person who is having trouble using software you design. The purpose of this letter is to help you understand how you can make your program accessible.
People with visual impairments either cannot read the screen directly, or they have difficulty doing so.
Instead, we use a screen access program. Colloquially, it's known as a screen reader. This software builds a constantly changing database of what's on screen called an off-screen model. Then, using keystrokes, the blind user is able to explore the model and interact with objects and controls.
The screen access software either displays parts of the screen on a Braille display, in larger print, or reads it aloud using synthesized speech. Today mostly software-based concatonative speech synthesizers are in common use. The synthesizer is a separate program, just as printer drivers are separate from the word processor.
Blind users typically press Windows keystrokes to accomplish a task. They will tab around dialogs, press the spacebar to uncheck a box, or use arrow keys to select radio buttons. They will use the PGDN key to scroll a document and F10 to pop up context menus.
Low-vision users might work with the mouse if the light is good and the magnification is right. But each partially sighted user is an individual, with his own preferred contrast, font size and visual ability. For many, vision fluctuates on a daily basis, so a person can see well one day and be nearly blind the next.
A large variety of standard but lesser-known keystrokes have been defined by Microsoft and make Windows by itself very accessible. For example, you can press F6 to toggle between the left and right-hand pane in a window or F2 to rename a file in explorer. Even someone who can use the mouse will frequently revert to these keystrokes rather than struggling to be sure they have clicked on the right thing. This is particularly true if the person is an experienced user and his vision impairment is significant.
Any program with a cursor is automatically more accessible because it is easy for screen access packages to track. The focus rectangle also makes Windows easily accessible, because the focus can be moved with keystrokes. Screen access programs monitor the keyboard and know when a particular key has been pressed. This enables them to take appropriate action. For example when I press CTRL-Home, my screen access program knows I asked the application to move to the top of the document. It is aware of the focus change, and if there's a cursor (insertion point) it can track where it's now landed. As I arrow about the document, it can read me appropriate information: characters when I press the right arrow for example, or words when I press the ctrl-right arrow.
There are also keystrokes to read important information, like the title bar of the currently active window or the previous sentence in a document one is proofing. Screen access software also lets the user move the mouse pointer with special keystrokes. The mouse can be moved by pixel, character, word, line and other user definable units. The mouse can be left or right clicked also with keystrokes provided by the screen reader. Keystrokes can also be pressed to enlarge the pointer, highlight the area where it's pointing or teleport a Braille display to show the text at the focus.
It is important to remember that for many blind and low-vision users, viewing the screen this way is kind of like peeking at it through a soda straw. A typical Braille display is a single line of 40 characters which must be panned in all dimensions. The same is true for a magnified area of the screen. Users depending on speech must decide what and how much they wish to have read. For example, when I read email, I have speech start at the top of a message, and read until I press a key to silence it. But when I scroll a long document, I simply want the top line of the window to be read as I scroll to each succeeding page.
A user's facility with his screen reader depends mainly on his level of sophistication and computer literacy. A power user will know how to redefine his keystrokes and make screen access jump through hoops. A beginner may only know how to use the arrow keys and the tab. But a power user will want to be productive and not waste time reading unwanted information and a beginner will be confused if software deviates from established standards.
Blind users therefore hope that the application they're working with will not require that they look everywhere at once. They hope the screen reader will track the focus and/or cursor and know what they need, when they need it.
Of course, there are situations where an icon must be clicked and the most familiar example of this is a typical toolbar. Screen access approaches this situation in two different ways.
The first method is to provide tools for the user to explore a new application and label its graphics. Graphics can be given text labels so the blind user can locate and interact with them. Typically, the user would set the screen reader to announce all new text which appears. Then he'd navigate across a toolbar button with the mouse and the screen reader would speak that button's tool tip. The blind user would be able to give that graphic a meaningful label, like "open file icon".
The second solution is to automate the process. For popular programs, like the Microsoft Office suite, screen access vendors have already defined labels for the graphics and configured special keystrokes that will "click on" particular icons. Customizations for screen readers are often prepared by users themselves and distributed on the internet. Some are free and others are sold via paypal. Many government agencies serving the blind also have special consultants who are experts in customizing screen reading software. They travel to job sites where they are contracted to make a particular application work with a particular screen reader.
Not only do the files that configure a screen reader contain icon libraries with descriptive text, they also contain scripts that tell the screen reader how to respond to a particular situation. Though not all the screen access packages have a built-in programming language, they are all highly configurable and their functions are exposed.
Users typically only get a government funded consultant to configure their software when they are new on the job. This is because the department of rehabilitation is eager to close a case and get another blind person hired. As the employers needs change and the employee’s job adjusts, new software is often introduced which may not work with screen access.
Take, for example, Meeting-Maker, a calendar program I must use in my job. It displays all my week's appointments onscreen in five columns, one for each day.
I worked with some ham radio software that had list views, grids, radio buttons and check boxes that my screen reader simply saw as graphics. Instead of labeling them as I would have icons, I had to tell the screen access what each control was. So richedit52w became an edit box and msctls_trackbar32 became a slider. This works of course if controls behave properly, and accept the standard keystrokes, when they just look odd to the screen access package. It is very frustrating if each control is its own window or controls look different to the sighted user but have the same underlying window class.
For a final example, I have an FM tuner card for my laptop whose software interface is a single screen of buttons. To the sighted user, it looks very much like a typical radio. However to my screen reader, it looked like this:
|
graphic496 graphic 621 graphic 883 |
|
graphic 9255 graphic523 graphic 871 |
|
graphic 422 graphic910 graphic263 |
|
graphic889 graphic 112 graphic 834 |
|
graphic525 graphic618 graphic543 |
After I labeled its graphics, it looked like this:
|
tune-up tune-down prev-station |
|
mem-store mono/stereo next-station |
|
band agc mute |
|
1 2 3 |
|
4 5 6 |
Next I wrote a simple script to click on a button when I pressed a keystroke. Now, if I press the up arrow, I tune up the band, if I press a number, I tune in a particular preset. Sadly, the programmer could have built this functionality in to the software, but he chose to just plop a bunch of graphics on the screen with no menus, no keyboard shortcuts and no access.
I am a fairly sophisticated screen access user. I have a programming background and a curious mind. There are blind wizards who can use software I find impossible. But there are many other ordinary users who would have never been able to utilize the FM tuner card.
This kind of ordinary user, who works daily with complex spreadsheets in Excel , using speech and a Braille display is a quick and competent worker. She knows how to do her job effectively but she isn't a computer expert. She may be asked to enter data using your company's accounting package, and discover that it's difficult or impossible for her to access. She may be afraid she will loose her job -- it happens to blind people all the time when companies change software -- and this fear will make her less able to master new software that probably won't work with her screen reader anyway. She then might send you an email complaining your software doesn't work with JAWS. The purpose of my letter then is to explain the problem more coherently, to help you fix your software so all of us can use it too!
JAWS, or Job Access with Speech, does just as the name implies.
It is one of the leading screen access programs in the
The JAWS folks also make a screen enlargement solution called Magic. It is scriptable and integrates well with JAWS.
In the U.K. Hal, from Dolphin Computer Access, is probably the market leader.
And back in the
Even though screen readers compete for users, what you do, as a developer to improve your software's accessibility helps everybody regardless of what screen access solution they choose.
Your most important step is to give keyboard access to the functions of your program. This is especially crucial if your graphical buttons don't have associated text-based tool tips. If the user must click on a microphone to record, and the word "mike" doesn't appear anywhere on screen, it would be helpful if they could just press CTRL-R for record rather than asking a sighted friend to help them find the mike button. For a humorous footnote to icons and mikes, see this page.
Consider too, if your general interface might not benefit from some overhauling. Screens today are very cluttered with more buttons than you can shake a stick at and so many windows that even fully sighted users can't cope. One of the audio players I use for example has five views open all at once even when I'm burning a CD. Why should I poke through a proliferation of icons and buttons when I just want to know the status of the burning task.
And don't just throw in some back and next buttons while you turn a ten-step process in to three huge steps. You can always caption each dialog "Step 6 of 10, step 7 of 10 etc."
Captioning each dialog helps all users know where they are. Instead of calling all dialogs ""client setup", using meaningful captions like "report layout" and "security settings" eases hassles for tech support as well. You have to know where you are before you figure out how to get where you're going.
While we are on this topic of captions, pay attention to the text on your screens. If English isn't your native language get your summer high-school intern to write the messages. And messages that help clue the user in are best. Instead of "Unable to continue" "Enter a project name, or click Help to learn what a project is" tells the user exactly what is needed to move forward. Improving software with these tips helps all users and your bottom line; it isn't just to make a small minority of blind people happy.
Once your program's important functions have keyboard shortcuts, and graphics have tool tips and messages are meaningful, then it's time to refine the keyboard interface a bit. Remember that sighted people concerned with productivity are heavy keyboard users as well. And people who depend on speech recognition often work with keystrokes, for example asking Dragon to "press the escape key".
So check that your tab order makes sense. If a person first clicks on create, then view, then modify and then save, make sure they tab to create first and save last. If the only way to pull down a drop-down list box is to click on it first, make sure it appears in the tab order.
Put away your mouse and try using your own software ONLY with the keyboard. You'll quickly find where shortcomings lie and shortcuts are needed most.
Familiarize yourself with the standard windows keystrokes. Do you know what ctrl-tab does? Do you know what keystroke is used to close a child window?
Don’t invent new ways of performing familiar tasks. Don't use F8 to delete unless you are writing for users whose keyboards are missing a delete key. The more your software quacks like windows, the easier it is for users to waddle through.
Screen reading programs already know how to access combo boxes, sliders, menu bars and spin controls. There are standard keystrokes for interacting with these objects and screen access knows how to report the appropriate information when its needed. For example as I arrow up, down left and right through a tree view, I'm told whether an item is closed or open and how far through the tree I've navigated. But if you build your own pretty tree-like view from scratch, my screen reader sees it as just a bunch of unidentifiable graphics.
Also, when you build controls from scratch, screen access frequently cannot track the focus. For example, I have some software that lets me use my computer to program a police scanner. The channels are shown in a grid, and to edit one, the sighted user clicks on a cell and begins filling in fields. Since it is some weird non-standard control, I can't use the ordinary cursor keys to navigate it. If I use my mouse, and locate the name of a channel, then click on that name, I still can't edit anything, because the label is above the cell. This software is extremely difficult for me to use, because I must locate a cell label, then guess how many pixels down to push the mouse and click on an invisible space. Had the programmer used a standard keyboard-accessible grid control, I could have been nearly as productive with this software as a sighted user.
If you are simply working with controls written by other firms, and these building blocks aren't accessible, refuse to buy them and share this open letter with them. Windows already has many built-in objects that are accessible and at your disposal, so learn their properties and methods. Other high level languages have plenty of accessible controls as well, for example a huge variety of toolbox items are available for Visual BASIC, and some of them work beautifully with screen readers. When in doubt, you can ask blind programmers on the internet for their advice.
My pet peeve here are CD burning programs that insist on showing their own explorer-like view. It is vastly simpler for me to select the files I need in familiar old Windows explorer, then right-click and choose "write to CD". But the built-in wizard for doing this in Windows is so lame. So why couldn't the CD burning programs add a simple context menu choice to familiar old explorer so I can bypass their confusing and non-standard file selection interfaces?
If you like the currently popular look of displaying a number of smaller panels in one large window, make sure that the user can switch focus between panes with the keyboard. Virus scanners and spyware removers seem particularly bad about cramming tons of little info boxes on to one screen. If each box were a separate window, screen access would read it is a discrete unit, but often, the screen is only one window with a multitude of overlapping panes. Screen readers turn this in to a hopeless jumble as they can’t tell that each pane should be considered separately.
Even better, put all the panes on the view menu, the way this is done in Microsoft Outlook, so a user isn't stuck with all of them. If your marketing guys want you to put more information on screen, then make this your default view, but allow users to turn off unwanted panes so they can create a view that's more compatible with screen enlargement or Braille displays.
Think how much simpler my meeting maker would be if I could get it to show just one day at a time on screen.
It's easier for me to pull down a menu bar, choose Reports, and go through a dialog box to format and prepare one. Do you really need to cram all the reports on to one screen and assign a cute little icon to each?
Media players have tried so hard to look like stereo components they don't look like Windows software anymore. It takes me forever to hunt through a forest of icons; I'd much rather pull down the playlist menu and choose Create.
Many computer users have other disabilities. Some people are dyslexic, some are visual learners. Some have physical limitations that makes it hard to type. If your software has skins or a variety of views, and you clearly document their availability, then it will automatically become more accessible to a wide range of users with different learning styles and skills.
I hope this open letter has helped you think about ways to make your software easier for blind and visually impaired customers to use. The internet is filled with mailing lists for blind people so you shouldn't have difficulty locating a friendly place to get any questions answered. Simply Google for any of the screen access programs listed above, or ask technical questions on the blind programmers' list.
Thank you for reading this, and thanks for caring about computer users who want to keep their dignity and independence.