
Barrier-free working
The term “barrier-free” is originally derived from the building industry and means that, for example, access to a building or the use of an object should not be made more difficult for anyone by obstacles of any kind. We find accessibility improvements in many public places. 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 handicapped people to cross the street.
Similarly, accessible software is intended to enable all employees of a company to do the same work. Typical obstacles arise from physical disabilities, such as reduced sense of sight or hearing or reduced motor skills.
But what requirements needs software to meet to enable all employees to do the same work? And how can software compensate these limitations?
How can software become accessible?
Criteria for accessible software are defined by various standards, such as ISO 9241 for the “Ergonomie der Mensch-System-Interaktion”, the “Web Content Accessibility Guidelines (WCAG)” of the World Wide Web Consortium and the “Barrierefreie Informationstechnik Verordnung (BITV 2.0)”:
- Separation of text and layout so that text can be read by screen readers and output on a Braille line.
- 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 should not be the only way to transmit information or initiate a reaction – such as the color red for buttons and warnings.
- All functions should be able to be carried out via keyboard in order to make control easier for people with limited mobility.
- Connectivity to operating systems and devices to ensure connectivity to screen readers, reading aids and other assistive technologies.
- Scaling and display connectivity to enable zooming, inverting or particularly high-contrast displays.
Open from scratch
These criteria seem logical, since they define modern software architectures with a “clean”, universal code. In good software applications, all functions should be usable by all users. However, practice looks different. Often the code is not accessible. Screen readers do not get access to the information or worse: Information is read incorrectly or incompletely. Exactly this should not happen with accessible 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. Like the trend in the net, modern software is strongly visual. Applications work with images, graphics, colored or animated elements, floating menus, drag and drop or overlays. Screenreaders and other assistive technologies have difficulties dealing with such user interfaces. For business software, less is more.
Clearly structured user interfaces that are easy to access, even if they may seem boring, are very likely barrier-free – and can usually be used more effectively by users without restrictions.
Good basis: A detailed catalogue of requirements
In numerous projects for accessible software applications, the requirement catalogs contain only very few specifications. On the one hand, because customers often do not have the relevant experience, on the other hand, because there is a lack of specific knowledge. The questions are as follows: What must and what can be implemented? And in what way?
Take the example of a call center: The process Call – Answer – Process – Hang up – Postprocess is to be designed to be accessible for blind employees and colleagues with physical limitations.
For blind users, the complete control via mouse must be transferred to the Braille keyboard in shortcuts, tabulator control as well as input and output. An alternative to mouse control also helps users with physical limitations, because tabulators and shortcuts are often faster than mouse control. For people with visual handicaps, possibilities for extreme zoom and strong contrast must also be created. It is also important to consider how the process and sub-processes are modeled:
- For example, how should blind employees be notified of an incoming call and how do they accept it?
- How do physically handicapped users who can only type slowly or to a limited extent document business transactions?
- How are additional documents – for example discussion guides – made accessible?
Finally, the “translated” functions must be put into skill sets and user profiles that require certain skills and expertise. For the successful implementation of this highly complex process, good foundations should be laid right from the start. A clear and detailed catalogue of requirements saves many iterations and test cycles.
Experienced partners
In the development of business applications, mixed teams of IT people, developers, business managers and users are proven. Even in barrier-free projects, it can make sense to involve actual users – disabled and not – in the development process. Handicapped users in particular can contribute important ideas based on their everyday experience.
If you do not have detailed technological knowledge or experience with accessible software, you should not be afraid to call in experts. For example, a reputable partner can provide you with contacts to those responsible for reference projects. So you can talk to your colleagues and benefit from their experience. Even with good pre-conditions, it takes many tests and iterations to achieve barrier-free operation.
Please do not hesitate to contact us if you have any questions about barrier-free software or if you are looking for an experienced and reliable partner who can help you with the realization of such a project.