Design and development

Increasingly, software developers are required by legislation and by those purchasing their products to ensure that software is accessible to users with disabilities. Requirements in official tender documents for software procurement may indicate that systems need to be accessible. So designers, developers and their managers need to know how to achieve this.

Managing software development

Unlike website development, inclusive design of software is neither common, well-known or discussed. Techniques vary greatly according to the software development platform and there are no cut-and-paste examples of good (and bad) code. Websites are frequently refreshed, redesigned and renewed but it is almost impossible to correct poor software coding after implementation. In addition, many systems have an anticipated lifetime of many years. This makes it all the more important to ensure that software is inclusively designed from the start.

Design tips and techniques

You may be designing software from scratch, developing a new version of an existing product, or tailoring a commercial off-the-shelf (COTS) system to customer requirements. You need to make the interface as accessible as possible - what should you do?

The accessibility and usability of software, and the amount of additional access technology configuration required, is determined primarily by the design techniques that the software author adopts. The basic 'out of the box' accessibility and usability of software is hugely improved for many users if software design teams use inclusive and user-centred design principles.

We know that working with standards relating to inclusive design is not easy or straightforward. Sometimes the standards can be difficult to interpret, and the rationale behind them is not always obvious. Nevertheless, the starting point for inclusive design has to be the guidelines and standards already in the public domain.

RNIB recommends ISO 9241-171 and the IBM software accessibility checklists. Neither of these is perfect. The ISO standard is not free, and is difficult to interpret and use, but everything's in there. The IBM checklist doesn't include all significant issues, but is relatively easy to understand and apply. In our own accessibility work, we use ISO 9241-171 but we cut it down to those statements that are directly applicable to the software concerned.

You need to understand your guidelines thoroughly and appreciate the principles behind them. If you don't, then find an accessibility expert who will answer your questions or give you a practical demonstration. The key to good inclusive design is really about providing flexibility, and not deciding for the user how they will use your software.

Here are a few examples to describe and explain some of the important concepts in software accessibility.

Effective access from the keyboard

This is by far the most important requirement for accessibility and ease of use.

Visual display characteristics

The appearance of the screen and its contents can make an enormous difference to productivity, and even to our safety!

The programmatic interface

This is mostly hidden from ordinary users but provides essential information to access technologies about what's on the screen.

Other important aspects of accessibility

This is by no means a complete list. Despite our long experience of issues in software accessibility, technology is a fast-moving discipline and we are always coming across new problems to solve. We are always reassured by the innovative and imaginative ways that software designers, developers and programmers overcome the barriers and improve the experience of using their software for everyone.

Run solutions past experts

We fully acknowledge that software accessibility is a difficult subject and not nearly as well established as web accessibility, for example. There are no tried and tested textbook solutions to the problems that arise in trying to make software interfaces as accessible and usable as possible to users with the widest range of abilities. There are no automated tools to help with judging software accessibility; everything must be done manually.

So at the time of writing, the only way to establish whether the solutions that software teams have come up with are effective or not is to work with experts in the field of software accessibility. RNIB contains such experts, and we hope that other agencies will join us and create a market where demand for varied software accessibility expertise is matched by supply.

Last updated: 15 September 2009

Make a donation

Right now we can only reach one in three of the people who need our help most.

Please make a donation and help us support more blind and partially sighted people.