Accessibility

UX Consultant Madita Schubert

What is Accessibility?

First of all – what do you think Accessibility is?

Is it a distant scenario, which one is unlikely to face?
What exactly do you need access to?
Is access infinite?
Can you achieve access, if you only want to get it?

The definiton of Accessibility by the Cambridge Dictionary is split into six slightly different explanations:

(1) the fact of being able to be reached or obtained easily
(2) the quality of being easy to understand
(3) the quality or characteristic of something that makes it possible to approach, enter, or use it

(4) the ability to get something easily
(5) the ability to reach or enter a place or building
(6) the fact of a person being willing to see people and of being friendly and easy to talk to

If you look closer, these are opposite prospects for the subject (the user).

The „ability“ has an active and apparently controllable definition.

ability
the physical or mental power or skill needed to do something.

Cambridge Dicitionary

On the other hand „being easy/willing“ and „makes it possible“ is focussed on the object – so for example the products we develop every day.

From a user’s perspective Accessibility has two aspects to consider

The active role of the user

Based on the ability, that the user can do what she wants to do, we should distinguish between a skill one is able to learn – a language for example -, and the restricted power to do something – seeing after a sight loss for example.

In the first scenario the user might need some time to learn the language, but she can also benefit from a translation tool to decode the content of a medium. So with some effort the problem is resolvable.

The second scenario, where one without sight wants to decode the content of a medium, it has to be accepted that the regular tool – the eyes – are not available for the ability to see (we call that disability). But when „seeing“ is considered in a broader perspective one is able to see or perceive with other senses as well: by listening, touching, smelling, and tasting. Even if these senses have to be trained to replace the eyes – it’s almost reachable. And like the translation tool in the first scenario, after a proper training, a braille display or screenreader can support the user as well.

So what connects the two scenarios? On the one hand it’s the effort one has to find the strength or motivation for (to learn a language or to use a screenreader) and on the other hand it’s the tools themselves (translation tool and screenreader). But these tools also need the access to the content of a medium – like the user herself. This is where the passive role of the user comes in – regardless of whether one has a disability or not.

The passive role of the user

Besides the active role the passive one is not in the hand of the user herself. Like in the definition above it’s more about „the quality of being easy to understand“ or „the quality or characteristic of something that makes it possible to approach, enter, or use it„.

With reference to the example above this is about the easy understanding and quality of a translation tool or screenreader. Tools the user can actively use to get access to a medium. So Accessibility is not a big problem – we just have to give those tools access to the content of a medium. Sounds easy, right? So why do we not provide this access then?

Provide Access Receive Ability (Accessibility)

Easily increase your target group

There are several technical requirements we have to consider besides some simple UX rules.

Let’s stay with the example: the usage of a translation tool. The user has a text in a foreign language and needs a translation in English. So the user enters the text into the tool and chooses a translation into English. But the tool is not returning any results. Instead it’s asking for a definition of the language the text is written in. But how should the user know? So the access to the text is not given.
Of course nowadays tools are able to find out which language the text is written in. But how? By analysing different patterns from reliable sources (a dictionary for example) and technical implementation. And why do we do that? To make the user happy? Maybe, but mainly because otherwise fewer people would use our translation tool.

So what is the diffenrence to the example with the screenreader? The people developing the screenreader can also create technical ways to understand content on a website – but in this case the „reliable source“ to create patterns of is the content itself. Like the dictionary, which is following a standard pattern of a language (syntax), the screenreader is dependent on the patterns of the website languages (funnily also called syntax). And why do we not do that? Because we want to make the user unhappy? Maybe, but mainly because we think no one of our target group is using the screenreader, right?

The unknowing, blind and deaf user

Let’s take it the short way: Google.

Google, like other search engines, is exactly that: an unknowing, blind and deaf user. What we know as SEO (search engine optimization) is from the technical point of view not really different from Accessibility. And why do we care about SEO so much? Because we think it’ll give our product advantages in the huge spheres of the World Wide Web.

So do we see Google as part of our target group? Only sometimes, because often the department responsible for SEO is excluded from the product teams and more related to marketing instead. So should we create a department for Accessibility? I’d say „no“, because Accessibility like SEO should be considered a part of the product teams – like UX has become over the years.

Why your product should focus on Accessibility?

If you need reasons or arguments to convince your team to focus on Accessibility – here are some values you’re welcome to use:

Without Accessibility you'll exclude valuable user groups.
With Accessibility you'll boost your SEO (search engine optimization).
You already have UX-Designers?
Enhance them to the next level with Accessibility.
How much do you know about your user?
Can you afford to ignore Accessibility?
Accessibility is part of everyday's life
(e. g. watching a video in the train with no headphones - subtitles give us access).
Ask your frontend developers - they'll be happy to stick to the syntax. Otherwise ask them why they're not.
Include Accessibility and it'll easily become part of your daily work with only little effort.

You’re convinced to focus on Accessibility but still need support in your team? No problem. Just contact me and I’m happy to support you.

Contact & Social