Overcoming barriers with barrier-free software

Accessible work

The term “barrier-free” originally comes from the construction industry and means that, for example, access to a building or the use of an object should not be hindered by obstacles or obstructions of any kind. In many places in public spaces, we encounter accessibility measures. For example, ramps make it easier for wheelchair users to overcome height differences, while sound signals at traffic lights “translate” the signal for blind and visually impaired people to cross the street. Similarly, barrier-free software should enable all employees of a company or authority to do the same work. Typical barriers are caused by physical disabilities, such as a lack of sense of sight or hearing or motor limitations. But what requirements must software meet in order to enable all employees to do the same work? And how can the respective limitation be compensated by software?

How does software become barrier-free?

Various standards, such as ISO 9241 for the “Ergonomics of Human-System Interaction”, the “Web Content Accessibility Guidelines (WCAG)” of the World Wide Web Consortium and the “Accessible Information Technology Regulation (BITV 2.0)”, define guidelines and criteria for barrier-free software:

• Separation of text and layout so that text can be read by screen readers and output on a Braille line (output in Braille).
• Alternatives must be offered for non-textual content. For example, so-called alt tags for images and graphics.
• Content must be prepared in such a way that it can be read without loss of information.
• Color must not be the only means of transmitting information or prompting a reaction — such as the color red for buttons and warnings.
• All functions should be able to be carried out using a keyboard to make it easier for people with restricted movement to control.
• Openness with regard to operating systems and devices to ensure the connection of screen readers, read-aloud aids and other assistive technologies.
• Openness in terms of scaling and presentation to enable enlargements, inversions, or particularly high-contrast representations.

Open from scratch

These criteria appear logical, as they define modern software architectures with “clean”, universal code. In good software applications, all functions should be usable by all users. However, the practice is different. The code is often not barrier-free. Screen readers do not have access to the information, or even worse: Information is read out incorrectly or incompletely. That is exactly what must not happen in barrier-free application scenarios; after all, blind people must be able to rely on assistive technologies. Barriers are often created not only by the code, but also by the user interface. In line with the trend on the Internet, modern software is heavily visually influenced. Applications work with images, graphics, colored or animated elements, floating menus, drag and drop, or overlays. Screen readers and other assistive technologies are difficult to handle with such user interfaces. The following therefore applies to business software: Less is more. Easy-to-use, clearly structured user interfaces, even though they may seem boring, are highly likely to be barrier-free — and are usually more effective for users to use without restrictions.

Good basis: A detailed catalog of requirements

In numerous projects for barrier-free software applications, the requirement catalogues contain only very few requirements. On the one hand, because clients often lack relevant experience, and on the other hand, because there is a lack of subject-specific knowledge. The questions are: What must and what can be implemented? And in what way? Let's take the example of a call center: The process Call — answer — process — hang up — post processing should be made barrier-free for blind employees and colleagues with motor limitations. For blind users, complete mouse control must be transferred to shortcuts, tab control and input and output to the Braille keyboard. An alternative to mouse control also helps users with motor disabilities, because they are often faster with tabulators and shortcuts than with the mouse. Opportunities for extreme magnification and strong contrast must also be created for visually impaired people. It is also important to consider how the process and sub-processes are represented:

• For example, how should blind employees be notified of an incoming call and how do they answer it?
• How do motorized users, who can only type slowly or to a limited extent, document business transactions?
• How are additional documents — e.g. discussion guidelines — made available?

Finally, the “translated” functions must be stored in skill sets and user profiles, which require specific skills and expertise. Good foundations should be created right from the start for the successful implementation of this highly complex process. A clear and detailed catalog of requirements saves many iterations and test cycles in the end.

Experienced partners

Mixed teams of IT people, developers, specialists and users have proven effective in software development and programming of business applications. Even in barrier-free projects, it can be useful to involve the actual users, restricted and not, in the development process. Disabled users in particular can contribute important ideas based on their everyday experiences. If you lack detailed technological knowledge or experience with barrier-free software, you shouldn't be afraid to call in experts. For example, a reputable partner can provide you with contacts with those responsible for reference projects. This allows you to talk to colleagues and benefit from their experience. Because even with good conditions, it takes many tests and iterations until barrier-free operation is ready. Feel free to contact us if you have any questions about barrier-free software or are looking for an experienced and reliable partner who can help you implement such a project project.