Assistive technologies on mobile devices like phones and tablets are much more limited or simpler compared to their older relatives on laptops and desktops. Therefore making user interfaces on mobile devices simpler and more focused need to be our priority. The scope of this post goes beyond Web Content Accessibility Guidelines (WCAG) and is more focused on the usability for users of assistive technologies.
In my native mobile application accessibility and usability audits, I often find multiple possibilities to simplify user interfaces, especially when some applications work against established (built-in) native mobile app patterns (native native ?) and try to copy or even mimic web interfaces (that will be a nice subject for a blog post in the future). On the top of the list to simplify things is accessibility group – that allows developers to group elements together, so that they are – you guessed correctly – grouped.
It’s of course a “it depends” situation that you will need to figure out for yourself and I can’t just say – always or never group this and this, but I think we can simplify the “rule” (rather guideline) and assume that items that visually belong together can often be grouped inside accessibility group. Especially if they are not interactive (for example different texts). But also if items include interactive elements we can decide what will be the main action and when it is appropriate to introduce accessibility actions or similar “enrichment”.
React native example
Let’s take an example from React Native and improve it. I choose React Native just because it’s more convenient, as it tries to support both iOS and Android platforms and can be translated to both iOS and Android native functionality. Please note that React Native has some accessibility issues that may be a show stopper for your project if you require specific accessibility features at the time of writing). But it works well to illustrate functionalities with a single code for both platforms.
We start with an un-grouped situation where we have an element that represents a single email (could be many other things where we need to represent information in a list);
<View>{/* Start list item */}
<View>
<Text>CEO</Text>
<Text>Important email subject</Text>
<Text>Short text that serves as preview</Text>
</View>
<View>
<Text>10. Nov.</Text>
<Text>!</Text>
<View>
<View>
<Button accessibilityLabel="Open" />
<Button accessibilityLabel="Mark as read" />
<Button accessibilityLabel="Delete" />
</View>
</View>{/* Stop list item */}Now this code works just great, but as it is not grouped, a screen reader user that swipes left to right or right to left needs to go through all 7 elements independently. Which takes quite some time. Keyboard users (and users of other assistive technologies based on keyboard, like switch control) get to at least three interactive elements per item.
This is what I meant when I wrote that I see a lot of opportunities to simplify the usability for users of assistive technologies.
Now, again, I am not saying that we must always group all these elements into a single one, but if we at least group the texts to a single one we help screen readers a bit – they can then swipe once instead of 4 times in our scenario. But if it makes sense, we can even go further and add all the elements that belong together into a same group and then decide what is the main action (in our example it could be to open the email) and add additional actions to a secondary interaction (for example “long press” and/or accessibility actions (opens in new window)).
Using accessibility group and accessibility actions to simplify the interface
Again – please treat this as pseudo code (code that is not ready for production) – I use it just to make a simple point and we all need to test it before we use it in the real world. But grouping items like this, where both textual context and interactions are grouped together per a single email (that would normally come in a list) could greatly simplify the non-visual interface of your app and improve usability for people with disabilities.
This kind of grouping may not work everywhere, but relying on accessibility actions (that are supported natively) could join the three buttons as well. It’s not a general answer for all kinds of scenarios out there, but it could be appropriate for your app if you show messages that allow actions on them.
<View
accessible
accessibilityLabel="10. Nov., Important, From: CEO, Important email subject, Short text that serves as preview"
accessibilityActions={[
{name: 'open', label: 'Open'},
{name: 'mark', label: 'Mark as read'},
{name: 'delete', label: 'Delete'},
]}
onAccessibilityAction={event => {
switch (event.nativeEvent.actionName) {
case 'open':
Alert.alert('Alert', 'Placeholder for open action');
break;
case 'mark':
Alert.alert('Alert', 'Placeholder for mark read action');
break;
case 'delete':
Alert.alert('Alert', 'Placeholder for delete action');
break;
}
}}
>{/* Start grouped list item */}
<View>
<Text>CEO</Text>
<Text>Important email subject</Text>
<Text>Short text that serves as preview</Text>
</View>
<View>
<Text>10. Nov.</Text>
<Text>!</Text>
<View>
<View>
<Button accessibilityLabel="Open" />
<Button accessibilityLabel="Mark as read" />
<Button accessibilityLabel="Delete" />
</View>
</View>{/* Stop grouped list item */}Please test soon and often and with all assistive tech provided by the platform as I’ve seen that sometimes there are bugs in abstractions (like for example React Native).
After you are confident (and you know that you have done everything in your power to make the app accessible – including naming all the interactive elements), please also involve people with disabilities in the user testing, but please do all you can to make things as accessible as possible. And please – offer fair compensation to the testers. This kind of testing is work, sometimes very advanced work, and they deserve compensation for their time as well.
