6 myths about accessibility

Date of publication

Many of my conversations come to the topic of accessibility at some point. I have come across a number of myths that are very persistent. I would like to clear up a few misconceptions here. Let me say right at the beginning that I explicitly mean accessibility for all people.

Who is this article actually for?

The article is not aimed at a specific target group. That may be an unusual approach. However, it is a deliberate choice. I am convinced that accessibility concerns everyone and that a certain basic understanding cannot be spread far enough. So I try to approach the topic as comprehensibly as possible. In doing so, I speak from experiences that I have made as a blind person. But it is not enough to limit accessibility to this group!

Myth 1: Voice assistant, that's right, I have that too!

It may seem logical at first that blind people control their computers with Siri, Alexa and Co. Mistake!

Where does that come from?

Some people have probably already noticed that smartphones or computers are often used by blind people with a voice output. And where else do you know that technical devices talk to you? That's right, from voice assistants. So one quickly draws the conclusion that it could be some kind of special function of theirs. Far from it.

How is it right?

Blind people do use voice assistants - but rather for less complex tasks. Perhaps to listen to a particular podcast or radio stream, or to quickly set a timer. But the actual interaction, with the smartphone for example, is done with a screen reader.

What is this now?

In simple terms, a screen reader is a translator. When my finger is on the display and I move it, I hear a voice output reading what is on the touched spot. A voice assistant cannot do that. Without a touchscreen, you use various keyboard shortcuts to get information.

Myth 2: It can't be made barrier-free!

This statement is an absolute hate object for me. At the same time, I don't want to blame anyone who thought or said this sentence. If you're not that deep into the topic of accessibility, it may seem inconceivable how, for example, a flight simulator can be made accessible. But it can actually be done.

Where does that come from?

I suspect that there are two reasons. One is that there is a lack of knowledge about what techniques can be used to make even the most complex applications accessible. The other is that there is a lack of imagination. Although I'm very deep in the subject myself simply because of my blindness, I'm always amazed at the creative accessibility solutions that some people come up with.

How is it right?

There is a lot to discover, especially in the creative solutions. The gamer scene is really impressive. Microsoft, for example, has an adaptive controller on offer. This allows games to be enjoyed even by people with motor impairments. The Last of Us 2 sets completely new standards on the software side. It is equipped with adaptations for various disability-specific restrictions. There was an incredible amount of positive press for it, and rightly so.

Myth 3: Accessibility restricts design!

"You can't make this barrier-free. Otherwise it won't look as nice!" This myth also still persists. Gladly also in connection with special additional pages that are supposed to be especially accessible, but where suddenly half of the content is missing. "Accessible" unfortunately also often means that it is a collection of links, which in turn refer to completely normal pages. Even if it were acceptable to offer a separate page for the disabled, the implementation would be deeply flawed as a result.

Who has now thought mainly of colors: Admittedly, it may be annoying if the beautiful color combination has to be changed because of a lack of contrast. But that doesn't mean that there are simply no chic combinations that are accessible.

Where does that come from?

The ability for screen readers to reasonably handle complex web technologies has not always been a given. Therefore, in the past, there were indeed problems with designing layouts or interactive concepts the way one wanted without compromising accessibility. In e-mails designed with HTML, this is still the case today. This is especially noticeable when tables are used for the text layout. It is not fun when the screen reader announces for each paragraph that it has to switch between several nested tables.

How is it right?

It is true that a single principle can already achieve a lot, namely: separate content from design! That this belongs together, you will now want to counter me. For accessibility, it makes sense to first create the framework of the page in HTML. Provided that the semantic structure (e.g. the heading structure) is coherent, everything can be made very pretty afterwards. I know that this is often done the other way around. Sure. The customer wants to see what he gets. But just because the advertising brochure shows a finished house, you don't do without the piping before you decorate.

Myth 4: Accessibility? That is exclusively a matter for the developers!

