Skip to main content
UX and accessibility

Insights into an inspiring collaboration

Our colleague Dominik Hertlein from the UX team has been working for several months with a colleague who was born blind with a slight perception of light. In our latest blog post, Simon shares his experiences and insights from his day-to-day work as a blind software developer.


According to the Disability Equality Act (BGG), we speak of accessibility when people with and without disabilities can use an environment designed by people in the same way. Nowadays, the topic of inclusion and the associated accessibility is becoming increasingly important in order to give people with disabilities equal access to life as people without disabilities. 

Accessibility is a hot topic for our colleague Dominik, as he has been working with Simon Bienlein for a while now. Simon is a software developer and has been blind from birth with mild light perception. In this interview, he tells us how he manages his day-to-day work and the challenges he faces.

Simon Bienlein / Barrierefreiheit

Hello Simon. Nice of you to take the time to tell us a bit about your day-to-day work. Why did you decide to work as a software developer and what challenges do you face, or perhaps still face?

I'm a child of the 80s and so the internet naturally found its way into our household in the mid-90s, along with other phenomena of the time. Even back then, I was interested in how websites worked and how they were structured and displayed. And then, of course, I was also interested in how websites could be created in such a way that blind computer users could also enjoy using them.

During the summer school holidays, I started to learn about website programming in order to understand the background and context. During my training as an IT specialist at the training centre for the blind and visually impaired and also during my internship at an internet provider, I was able to gain experience in dealing with the Web Content Accessibility Guidelines (WCAG), deepen my knowledge and, of course, sensitise team members to the topic.

Even at this early stage in the history of the internet and websites, I realised that there was a wide range between good and bad implementations in terms of accessibility. So the challenge was to conclude which aspects distinguish the good from the bad realisations.

In the past, websites were very static, not very dynamic and not designed to be displayed on different end devices. In today's modern systems, the focus is much more on dynamic multimedia content and optimised displays on all possible output devices. As a result, the accessibility requirements for modern systems have also become more complex and multi-layered. Meeting these requirements is a key challenge of my job and has now also become a personal mission for me - all user groups should have the best possible experience in their everyday (digital) lives.

I am currently pursuing this challenge in my work at a federal authority. Through my current work, I have also come into contact with my colleague Dominik Hertlein from ASTRUM IT. Based on our collaboration in this context, we were recently able to organise an initial Aibility workshop as a kick-off for the UX team at ASTRUM IT in order to create a broader awareness of the topic of inclusive design.

How can we imagine your day-to-day work?

The requirements for the user interface are defined in close coordination with the experts for the legal requirements and the UX team. I am part of the interface between technical feasibility and the specific utilisation requirements of the specialist users. I look at the software from two different perspectives: on the one hand as a user who relies on special technical requirements and on the other hand as a developer who understands precisely these requirements and can of course also implement them.

My work centres on the signal chain consisting of the operating system, Internet browser and screen reader. The screen reader functions as an output system for the user interface via audio track, Braille or greatly enlarged display formats - in other words, the screen reader replaces the screen as the central output element for blind and visually impaired users.

Of course, the signalling chain is not limited to specialised tools for the blind and visually impaired. For example, there are also special keyboards or adapted pointing devices for users with motor impairments. All assistance systems offer an accessible user experience if the applications or websites they display or reproduce fulfil the necessary semantic principles, for example by using the correct HTML standards in web programming. If these principles are fulfilled, the assistance systems can interpret digital content in such a way that a high degree of accessibility is made possible for all user groups.

In my current day-to-day work, I support the project team with development reviews, various quality assurance activities, creating and reviewing pull requests, incorporating changes to the HTML code and coordinating internal and external accessibility audits, among other things.

How do you work together with your colleagues?

I like to paraphrase my collaboration experience with the following pithy sentence: "Copied error message texts are easier to deal with than attached screenshots."

One thing is clear: integration into a developer pool can never run smoothly. The other side also has to get used to the fact that information required for collaboration must be provided in accessible formats for blind team members. And, to stay with the example, a screenshot of an error message is not a suitable choice😊

So it's less a question of collaboration and more a question of the tools used. If you consider the tools that are commonly used, especially since the switch to distributed working, it becomes clear how important it is to formulate content precisely in times of highly visual tools such as screen sharing or collaboration boards. For example: "Click on the blue button on the right-hand side" is an abstract description that I cannot follow due to the different presentation - it would be more helpful to describe the underlying function or name the displayed text or tooltip.

What do you do differently to sighted people in your daily business?

I don't do things any differently to sighted people. Here, too, it's a question of tools: I prefer to use the Linux toolbox, especially the console, to complete some tasks rather than other, UI-heavy solutions.

Otherwise, I work with exactly the same content and in many places the same tools, only the form of presentation and interaction with the system is different.

Why don't you tell us what your workplace looks like? What tools do you use/need to be able to work?

My workstation includes the following devices:

- An 80-digit Braille display. Used for the tactile output of small screen sections in Braille (Braille for the blind), also available as a 40-digit version.
- A headset. In conjunction with a screen reader, outputs content controlled with the keyboard via voice output.
- Regular keyboard. Used for regular, normal input - as sighted people do and to control the screen reader
- Computer with screen reader software installed

Thank you Simon for your time and the detailed interview!

News-Kategorie: blog entry
arr_left previous post