15 percent of people using digital platforms have some form of disability that inhibits their digital behaviour and thereby creates another use patterns. The term accessibility may not be part of the agenda when developing apps, but it should be.
If not just for the bettering of mankind, but in time to be compliant with future legislation on the subject. Two weeks ago UX Copenhagen enlightened the subject of accessibility from an ethical point of view to broaden the knowledge on how you design for inclusion and accessible products, without creating unnecessary barriers for users.
This motivated us to write about the subject from an app specific point of view. The following will, therefore, look into the term accessibility, how it influences user scenarios and why you should strive for highly accessible apps.
What is accessibility?
Accessibility simply put, can be as answered by this question, “can your app (or any other service) be used by everyone?” If not, then it is not accessible. This may be a very black and white way to put it, but you get the idea. You can look at the term from two angles, the ‘everyday struggles accessibility’ and ‘the accessibility as a result of a disability’.
The everyday struggles are essentially when you are incapacitated for a limited amount of time in your everyday life; this can be things like; having a baby in one hand, having a hangover or being located in a place where your screen is not fully visible.
The other angle is regarding accessibility is caused by disabilities for example being blind, deaf or having another physical long-term restriction, that could affect your device use behaviour. Just to give you a bit more to consider the disabilities, they should be seen in relation to a sliding scale in regards to severity.
For example, only 3-4% of those referred to as blind are completely unable to see, while the remaining are only partially inhibited. To design inclusive apps with high accessibility you need to consider both to ensure you do not create unnecessary barriers for your users.
Creating accessible apps
Looking into the approach of creating highly accessible apps there are tangible actions while others require that we challenge our cognitive patterns.
Starting with the tangible actions we have listed a few examples, that will take you in the right direction when developing your app:
- Contrast – The visual representation of text and image should have a contrast ratio. The ratio depends on text size and type. There are plenty online colour-checkers, where you simply type in your colour codes, to see if the ratio is sufficient.
- Dynamic text – Currently the standards require that users should have the option to zoom into 200% when having activated dynamic text in their settings.
Use of colour – Don’t use colours as sole distinguishers. Colour blindness is a common vision deficiency, it will inhibit more people than you may think.
- Don’t test with experts – This may be a given, but to get a thorough understanding of yours apps accessibility, you need to test with a broad user segment and not the experts on disabilities.
Avoiding biases when using machine learning – This probably isn’t necessary to if you are an expert in machine learning, but at UX Copenhagen we were presented with some gruesome mistakes, where apps favoured certain races or genders because they failed to use a diverse dataset in their development.
- Test your app with variety – When developing your app, try to inhibit yourself in some sort of way when testing the progress. Either by simply narrowing your eyes, using only one hand or a more comprehensive method. This allows you to fix potential barriers ongoing with your development (but should not be a substitution for testing with real users!).
The above mentioned are pretty hands-on guidelines, but when we develop apps we must consider that both the producers of the app and our users are influenced by cognitive biases. At UX Copenhagen Dave Dylan Thomas explained that 90 % of cognition is happening below the threshold of conscious thought, why we as the human race don’t really have a clue why we act the way we do most of the time.
This means that the biases in most cases are uncontrollable, and taken as there is more than a hundred different biases, it is highly likely that it influences our behaviour in interaction with apps. Take for example pattern recognition, which influences our attitude towards race and sex based on the patterns that we have met throughout our lifetime.
Biases are often linked with a negative assumption, but there are ways to use these thoughts for the better and ways to work around biases. First of all, it is important to look into the user scenarios, and how the surroundings and the interface will trigger user actions.
We have listed some examples of learnings from UX Copenhagen that can be relevant to consider when designing for biases in order to strengthen your accessibility.
- Choice architecture – Design your app flow to cater for user decisions made in real-life contexts. Users will act depending on their environments and the choices they are given.
Specific information – Consider what information is really needed for your user to complete an action and remove the noise, thereby decreasing chances of biases.
- Easy to read, easy to do – Common knowledge, but is easily forgotten in the eagerness of getting a users attention. Research also shows that text that is easy to read is perceived as truer than things that are more complex. Text that rhymes are also perceived as more convincing.
- Visualisation – By using hierarchy and making your message more transparent, the user feels more comfortable while you increase ease-of-use, which in turn makes the user trust you.
These are a small section of the tangible actions you can take towards increasing accessibility. As you can probably see these actions go hand-in-hand with focusing on providing an optimal and intuitive user experience. If this hasn’t convinced you to look into this subject, then the legislation might.
What are the legal implications of accessibility?
In October 2016 the EU formally approved a refreshed version of their accessibility directive that brings forth guidelines and standards for how to conduct accessibility on public sector websites and apps across EU member states.
The legislation has been four years in the making with ongoing milestones – after 12 months new public websites must be compliant, after 24 months older public websites must be compliant, and after 33 months mobile apps must be compliant – the specific deadline for public apps to be compliant is June 23rd, 2021.
The legislation is first of all influencing public websites and apps, but it will also involve certain private sectors to be compliant, like banking, transportation, and e-commerce. It is a subject to be taken very seriously! Countries like Norway and the Netherlands are already leading the charge on accessibility, Norway fines non-compliant companies.
The general definition for you to remember when developing your app is that it should be usable, understandable and robust. Of course, this statement can be quite subjective, which is why we would recommend companies to define your understanding of this along with KPI’s for how your app will perform.
If your app is influenced by the legislation you will also need an accessibility statement that describes your efforts in regards to the directive (there are templates available). For internal purposes, this may be time well spent even if your app is not influenced by the legislation in the first round thereof.
Your next step in regards to creating accessible apps
Are you eager to start making your app more accessible? Then first let us point out that it matters who you get to assess your app’s accessibility – as Upton Sinclair put it:
“It is difficult to get a man to understand something when his salary depends on his not understanding it.”
If you are interested in learning more, the talks from UX Copenhagen are up on their website, you can research into inclusive design or you can give us a call or a mail and we will be happy to sit down and discuss the issues at hand.