Developing for accessibility is basically keeping in mind that the end user is an actual human being that might or might not have limitations, disabilities, impairments and so on.
I first started developing for accessibility when I joined the Lynda.com team and later I dug deeper into the concept while working on the LinkedIn Learning Android app. I very quickly realised that most of us are using the wrong definition of accessibility — and yes, that was true for me too. We tend to think that accessibility only addresses the problems that visually impaired people face. Although concentrating on accessibility does help this group of people, the idea actually includes a wider range of people with other limitations:
- Visual, auditory, physical, speech, cognitive and neurological disabilities
- Age-related impairments
- Low literacy or lack of fluency in a language
- Low bandwidth connections or the use of older technologies
- New or infrequent users
- Temporary disabilities (e.g. injuries or illness…)
What I also learned from that experience is that accessibility shouldn’t be treated as a “nice to have” for a later step. Nor should it be excluded from a MVP feature set. The sooner you think about accessibility issues, the easier it gets.
So what do I need to look for in order to make my app more accessible?
To answer the question, here is a list of requirements that you need to meet.
Contrast ratios: this primarily helps users who have visual impairment and is calculated based on a formula that compares the colour of text or images containing text and the colour of the adjacent background. The W3C has set a minimum ratio of 3.00 for large or small text that is bold, and a minimum ratio of 4.5 for small text.
In order to confirm your colour palette meets these criteria, there are many websites that can check the contrast ratio given the colour of the text and the colour of the background — here’s an example: http://leaverou.github.io/contrast-ratio/
Colour should not be the only way to convey information: some people might suffer from forms of colour blindness like protanopia or deuteranopia which prevent them from differentiating between the colours red and green. For this reason, using a red highlight to show an error might not provide the necessary information without the addition of an error message.
You can see how the supplemental error message delivers more information to such users in the following images. They simulate the vision of people with protanopia and deuteranopia.
Touch target: in order to help people with finger joint mobility issues, older users or users who are simply not wearing their glasses, we need to make sure any interactive elements (buttons, tabs, checkboxes, etc…) have a minimum touch target of 48dp. Note that we are talking about touch target here and not the button size. You can still have smaller sized buttons but set a bigger touch target in the code, or by adding a padding around the button.
Swipe/drag gestures should not be the only way to interact with the app: Many users with motor disabilities need the help of some external keyboard or directional pads, and they are not able to swipe or drag with these devices. Think of an alternative way to close a notification other than swiping it away. You could, for example, set a dismiss button to be visible only if accessibility settings are enabled on the device.
Focus and traversal order
The traversal order describes how users can navigate between elements. The focus specifies whether a view is interactive, conveys useful information or is only decorative. This helps users that need add-on devices like external keyboards or directional pads, as well as those who have a screen reader activated that describes the screen content — like Talkback for Android or VoiceOver for iOS.
- Traversal order goes from top to bottom and from left to right: If using external keyboards to navigate through the app, it is crucial to have clear navigation logic.
- A toolbar in mobile apps should always get first focus: Having first focus on the back button is important so users do not have to go through the whole screen just to dismiss it.
- Decorative images / views should not have accessibility focus: It is not useful to focus on an element that neither has a click role nor contains a meaningful information.
- Partially hidden views should still describe all content: There are no secrets here, so if an item is focused it needs to tell the user everything it knows!
- Hidden screens should not get focus: If a new screen shows up on top of another or a pop up appears, whatever is behind should not be focusable.
Interactive items & Notification:
This section is about making screen readers more useful for the end users. Screen readers, as mentioned in the last section, provide an audio description of the content of the screen.
There is some information that screen readers need to emphasise and some that is completely superfluous. Here are the main examples:
- All interactive (clickable/scrollable) views should have an accessibility role: Tell the users what are they dealing with, whether an element is a button, a checkbox or a tab.
- Buttons should have a correct action: Tell people exactly what the button does. Does it open some settings? Does it play a video? Does it dismiss something? Be specific.
- Toggle buttons, switches, checkboxes, etc. should have a state: Tell the users what the element state is. Elements can be enabled, disabled, expanded, collapsed, etc.
- Tabs should specify their index and the total tab count: Users want to know where they are now and how far they can go. Is this tab 2 out of 4, or tab 1 out of 300?
- Any change of layout, screen or status should be announced to the user: Give them some feedback about what they just did, for example a confirmation message or an error message.
In today’s world, evaluating your code depends on more than just whether it is working or not, or how well it performs. Now we can even talk about coding as more of an art! We care about performance just as much as code readability, testing, and other factors. Accessibility is just one new aspect to develop further, keeping it in mind through all steps of development: design, code, review and test. Making an existing app accessible is likely going to present a major challenge the first time you do it, but it becomes more or less automatic once it becomes part of your daily coding.