Blog on Mobile A11y

Checking accessibility with SwiftUI Previews

a11y@mobilea11y.com (Mobile A11y) — Sun, 12 Apr 2026 21:45:55 +0000

SwiftUI previews offer a fast, practical way to see the output of our view code. But did you know you can also use them to test accessibility-related UI changes including Dynamic Type, localisation, and system accessibility settings, all without needing a physical device.

No, SwiftUI is not “Accessible by default”

a11y@mobilea11y.com (Mobile A11y) — Fri, 03 Apr 2026 12:41:50 +0000

"SwiftUI is accessible by default" is one of the most repeated misconceptions in iOS development. Here’s why that’s wrong and what you actually need to watch out for.

iOS Accessibility Values

a11y@mobilea11y.com (Mobile A11y) — Sun, 19 Jun 2022 10:30:56 +0000

For iOS, Accessibility values are one of the building blocks of how Accessibility works on the platform, along with traits, labels, hints, and showing/hiding elements. If you’re familiar with WCAG or web accessibility, accessibility values are the value part of WCAG 4.1.2: Name, Role, Value.

Values
#

Not every element in your view will have a value - in fact, most won’t. Any element that ‘contains’ some data, data that is not included in the element’s label requires an accessibility value to be set. If you’re using standard controls provided by Apple, these values will be set for you. But if you make something custom you must add a value where necessary, and if you’re extending a standard control, testing with VoiceOver is essential.

iOS UIKit Accessibility traits

a11y@mobilea11y.com (Mobile A11y) — Fri, 13 Aug 2021 07:30:56 +0000

Accessibility traits on iOS is the system by which assistive technologies know how to present your interface to your users. The exact experience will vary between assistive technologies, in some cases they may change the intonation of what VoiceOver reads, or add additional options for navigation, sometimes they will disable that assistive technology from accessing the element, or change how the assistive tech functions. They are the ‘Role’ part of the fundamental rule of making something accessible to screen readers - WCAG’s 4.1.2: Name, Role, Value.

iOS Custom Accessibility Actions

a11y@mobilea11y.com (Mobile A11y) — Sun, 01 Aug 2021 07:30:56 +0000

Learn when and how to use iOS custom accessibility actions to reduce navigation noise for VoiceOver, Switch Control, and keyboard users — without hiding functionality.

Test Your App's Accessibility with Evinced

a11y@mobilea11y.com (Mobile A11y) — Wed, 24 Mar 2021 07:30:56 +0000

Disclosure: Evinced has paid for my time in writing this blog, and I have provided them feedback on the version of their tool reviewed and an early beta. I agreed to this because I believe in the product they are offering.

Testing your app for accessibility is an essential part of making an accessible app, as with any part of the software you build, if you don’t test it, how can you be sure it works? Because accessibility is human, there are no true shortcuts to this, a through manual test will always be the most productive form of accessibility testing possible. But with some carefully designed automated checks, you can detect common accessibility issues quicker and earlier. This makes fixing them easier, the chance of these errors reaching your customers is reduced, and it saves you valuable time for resolving more complex issues. It’s not an easy problem to solve - I’ve tried with A11yUITests, and Apple built their offering, Accessibility Inspector, right in to Xcode. Now a new tool has entered the arena from Evinced, the iOS Accessibility Debugger.

How Do I Get My App an Accessibility Audit?

a11y@mobilea11y.com (Mobile A11y) — Sun, 21 Mar 2021 07:30:56 +0000

This is a common question I get asked - how do I go about arranging an accessibility audit for my app so I know where I can make improvements? If you’re truly looking for an answer to that question then I have a few options for you below, but first, are you asking the right question?

Accessibility Isn’t About Box Ticking
#

You can’t make your app accessible by getting a report, fixing the findings, and accepting it as done. Accessibility is a constant process of improvement to make sure your app works better for as many people as possible. This could mean adopting new accessibility APIs as they become available, or it could mean reacting to feedback you receive from your users. Disability happens when someone’s abilities don’t mesh with the tools we have provided, and as disability is such a wide spectrum there will always be someone disabled by your app. How that manifests will vary depending on your app, the people using it, and over time, so one assessors report is not enough to claim your app is 100% accessible, because there is no such thing. To claim this is both naive and a little offensive.

Quick Win - Start UI Testing

a11y@mobilea11y.com (Mobile A11y) — Wed, 03 Feb 2021 07:30:56 +0000

I’ll admit, adding UI testing to an app that currently doesn’t have it included is probably stretching the definition of quick win, but the aim here isn’t 100% coverage - not right away anyway. Start small and add to your test suite as you gain confidence. Even a small suite of crucial happy-path UI tests will help to ensure and persist accessibility in your app. And the more you get comfortable with UI tests the more accessible your apps will become, because an app that is easy to test is also great for accessibility.