Accessibility is a complex topic. And yes, developers can do a lot about it by using accessible practices. However, it is too short-sighted to pass on the issue to them. Nevertheless, thank you for thinking about accessibility at all!

Where does that come from?

When accessibility is commonly written about, one often finds two principal statements:

  • Structural accessibility consists of wheelchair ramps.
  • Accessibility for the blind is totally complicated from a technical point of view.

"Technically complicated? Well, let our developer take care of it!"

How is it right?

It is true that developers have a part to play in accessibility. And admittedly, this part is crucial. But it is just as crucial, for example, that the design uses high-contrast colors and provides sufficient "white space" between elements that differ in content. And then, of course, there are the editorial tasks:

  • Is the right language markup set?
  • Does the headline structure make sense?
  • Are images correctly described?
  • Are data tables set up sensibly?

Those are just a few questions to ask. And that doesn't even take into account other things like sign language and subtitles for videos or using plain or simple language. These are all prerequisites that ensure that the preliminary work of your development department can be successful at all.

Myth 5: Accessibility can be tested automatically!

I read it all the time: the promise that accessibility checker XYZ can replace a comprehensive appraisal. And I can see why that's so tempting. It's faster and cheaper to run an automated test than to entrust this task to people who are used to working with screen readers.

Where does that come from?

I have already mentioned it briefly: schematic testing is faster and cheaper. And nowadays, so many things can be automated that one cannot believe that there should be an exception here of all places.

How is it right?

It is true that the various automated accessibility tests can provide clues. However, depending on which numbers you rely on, these tests only find 40% of accessibility problems. Less than half is better than nothing, of course. But a web store where I can do everything except add items to the shopping cart is still broken because of it.

Furthermore, these tests can so far only tell whether certain things are present. But not whether they have been integrated in a meaningful way. Let's imagine the image of a lemon. This image gets the image description "piece of cake". Doesn't fit together? No, we don't connect it and make it a lemon pie slice. An automated test now only sees: "There is an image with an image description". But it will miss the fact that this description does not match the image at all.

Myth 6: Data protection and accessibility are mutually exclusive!

Unfortunately, I keep reading and hearing that data privacy and accessibility are mutually exclusive. "Data protection gets in the way of accessibility" is simply what they say.

Where does that come from?

The idea behind this myth is, among other things, that data protection is perceived as a major hurdle. The General Data Protection Regulation (GDPR) is evil and if only we finally gave all data freely to all companies, everything would be fine. Sometimes more, sometimes less formulated, this also includes accessibility. Facebook can recognize images? Well, then we have to use that, too.

How is it right?

Both are fundamental values that, when combined, create significant added value. Of course, everyone is free to see things differently. But I have yet to hear an objective reason why data protection should hinder accessibility.

At the end

I would like to end with an unfortunately real example. I landed on a page that was barely understandable. Everything was strangely choppy and not exactly pleasant to read. Picture descriptions also didn't match the picture content, which I learned from the laughter of my colleagues. (Hey, there's nothing like a cheerful mood in the office).

I then found out that the site was labeled as almost perfectly accessible. This was a mystery to me. The resolution was then found in the test steps. A view of the page with a screen reader was only in exceptional cases. It slipped through that the hyphenation took place in the HTML and not in the CSS.

As a conclusion I would like to state that we all should not understand the accessibility as an annoying requirement. If you waive it, you actively exclude people. And the next blind person who is excluded might have left a lot of money with you ...

Profile picture for user DeepL

DeepL is a deep learning company that develops AI systems for languages. The company, based in Cologne, Germany, was founded in 2009 as Linguee, and introduced the first internet search engine for translations. Linguee has answered over 10 billion queries from more than 1 billion users.

Profile picture for user dennis.westphal

Dennis Westphal

Dennis is an IT consultant at the Company for the Development of Things. His field is accessibility. Helpfully, Dennis has been blind since birth. He creates his screencasts with open source software.