At Picnic we’re constantly working towards replacing the traditional grocery shopping experience with a digital alternative. This comes with a unique set of challenges that have never been tackled before. One of them is to make the digital store maximally usable to people with disabilities, ideally as usable as it is for everyone else.

Fortunately, we’re not alone in this initiative. Apple has been working on technologies for people with disabilities for many years now. It was no surprise that this year at WWDC 2016, there were three sessions dedicated entirely to Accessibility.

Getting started with Accessibility

Accessibility covers four major functional areas:

Hearing Vision Learning Physical and Motor

If you’ve never used Accessibility before, check out this brief accessibility features list.

There are a lot of things to be done before an app becomes fully accessible. It is best if you start thinking about accessibility from day one. But even then it is not an easy job. For every design decision you make, this is one extra thing to think about. In our experience, even a lot of Apple apps are not entirely accessible.

Things are even harder if you want to enable accessibility for an existing project, particularly an app as big as the Picnic shopping app. We have expanded the Picnic app on a daily basis since its genesis in late 2014. And there is always some more code waiting to be merged in.

The first challenge in getting started with accessibility, was to figure out a road map. We decided to start with supporting VoiceOver initially, as VoiceOver directly helps people with vision disabilities and provides broad coverage for all major Accessibility functions.

What is VoiceOver?

VoiceOver is the amazingly powerful engine that speaks the UI to people with vision disabilities, in all major languages in the localized accent. How cool is that!

It already works great out of the box. If your app only uses the standard UIKit controls, there’s nothing more for you to do than sit back and relax. But, if you’ve been working on making things awesome, it is very likely that you introduced some custom UI elements. If so, then probably VoiceOver either has no idea how to access your awesome UI or is accessing it incorrectly.

Our job as app developers is then simply to assist the VoiceOver with its job.

VoiceOver basics

For every UI element, VoiceOver needs assistance in the following:

Tell about the UI element: Name, trait, and hint if it makes sense. Support accessibility gestures: What is the next element, next page, and many more.

For every UI element, you should test whether the current accessibility elements are correct. One good test is to enable the screen curtain, and see whether you can still use the app. The first time you do this, you’ll be probably surprized to learn how awful your app works without any visual interface.

Assigning names, hints and traits should be straightforward in most cases. For example, the accessibility data for a basket button could be as follows:

view.isAccessibilityElement = true

view.accessibilityLabel = "Cart"

view.accessibilityValue = "€ 2.49"

view.accessibilityHint = "Double tap to checkout"

view.accessibilityTraits |= UIAccessibilityTraitButton

UITableViewCell and UICollectionViewCell are a bit different, in the sense that they could be both a button-like element and a container view. To elaborate, one can tap on a cell and expect an action. On the other hand, a cell can simply serve as a container view that has several inner UI elements, which then can be accessed independently.

In this example, you would expect the top two cells to act as buttons, while the third acts as a container view. When you’ve decided on the role of the cell, you can set the accessibility data accordingly.

With VoiceOver, a user can use swipe left and right to go from one UI element to another. Which could be incorrect in some cases. Consider for example the totals view in the Picnic app

We would prefer some other, more sensible order.

To achieve this, we use the UIAccessibilityContainer protocol’s accessibilityElements property, which is an array of elements ordered according to the desired VoiceOver access sequence.

self.accessibilityElements = accessibilityElements

What’s next

The changes described here basically cover 95% of all VoiceOver and accessibility. If your app has this covered, it is already a lot better with Accessibility than most apps out there. In some future article, we’ll discuss some of the more specific challenges. And believe us, there have been many.

These are some of the resources that helped us a lot when we started out with Accessibility: