Mobile on Mobile A11y

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.

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.

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.

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.

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.