The importance of a diverse workplace: a multilingual screen reader case study

Screen readers were initially developed to help blind and low-vision people interact with computers, although many other users (such as people with dyslexia or people who are unable to read) can benefit from them as well.

Screen readers speak out text content, and they also provide information that is otherwise only available visually or, in some cases, programmatically. For example, they can inform the user about special kinds of text (like headings and links), read out text alternatives for non-text content (like images), and explain how to use a complex web widget (as long as the necessary ARIA attributes are present in the HTML code).

Although I had learned the basics a while back, I only became a frequent screen reader user once I joined Wunder as a UI developer and accessibility specialist. Nowadays I can comfortably use VoiceOverOpens in a new tab on Mac and iPhone, NVDAOpens in a new tab and JAWSOpens in a new tab on Windows, and TalkBackOpens in a new tab on Android.

The origin story

One of my first internal projects involved assessing the accessibility status of many services developed by Wunder. This, of course, included screen reader testing. I did speak Finnish back then already, although not fluently enough to use it at work. As a result, my work computer and screen reader were in English, but I had to test a lot of websites that were exclusively in Finnish, or in Finnish as well as other languages. This is what I will henceforth call “a multilingual situation”: when the language of the screen reader and the language of the content are not the same.

In multilingual situations, screen readers are supposed to figure out the language of each text portion from the code, and then choose the correct voice synthesizer accordingly. If the wrong voice is used, you can end up listening to Finnish text being butchered in an English accent (or vice versa).

During that early internal assignment, I was testing website after website, and noticed constant mismatches between the language of the text and the voice synthesizer used to announce it. The first few times I thought the developers must not have properly declared the language; however, when I looked at the code, everything seemed correct. Googling didn’t help much; neither did asking my peers and mentors at Wunder. After a while, I began to notice minor patterns, until I finally decided it was time to properly study this phenomenon.

The experiments

Putting my science degrees to good use, I devised some experiments that could help me elucidate what exactly was going on with these language bugs. If you want to get into the nitty-gritty of how screen readers work, how I designed the experiments, and what kind of results I got, feel free to read my 2020 article, “The troubled state of screen readers in multilingual situationsOpens in a new tab“. Otherwise, here is the gist:

I tested the performance of VoiceOver, NVDA, JAWS, and TalkBack, on major devices (desktop and mobile), operating systems (macOS, iOS, Windows, and Android), browsers (Safari, Chrome, Firefox, Opera / Opera Touch, and Edge), and reading modes (continuous reading, where you allow the screen reader to “run on its own”; and controlled reading, where you use keyboard or touch shortcuts to “tell” the screen reader what to announce next).

I ran three separate experiments:

• In Experiment 1, I tested common web elements that have existed for a long time (such as headings, lists, images, buttons, and links).
• In Experiment 2, I compared different ways of providing accessible labels for a Close button, whose only visible content was the letter “X”.
• In Experiment 3, I repurposed data from the previous two experiments, in order to focus on what happens when screen readers announce content that is provided through HTML attributes (for example, the alt attribute for an image, or the aria-label attribute for an icon).

I gathered a massive amount of data that revealed a lot of interesting patterns. In extremely broad strokes, this is what I found:

• All screen readers showed significant language bugs in multilingual situations.
• The language bugs were present in features that have been around for a long time (such as the <img> element, introduced by HTML 2.0 in 1995), as well as newer ones (such as the aria-label attribute, introduced by ARIA 1.0 in 2006).
• In most operating systems, there wasn’t a single screen reader and browser combination that worked sufficiently well.
• Even if a screen reader and browser combination works today, a software update to either one of them can completely break it tomorrow (for example, Firefox version 75.0 worked really well with NVDA but poorly with JAWS, while the opposite had been true for version 72.0.2 less than two months earlier).

