Blog on Mobile A11y

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

When testing your app with VoiceOver or Switch Control, a common test is to ensure you can reach every interactive element on screen. If these assistive technologies can’t focus all of your buttons how will your customers be able to interact fully with your app? Except there are times when hiding buttons from your assistive technology users is the better choice. Consider an app with a table view that has many repeating interactive elements - this could be a social media app where ’like, share, reply’ etc is repeated for each post. Or perhaps an e-commerce app with ‘wishlist, buy now, add to basket’ are repeated for each item. Visually these buttons won’t interrupt your users skimming the list of content, but for VoiceOver or Switch Control users, they will have to visit each one for every item on the screen. This is going to make navigating your app long and tedious, an means your users are more likely to drop out.

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.

iOS 14: Custom Accessibility Content

a11y@mobilea11y.com (Mobile A11y) — Mon, 29 Jun 2020 07:30:56 +0000

Each year at WWDC Xcode Santa brings us exciting new APIs to play with, and this year our accessibility present is Customized Accessibility Content. This API flew under the radar a little, I’m told this is because it’s so new there wasn’t even time for inclusion at WWDC. But this new feature helps to solve a difficult question when designing a VoiceOver interface - where is the balance between too much and too little content.

Accessibility Review: Huh? - International languages

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

The Accessibility Review series uses real world apps to provide examples of common accessibility issues and provide tips on how to fix them. Each of the developers has kindly volunteered their app to be tested.

Huh? is a dictionary and thesaurus app from Peter Yaacoub. Enter a word into the search bar then choose a dictionary service. Press search and the app will present your chosen service’s entry for the term you entered.

Accessibility Review: Figure Case - Button Labels

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

Figure Case is an app to help organise a tabletop miniature collection created by Simon Nickel. The app helps to track miniatures you own, and what state they currently find themselves in - unassembled, assembled, or painted.

Accessibility Review: Daily Dictionary - Screen changes

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

Daily Dictionary is an app from Benjamin Mayo providing a new word every day with definitions and real-world uses designed to help increase your vocabulary.

Assessing the app, I noticed Benjamin has made a design decision around presenting the app’s settings. Settings are slid down from the top of the screen, similar to a card UI that you might find in the Apple Maps app. Except with Daily Dictionary, the card is presented from the top of the screen. The card slides down or up in response to the user activating the settings button on the navigation bar.

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.

Mobile A11y Talk: Accessibility in SwiftUI

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

I was supposed to be attending the 2020 CSUN Assistive Technology conference to present a couple of talks, unfortunately with COVID-19 starting to take hold at that time, I wasn’t able to attend. In lieu of attending I decided to record one of the talks I was scheduled to present on Accessibility in SwiftUI.

SwiftUI is Apple’s new paradigm for creating user interfaces on Apple platforms, and it has a bunch of new approaches that really help create more accessible experiences. The talk is based on the series of SwiftUI guides available on this site.

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?

A11yUITests: An XCUI Testing library for accessibility

a11y@mobilea11y.com (Mobile A11y) — Tue, 17 Dec 2019 07:30:56 +0000

A11yUITests is an extension to XCTestCase that adds tests for common accessibility issues that can be run as part of an XCUITest suite. I’ve written a detailed discussion of the tests available if you’re interested in changing/implementing these tests yourself. Alternatively, follow this quick start guide.

Getting Started
#

Adding A11yUITests
#

I’m assuming you’re already familiar with cocoapods, if not, cocoapods.org has a good introduction. There is one minor difference here compared to most cocoapods, we’re not including this pod in our app, but our app’s test bundle. This means your podfile will look something like this.

Review: Accessibility for Everyone - Laura Kalbag

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

Laura’s introduction to web accessibility jumped out to me because it’s available as an audiobook. Being dyslexic I struggle to read, so prefer to listen to audiobooks where available. Unfortunately, most technical books aren’t available as audiobooks for a couple of potentially obvious reasons. Hearing code or descriptions of diagrams and illustrations read aloud may not be the best experience for an audiobook. As such, this book choses to leave those out of the audio version. For this review, I also purchased the eBook version. Having illustrations available there did make it feel like I had lost out by reading the audiobook version. Screen readers do their best to convey information when greeted with diagrams and other non-text content, and I wonder if more could have been done here to convey this information in an audio format. That said, I am grateful Laura took the time to record an audio version, as in all honesty, I wouldn’t have completed this book up otherwise. This is not an indictment of Laura or her book, simply that I struggle to read a full book.

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.

Review: Design Meets Disability - Graham Pullin

a11y@mobilea11y.com (Mobile A11y) — Sat, 12 Oct 2019 07:30:56 +0000

Design Meets Disability was recommended to me by accessibility consultant Jon Gibbins while we were sharing a long train journey through mid-Wales. We were talking, amongst many things, about our love for Apple products and their design.

I am a hearing aid wearer, my aid is two-tone grey. A sort of dark taupe grey above, and a darker, almost gun-metal grey below. There’s a clear tube into my ear. This is fine, I don’t hate it. It’s certainly better than the nowhere close to anyone’s actual skin colour weird pinky-taupe colour of older style aids. But, why is the tube clear? I didn’t make the design decision here, but I think we can safely assume it’s clear to hide the tube. But why would I want to hide it?

Podcast: iPhreaks - iOS Accessibility

a11y@mobilea11y.com (Mobile A11y) — Wed, 09 Oct 2019 07:30:56 +0000

I was asked to guest on the iPhreaks podcast to discuss iOS accessibility. We talked about why accessibility is important, how you can improve it in your apps, and some of the changes iOS 13 and SwiftUI bring.

unfortunatley iPhreaks don’t provide a transcript, but they do provide a comprehensive write-up on their site.

Mobile A11y Talk: Accessibility without the 'V' Word

a11y@mobilea11y.com (Mobile A11y) — Tue, 08 Oct 2019 07:30:56 +0000

I was honoured in 2019 to be able to give my first full conference talk at CodeMobile. I was then lucky enough to be able to repeat that talk at NSLondon, NSManchester, and SWMobile meetups.

As an iOS developer, I know accessibility is important for a huge range of people. But at times I think I can treat it like an afterthought. Accessibility Without the ‘V’ Word covers a skill I think we as software engineers would benefit from developing - empathy towards our users. Remembering that everyone who uses our software is different, and have different abilities, experiences, and requirements. VoiceOver is an essential tool for many of our customers, but it’s not the only thing we should consider with 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.