Quick Win - Support Dark Mode

a11y@mobilea11y.com (Mobile A11y) — Thu, 28 Jan 2021 07:30:56 +0000

Many people don’t realise dark mode is an accessibility feature. It’s often just considered a nice to have, a cool extra feature that power users will love. But dark mode is also a valuable accessibility feature. Some types of visual impairment can make it painful to look at bright colours, or large blocks of white might wash over the black text. Some people with dyslexia or Irlen’s Syndrome can struggle to read black text on a white background. Like almost any accessibility feature, dark mode is about providing flexibility to your users so they can use your app in the way that is most comfortable to them.

Quick Win - Support Landscape

a11y@mobilea11y.com (Mobile A11y) — Thu, 28 Jan 2021 07:30:56 +0000

If you have a regulatory requirement to provide accessibility in your app (spoiler, you do) the chances are it will say you have a requirement to reach WCAG AA. While this is likely meaningless to anyone other an accessibility professionals, in short it means you are providing the minimum level of accessibility features required to make your app usable by the majority of people.

This post is about one such requirement, the jazzily titled Success Criterion 1.3.4. 1.3.4 is often overlooked, I’ve see it forgotten by accessibility auditors, overlooked by testers, removed by engineers, and ignored by designers. Yet this feature is one that is already enabled by default in your app. One that you have to choose to disable. For both Android and iOS when you create a new app, the app supports landscape mode out of the box, and all you need to do to continue supporting it is to build robust interfaces, and not disable it. Yet often one of the first things developers do when creating a new app is to disable landscape modes.

Quick Win - Image Descriptions

a11y@mobilea11y.com (Mobile A11y) — Tue, 19 Jan 2021 07:30:56 +0000

Images are a major part of our apps. They add meaning and interest, they give your app character and context. The adage is that a picture is worth a thousand words. But if you can’t see the image clearly, how do you know what those words are?

If you aren’t providing image descriptions in your app many of your users will be missing out on the experience you’ve crafted. The result can be an app thats missing that spark an character, or worse an app thats just meaningless and unusable. Fortunately adding image descriptions is simple.

Quick Win - Text Contrast

a11y@mobilea11y.com (Mobile A11y) — Tue, 19 Jan 2021 07:30:56 +0000

How many shades of grey do you use in your app? OK, maybe thats a bit cruel towards designers, grey is a great colour, but the problem with grey is that it can be deceptively difficult to distinguish from a background. And this problem is not just limited to greys - lighter colours too can blend into the background. This effect can be heightened too for people who have blurred or obscured vision, or one of many forms of colour blindness.

iOS Attributed Accessibility Labels

a11y@mobilea11y.com (Mobile A11y) — Sun, 03 May 2020 10:30:56 +0000

Attributed accessibility labels are an incredible tool for making some next-level accessible experiences. They let you tell VoiceOver not just what to speak, but how to say it too.

Using the accessibilityAttributedLabel property you can provide an NSAttributedString to VoiceOver, much the same way you would provide an NSAttributedString to a label’s attributedText property to display a string with an underline or character colour for example. The difference here is that all of our attributes are instructions for VoiceOver.

Writing Great iOS Accessibility Labels

a11y@mobilea11y.com (Mobile A11y) — Sun, 03 May 2020 09:30:56 +0000

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.’

When to use Accessibility Labels

a11y@mobilea11y.com (Mobile A11y) — Sun, 03 May 2020 08:30:56 +0000

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.

iOS Accessibility Labels

a11y@mobilea11y.com (Mobile A11y) — Sun, 03 May 2020 07:30:56 +0000

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.

A11y Box Android

a11y@mobilea11y.com (Mobile A11y) — Sun, 26 Apr 2020 07:30:56 +0000

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.

A11y Box iOS

a11y@mobilea11y.com (Mobile A11y) — Wed, 26 Feb 2020 07:30:56 +0000

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.

Android Live Regions

a11y@mobilea11y.com (Mobile A11y) — Tue, 11 Feb 2020 07:30:56 +0000

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?

A11y is not accessible

a11y@mobilea11y.com (Mobile A11y) — Thu, 28 Nov 2019 07:30:56 +0000

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.

Baking Digital Inclusion Into Your Mobile Apps

a11y@mobilea11y.com (Mobile A11y) — Thu, 25 Jul 2019 07:30:56 +0000

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.

What The European Accessibility Act (Might) Mean for Mobile Development

a11y@mobilea11y.com (Mobile A11y) — Mon, 24 Jun 2019 07:32:16 +0000

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.