That last point was based on comparing the data collected during the experiment with preliminary data I had gathered earlier. Due to this uneven, fluctuating support, I made a commitment to repeat the experiment on a yearly basis. If you are interested in how they will develop, follow me on MediumOpens in a new tab!

My theories

As a junior web developer, I don’t have the knowledge to dig into the code behind a screen reader or browser in order to find out where the issues are coming from. However, a lifetime of experience in problem-solving and teamwork does allow me to venture a few educated guesses:

• Those developing screen readers are predominantly monolingual. It is a well-known fact that the lingua franca in the software development industry is English. But I specifically want to make the point that the people, teams, and environments developing screen readers probably have, for the most part, a monolingual mindset and sensibility. Even if a team communicates in English, as long as there are members who speak multiple languages, and multilanguage support is defined as a priority, the team can work towards that goal. The number of language bugs present, and the fact that they occur even with simple and long-established features, strongly suggest that multilanguage support is not a central concern.
• Those developing web browsers are predominantly monolingual and non-disabled. Browser development probably suffers from the same monolingual mindset problem I described above. I’m also willing to bet that most people involved in designing and developing browsers neither have a disability nor consider the needs of the disabled community. Furthermore, there’s probably not that many people whose job it is to ensure that internet browsers improve (or even maintain) screen reader support; and the few with that task are probably monolingual English speakers, and/or work in monolingual environments.
• Those testing websites with screen readers are predominantly monolingual and non-disabled. I definitely think this is the reason why nobody else at Wunder had ever noticed these language bugs. We have five accessibility specialists: three don’t have any disabilities, one is a designer with a visual impairment, and I have a disability that doesn’t affect how I interact with digital devices. I am also the only one in the team who isn’t a native Finnish speaker. In practice, all this meant that my colleagues were either not operating screen readers in multilingual situations (so they simply didn’t encounter language bugs), or they did so rarely that they simply had no chance to notice patterns or explore them further.

How my background helped this experiment

Every person has a different body, mind, and life history, which causes them to experience the world in their own way. Individuals are, of course, not at fault for not speaking multiple languages or not needing a screen reader. But when everyone involved in a project speaks primarily one language, it’s hard for the team to figure out and address the needs of people who don’t. Same deal for screen reader users, and both deals combined for multilingual screen reader users. There’s a few different aspects of my lived experience that made this experiment possible:

• As a polyglot, I could experience screen reader language bugs.
• As a developer testing the accessibility status of many different websites in a short period of time, I was able to notice certain patterns in these bugs.
• As a scientist, I had the inclination and preparation to come up with a way to properly study and systematize these patterns.
• As a Wunder employee, I had a supportive working environment where I was given the time, space, and resources to go down this rabbit hole, and come out the other end with the knowledge to help Wunderers not only test screen reader support better and more efficiently, but come up with more inclusive practices.

What this means for diversity in tech

Having a diverse workplace is important for many different reasons. Being “the only one” of a certain kind or identity can lead to representation burnoutOpens in a new tab. Even when someone is not “the only one”, it is key to put structures in place that not only support diverse individuals but also treasure and harness the innovative ideas that come out of diverse groups; otherwise, people can walk away wondering, “is diversity and inclusion in tech just a myth?Opens in a new tab“.

Although we have a long way to go, one of the great things that came out of the diverse workforce at Wunder is our Wunderpedia. This “Wunder encyclopedia” was launched with an accessibility section on Global Accessibility Awareness Day 2020. What started out as an internal resource is now a living, public, curated collection of knowledge that we put out into the world because we want to do our part in building a world where digital belongs to everyone. If you’re curious, I wrote more about the origin story of Wunderpedia AccessibilityOpens in a new tab on Medium.

The matter of screen reader multilanguage support is touched upon in our text alternatives section in the Accessible UIs article as well as in our screen reader testing section in the Accessibility Testing article. You’re welcome to peruse the rest of Wunderpedia now and in the future, as we have great resources in place already, and many more to come.