User Experience - Problems of blind Users

Standards like WCAG cover the technical requirements of blind people for digital user interfaces quite well. However, technical conformity does not have to mean that an application is comfortable to use for blind people. In many cases, applications that are formally accessible but difficult to use tend to deter blind people.

If blind people use applications regularly, they can usually work very well with them. The challenge is that nowadays we often have to work very quickly with new applications or have programs that we use so rarely that we don't become familiar with them - an area in which a good user experience would be particularly important.

In the following examples, I assume that the application is largely accessible, i.e. standard-compliant. It goes without saying that non-accessible applications cannot be used by blind people or can only be used with great difficulty. A typical example is a button that is implemented as a linked graphic or clickable JavaScript element. Although this is generally usable, it does not conform to the standards because the role of the element is not correct.

Common problems

It's often little things that make it difficult for blind people to use. A typical design pattern is to place the Cancel button on the right and the Agree button on the left.

This often results in the Cancel button being reached first via tab. If you as a user are not careful, you will accidentally cancel the process. In most cases, however, confirming should be the desired option.

Blind people always walk from top to bottom when using web or app interfaces. This means that they will not notice if something changes in front of their current position. Imagine scrolling through a long page, clicking something, and something changes at the top outside of your viewport. This happens with Google applications such as Gmail. If you select an email in order to perhaps delete it, the corresponding buttons appear above the email list, but a blind person would look for it below the email list because it has already “passed” above and was there at that time nothing there.

Another challenge is the increasing complexity of keyboard shortcuts: Blind people use countless key commands in desktop applications to speed up work. For example, you can use the keyboard shortcut “Alt + 1” to mark a section of text as heading 1.

There are also such abbreviations on the web, but they can be very complex. They often consist of pressing three or more keys at the same time. This is both a motoric and cognitive challenge: the more buttons you have to press, the higher the likelihood of incorrect operation. In addition, there is no standard for keyboard shortcuts. With video communication tools, the icons for activating the video or camera always look similar, so that sighted people can quickly find their way around. However, the key combinations for these functions are different, which is not intuitive for blind people.

The complexity of applications is constantly increasing: Single-page applications such as Google Docs or very long forms in particular are a challenge for blind people. Blind people cannot “scan,” i.e. quickly skim through a large amount of information and UI elements. This makes it difficult to use such applications smoothly.

Possible solutions

Some problems have solutions, but others are more difficult.

The needs of blind people should be taken into account at an early stage. This includes – as indicated above – good orientation via HTML or ARIA regions and keyboard navigation with familiar key shortcuts that makes sense for the user. Good error management is also important for complex forms and applications. Incorrect entries should be anticipated, information should be validated as soon as possible and communicated to the user so that it can be corrected.

For dynamic changes such as changed text or newly inserted UI elements, the changes should, if possible, take place behind the element that triggered them. Alternatively, the user should at least be told exactly where to find the changes and how to get there. Hijacking the screen reader focus, i.e. moving it using JavaScript, is possible, but not particularly popular with blind people because they then no longer know where on the page they are.

More simplicity in applications is desirable for all users, but especially for blind people. For example, if I book a ticket with Deutsche Bahn via the desktop website, I can still see the complete navigation from bahn.de. The booking form and a button to cancel the booking would be completely sufficient and would make orientation much easier.

Conclusion

In general, it makes sense to test with blind users and take their feedback into account at an early stage. However, it is difficult to get sufficiently qualified feedback, especially for complex applications. Then it makes sense to offer feedback options for blind users and to incorporate this feedback into optimizations.

It would also be important for assistive technologies to continue to develop. Currently they are still optimized for desktop applications. However, it is foreseeable that many applications will migrate to the web. It is also problematic that screen readers sometimes do not have uniform names for common UI elements such as checkboxes.

There is also a lack of established design patterns for blind people. As mentioned above, no uniform key shortcuts have yet been established for similar tasks in different applications.

More on blindness and accessibility