A good accessibility label lets your customer know exactly what a control does in as few words as possible, without having to rely on implied context.
Don’t Add the Element Type # iOS already knows your button is a button and your image is an image, it does this using an accessibility trait. If you label your button as ‘Play button’ your VoiceOver customers will hear ‘Play button. Button.’
There’s a few circumstances when you’ll want to set your own accessibility label, such as…
An interactive element that you haven’t given a text value to, such as an image button. An interactive element with a long visual label. An interactive element with a short visual label that takes context from your design. A control or view you have created yourself or built by combining elements. Images of text. Elements Without a text value # Take the controls for a music player as an example. Below is a screenshot of the controls for Spotify’s music player, each icon is a button. They’re all visual, but not text. As they’re buttons they’re all available to assistive technology but without a text value, assistive technologies would not know how to present each button to your user. VoiceOver would likely read each as ‘button’ giving no indication what each button does. Voice Control users would have to refer to each button by a number based on the order it appears on the screen.
This blog was inspired by Jeff Watkins’ series of blogs on UIButton. UIButton is a fundamental part of building interfaces on iOS. So much so, that it probably doesn’t get the love it deserves. But it’s also really powerful and customisable when used correctly.
Accessibility labels on iOS I feel are very similar. They’re fundamental to how accessibility works on iOS, yet I think they suffer from a few PR issues. Firstly, Apple has done such a good job with them that we often don’t give the humble accessibility label the consideration it deserves, instead relying on the Apple default behaviour. Secondly, they’re just some text, right? Who can get excited about just a boring old label? Well, I’m sure this won’t surprise you, but I can.
A few months ago I shared a project I’d been working on for iOS exploring the accessibility API available on that platform. The Android accessibility API is equally large and full featured, and really deserves the same treatment. So here’s A11y Box for Android.
A11y Box for Android is an exploration of what is available on the Android accessibility api and how you can make use of it in your apps. It’s open source, and open for contributions. So please feel free to fork if there’s a feature I’ve missed or something that needs a little clarification.
iOS’ UIAccessibility API is huge. I like to think I know it pretty well, but I’m always being surprised by discovering features I previously had no idea about. Like many things on iOS, the documentation for UIAccessibility is not always complete, even for parts of the API that have been around for years.
In an attempt to help spread the knowledge of some of the awesome things UIAccessibility is capable of, I’ve created A11y Box for iOS. It’s an open source project that covers every feature I know about on the UIAccessibility API, and a little more too.
Live Regions are one of my favourite accessibility features on Android. They’re a super simple solution to a common accessibility problem that people with visual impairments can stumble across.
Say you have a game app, really any type of game. Your user interacts with the play area, and as they do, their score increases or decreases depending on your customer’s actions. In this example, the score display is separate to the element your customer is interacting with. For a blind or partially sighted user, how will they know their interaction has had a consequence against their score?
Accessibility is a long word. It’s not the simplest of words to read or to spell, so it seems like a word that would be a good candidate for abbreviation. The common abbreviation of accessibility is a11y. We take the A and Y from the beginning and end of accessibility, and 11 for the number of letters in between. This abbreviation also creates a pleasing homophone for ‘ally.’
The irony of this abbreviation is that a11y isn’t accessible. Using jargon in this way can be a fail for WCAG guideline 3.1.3. Some people with disabilities such as autism can struggle to understand non-literal language. Dyslexia can make some characters difficult to distinguish, and mixing letters and numbers in this way can exacerbate this. Screen readers often won’t understand how to pronounce non-common words and abbreviations, so the pronunciation of a11y can vary. When writing we should generally avoid domain-specific jargon where possible, especially where there there is a common alternative like accessibility.
I was asked by Capital One to contribute an accessibility piece to the Capital One Tech Medium. The blog, titled Baking Digital Inclusion Into Your Mobile Apps, briefly covers what we mean by disability and what we can do to make our mobile apps work better for everyone.
The European Accessibility Act, or EAA is due to become law in Europe later this year, and it defines some specific requirements for mobile. In fact, its the first accessibility legislation that I’m aware of, anywhere, that explicitly covers mobile apps.
Since 2012 the European Union has been working on standardising accessibility legislation across Europe. The ultimate aim is to both improve the experience for those who need to use assistive technology, but also to simplify the rules business need to follow on accessibility. The years of discussions and consultations has lead to the European Accessibility Act, written in 2018, which covers a range of requirements for, amongst other channels, mobile.