IOS 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

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.

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

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.

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.

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.

XCUITests for accessibility

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

For a while now I’ve been looking at possibilities for automated accessibility testing on iOS. Unfortunately, I’ve not found any option so far that I’m happy with. I am a big fan of Apple’s XCUI Test framework. Although it has its limitations, I believe there’s scope for creating valid accessibility tests using this framework. Over the last few months I’ve been trying things out, and here’s what I’ve come up with.

SwiftUI Accessibility

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

Accessibility is important. We can take that as a given. But as iOS devs we’re not always sure how to make the most of the accessibility tools that Apple have provided us.

We’re lucky as iOS developers that we work on such a forward-thinking accessibility platform. Many people consider Apple’s focus on accessibility for iOS as the driver for other technology vendors to include accessibility features as standard. To the point that we now consider accessibility an expected part of any digital platform. This was not the case before 2009.

SwiftUI Accessibility: Semantic Views

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

Semantic views are not new to SwiftUI, but changes in SwiftUI mean creating them is simple. Semantic views are not so much a language feature. They’re more a technique for manipulating the accessible user interface and improving the experience for assistive technology users.

A what view?
#

A semantic view is not one view, but a collection of views grouped together because they have meaning (or semantic) together. Take a look at this iOS table view cell from the files app.

SwiftUI Accessibility: User Settings

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

SwiftUI allows us to read environmental values that might affect how we want to present our UI. Things like size classes and locale for example. We also get the ability to read some of the user’s chosen accessibility settings allowing us to make decisions that will best fit with your customer’s preference.

Why?
#

Before we cover what these options are and how to detect them I think it’s important to briefly cover why we need to detect them. There’s a few dos and don’ts worth consideration.

SwiftUI Accessibility: Attributes

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

When a customer enables an assistive technology to navigate your app the interface that technology navigates isn’t exactly the same as the one visible on the screen. They’re navigating a modified version that iOS creates especially for assistive technology. This is known as the accessibility tree or accessible user interface.

iOS does an incredible job at creating the AUI for you from your SwiftUI code. We can help iOS in creating this by tweaking some element’s accessibility attributes. Setting some accessibility attributes through modifiers is a simple way to add a little more meaning and context for your assistive technology users.

SwiftUI Accessibility: Traits

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

Accessibility traits are a group of attributes on a SwiftUI element. They inform assistive technologies how to interact with the element or present it to your customer. Each element has a selection of default traits, but you might need to change these as you create your UI.

In SwiftUI there are two modifiers to use for traits, .accessibility(addTraits: ) and .accessibility(removeTraits: ) which add or remove traits respectively. Each modifier takes as its argument either a single accessibility trait or a set of traits.

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.

SwiftUI Accessibility: Accessible User Interface

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

Take a look at your app. Notice the collection of buttons, text, images, and other controls you can see and interact with that make up your app’s user interface. When one of your customers navigates your app with Voice Control, Switch Control, VoiceOver, or any other assistive technology, this isn’t the interface they’re using. Instead, iOS creates a version of your interface for assistive technology to use. This interface is generally known as the accessibility tree. Apple often refers to this as your app’s Accessible User Interface. For brevity and consistency in this article, I’ll refer to it as the AUI

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.

SwiftUI Accessibility: Sort Priority

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

Assistive technology, such as VoiceOver, works in natural reading direction. In English, and most other languages, this means top left through to the bottom right. Mostly this is the right decision for assistive technology to make. This is the order anyone not using assistive technology would experience your app. Sometimes though, we make designs that don’t read in this way. By using the .accessibility(sortPriority: ) modifier we can set the order in which assistive technology accesses elements. To achieve this, you must group elements in a stack (HStack, VStack or ZStack). Then use the .accessibilityElement(children: .contain) modifier. The higher the number we give to .accessibility(sortPriority: ), the earlier VoiceOver will focus on the item. This means an element with a priority of 2 comes before priority 1, and so on.

SwiftUI Accessibility - Named Controls

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

One big accessibility improvement in SwiftUI comes in the form of named controls. Nearly all controls and some non-interactive views (see Images) can take a Text view as part of their view builder. The purpose of this is to tie the meaning to the control.

Toggle(isOn: $updates) {
 Text("Send me updates")
}

Imagine a UIKit layout with a UISwitch control. We’d most likely right align the switch, and provide a text label to the left. Something like this.

SwiftUI Accessibility: Dynamic Type

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

Like all accessibility features, Dynamic Type is about customisability. Many of your customers, and maybe even you, are using Dynamic Type without even considering it an accessibility feature. Dynamic type allows iOS users to set the text to a size that they find comfortable to read. This may mean making it a little larger so it’s easier to read for those of us who haven’t yet accepted we might need glasses. Or it could mean ramping it right up for people with low vision. Or taking the text size down for extra content and privacy. Like many accessibility features on iOS, Dynamic Type support has been greatly improved in SwiftUI. There are a few things you should do (and not do) to make the most of it.

SwiftUI Accessibility: Images

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

Images in SwiftUI are accessible by default. This is the opposite of what we’d experience in UIKit, where images are not accessible unless you set isAccessibilityElement to true.

Sometimes making images not accessible to VoiceOver is the right decision. Like when using a glyph as a redundant way of conveying meaning alongside text. An example of this would be displaying a warning triangle next to the text ‘Error’ or a tick next to ‘success’. If these images were accessible your VoiceOver users would hear the word ‘error’ twice and have to swipe between each one. This makes navigation longer and frustrating for your customer.