“Software programs should be usable by everyone.”
I think everyone can agree with that statement. Unfortunately, there is some extra work needed to make a program truly accessible. Even worse, this is often only thought of in the last bit of a project. This leads to accessibility often being cut out because of time and budget constraints. If accessibility would be considered from the start, it could be built in more easily. But how can we make us as developers more aware so that we actively think about accessibility when building the software?
Our answer: let’s experience first hand how (in)accessible our software is!
We decided to host an accessibility challenge for our colleagues. Read below how this turned out…
Accessibility at TOPdesk
At TOPdesk, considering accessibility becomes more and more important. Our software is web-based, so we strive to adhere to the WCAG guidelines (level AA in our case) for new features. We test our software with two of the most common screen readers, Jaws and NVDA. Also, all development teams receive an accessibility training.
Nevertheless, the focus during development is on the new features and accessibility is considered later. When accessibility is tested during development, we do not use the screen reader exclusively but also observe the monitor. Although this is a valid approach, the tester subconsciously picks up visual information that helps him to anticipate the next steps.
The Accessibility Guild – a group of TOPdesk developers from different disciplines – is working on moving the whole topic more into focus and raise awareness in the heads of our colleagues.
Creating the Accessibility Challenge
We took the opportunity to reach a lot of our colleagues during a three-day conference of the TOPdesk development department. In between their sessions and workshops, people could come by and have a go on the “Accessibility challenge”. We created a scenario that had to be solved by only using the keyboard and screen reader – and no screen. To encourage participants, we measured the time taken to complete the scenario. Time measurements were collected publicly and the winners awarded with small prizes in the concluding session.
The scenario to solve was as close to real-life as possible to make people identify with the situation: Find help with your problem (failing to log in with the hour registration system) in the TOPdesk self service portal. Intentionally, there were several solutions for the scenario as we wanted people to be creative about the task rather than follow a chosen track. And indeed, people came up with solutions we did not think of beforehand.
The setup was pretty straightforward: a laptop with a running TOPdesk, NVDA as screen reader and Chrome to access the self service portal. We installed the screen curtain plugin for NVDA, so the participants had only a black screen to look at.
Running the challenge
The challenge took place outside the conference rooms where everybody could see it happening. A difficulty was the noisy environment which made understanding the screen reader sometimes difficult. Still, we decided to run the challenge without headphones, so we could follow the actions of the participants and help them when they get stuck. A side effect of that was that a lot of people got curious when they heard the screen reader talk and then decided to have a go themselves. 🙂
An important point after the exercise was to lift the screen curtain. Then the participants could finally see where they ended up and what they actually did. For some people, this was a surprise moment. They had a different mental image of their path through the program, and were even interested in getting an “unveiled” tour with active screen reader.
Outcome of the challenge
Placed near the coffee machine, we were very visible. Our colleagues reacted very positively to the challenge and asked a lot of interested questions. As a result, many of them took up the challenge. The participants came from all disciplines of the department – programmer, tester, designer, manager. Most managed to solve the task in under 5 minutes.
A few participants lost orientation completely. When they reached that point, we offered help and reset them to the start or showed them the next step. Being supportive and helpful throughout the whole exercise turned out to be a crucial point to make this a success.
Another positive effect was that we found – not surprisingly – some accessibility issues in TOPdesk which we will follow up on.
Reactions to the experience
The experience triggered a lot of emotions in the participants. Being reduced to a keyboard as input and a mechanical sounding voice as feedback was really stressful for them. Despite knowing how use the program, participants felt helpless and disabled. Some participants even became angry about inaccessible features of the interface.
The participants became positively excited about their experience. They came up with a lot of ideas of how to improve the usability for screen reader users. Participants also became curious about the working of the screen reader itself and how “real” blind users would use it. Their perception of the software shifted – this is what we were hoping for.
Participants were astounded to find that features which seem to be accessible at first glance are actually unusable. This means, all the right HTML elements and labels are there and you can access the feature with the screen reader and keyboard. However, the actual use is super awkward: often, the tab order is wrong or there is no audible feedback on actions. This shows once more how important it is to put yourself in the shoes of the user when you test accessibility.
We found that gamifying a trivial everyday problem with the additional hurdle of experiencing it as an impaired person really broke the ice with a lot of colleagues. It lead to fruitful conversations about the personal experiences of the participants and usability pain points. We now have a new view on the people who have to use our software by means of a screen reader. Hosting the challenge taught us a lot about the perception of accessibility of our colleagues. All in all, we set out to make people more aware about accessibility and we believe that we reached that goal!