After two years of remote conferences, we all breathed a sigh of relief in 2022. Thus, the 10th edition of the NSSpain conference in September was bigger than ever and buzzing with speakers, information and many eager developers. There were way too many interesting topics in the 22 talks over 2 days to fit in one blogpost, as each and every one of them deserves its own spotlight. Hence today, we will dive specifically into the world of accessibility. A topic that is actually not only relevant for developers, but for designers and copywriters as well.
Exclusion
This dive into accessibility is actually a safari through unknown territory for most, as 85% of you probably have no need to use most of the available accessibility features. Hold on, does that mean that 15% of people do need some form of support when they use their smartphone? Yes. 15%. Let that percentage sink in for a minute. It means that you, as a developer, may miss out 15% of your audience if your app does not adhere to at least some of the available support features out there. Talented developer Bas Broek opened the eyes of many participants at NSSpain when he presented these numbers. Reality is that most developers aim to get their product to work as they perceive it themselves. This might partly be caused by the extra hours they will need to spend working on it to integrate specific features for people who experience the app differently.
MAKING APPS WORK FOR ALL
Although Apple does offer many ways to support people with specific disabilities, it does not necessarily mean you need to implement all of these at once. An app without any support features might be worthless to an impaired user, an app with only a few features enabled however already makes a huge difference. As Daniel Devesa Derksen-Staats quoted Novall Swift on Twitter: “We have one job, and that’s to make apps work. If you’re not implementing accessibility features, you’re forgetting to make it work for a lot of users”.
The first and easiest thing developers should do when implementing accessibility features, is to make use of the `accessibilityLabel` properties on most `NSObjects`. They tend to give a description of what the specific object entails, such as the ‘Close’ label on a button. Keep in mind that Apple reads out loud what kind of element it is, so in the case of a ‘Close’ button it will already tell the user that it is a button. Copywriters should therefore be practical and keep the labels clean and short, while not leaving out the essence of the element.
While looking up the `accessibilityLabel` documentation, you can see there is a lot more to gain, such as `accessibilityValue`, `accessibilityHint` and `accessibilityTraits`. These are some low hanging fruit you should be able to implement in your apps fairly easily. And while you’re at it, try exploring the ‘heading’ function to see how powerful it can be.
Secondly, when developing your app further, be aware of information cluttering. A list of items, for example, can contain extensive metadata. If a user needs to go through 10 or more elements to grasp the meaning of the item, they might be lost after item number 3 or 4. To prevent this from happening, you can easily configure the containing parent as an accessibility element, and include a summarised description of all its subviews. To navigate to the specific elements, or skip towards the next item, the user should be able to use different sets of gestures; swipe horizontally or vertically, either with one, two, three or even four fingers.
THE PILOT
One quote of Daniel Devesa really did hit home for me:
Imagine the army has multiple F-16 pilots and is in need of multiple jets. How do you know what size the chair should be? They started measuring all their pilots, and took the average height. After building the chairs for the average height of the pilots, not even one fit! This is because the average person does not exist.
So when you think you are building your app for your ‘average user’, you are building an app for nobody. You need to give users of your apps several options to choose from, for example the font size in your app. You can either adhere to the iOS system settings, or implement a custom slider to determine the required size. The same applies to light and dark mode or other color schemes, language, right-to-left texts or even the interaction with the content. Even though your buttons should be a minimum size of 44×44px, people might not like or be able to use buttons. For those users you can implement the `accessibilityCustomActions` and `accessibilityCustomRotor` properties for your grouped items. The user can then use a rotor to switch between items, and use a flick gesture to walk through the options, such as the ‘like’, ‘reply’ or ‘share’ actions in each item.
THE DELICATE EYE
When you have managed to enhance accessibility by integrating the basic steps, it is time to align with the designers of the app. Most apps are designed to be eye candy. Beautiful, colorful, playful, or maybe very clean to show only the most important information. When designing an app, you should definitely consider the contrast between colors. Light grey does not fit on dark grey, and yellow does not fit well on light green for example. While some designs look beautiful with those colors applied, some people will be unable to distinguish between the colors, rendering your app unusable. If in doubt, there are numerous tools to help you with this. Did you know, for example, that UIColors can also have accessibility names, so people know what color they are?
Besides contrast, the shape can also be extremely helpful to guide your user. Instead of giving an icon only a different fill-color, consider changing its form slightly. It can be bigger, bent differently or merely underlined, but different ways of showing a state change can improve your app's appearance more than you can imagine.
LET'S START IMPLEMENTING
We’ve covered some ground on why you should care for implementing accessibility. An average user simply does not exist and about 15% of smartphone users need some form of support in order to be able to use your app. We discussed what you, as a developer, can do to start making your app a good place for everyone. We also briefly touched upon what copywriters or designers should take into account when working on their apps.
Most of this is not rocket science, and Apple paves the way for you to implement the basic functionalities. Now it is your job to convince product owners and project managers of its importance. Let’s start implementing!
