Accessibility at 3 Sided Cube

Accessibility is ensuring that as many people as possible are able to use your software. It’s so important to consider accessibility for your users because you want as many people to access and enjoy your app as possible. This requires making sure it is easy to use for people with different abilities.

​​Making your app accessible means you need to consider the range of challenges a user may face, so that as many people as possible can use it. This includes those with impaired vision, motor difficulties, cognitive or learning difficulties, as well as deafness or impaired hearing. It also requires the consideration of those with poor internet connectivity.

Designing an accessible app means much more than simply making the design clearer. It is so incredibly important that you design an app that is adaptable to those throughout the spectrum and support those who need the app’s extra, accessible functions. 

Considerations needed to make an app accessible

1. Create a simple, clear layout. The initial step is to ensure you have a simple layout
2. Design a consistent navigation
3. Consider your text formatting
4. Make audio and video accessible
5. Give careful consideration to colour
6. Don’t forget to test!

As a tech for good agency, we want to ensure that we’re able to help as many people as possible with our apps – ensuring our apps are accessible helps us do that!

Part of Cube’s mission is to change millions of lives for the better – we can’t guarantee we’re doing that if we’re potentially excluding part of a user base through not considering something as widely used as accessibility features.

To ensure that all of our apps are as accessible as possible is going to potentially be a long process. For newer apps that the client has requested meet a certain accessibility standard (typically AA), we are introducing accessibility acceptance criteria to ensure that this is included and tested within each implemented feature

We’re also including separate accessibility regressions alongside the typical regression to ensure that any potential issues and changes are caught should a general change be made within the application.

One thing that we found when researching was that although there were tons of guidelines for web accessibility, there were hardly any for mobile – the ones that did exist weren’t very easy to find. Which is so surprising when you think about it, apps have been mainstream for well over a decade, yet there are no black and white guidelines which people implemented years ago to ensure accessibility!

This led us to draft our own internal accessibility testing standard, including detail on regression testing for accessibility, the level at which we’ll test using screen readers and scaling, as well as known limitations of accessibility across iOS and Android 

The following contains the standard for testers at Cube to adhere to when testing accessibility. As there are very few set guidelines for mobile development in terms of accessibility testing, to prevent discrepancy across projects we have defined an in-house standard. This has been compared to existing web standards, as well as the accessibility functionality of leading apps across both iOS and Android.

 Accessibility Regression Testing

Testers to compile a standardised accessibility test script that can be applied to all 3SC projects. This will contain runs that meet AA and AAA standard, as well as meeting the standard defined within this document that has been agreed as 3SC’s internal accessibility development and testing standard.

 Screen Reader 

When testing a screen reader, we would need to define priority of content to be read out – screen reader to then follow this priority. Default would be reading content from top to bottom of screen.

Images that provide no extra value/information to user to be hidden from screen reader, e.g. a decorative image would not be announced by a screen reader, but an image containing information such as COVID-19 regulations would need to be announced, therefore content would need to be added to the alt text

 Scaling

To be tested on font size up to 200% – this is the standard largest size recommended for web testing so remains consistent with existing accessibility standards. If no percentage visible on device, tester should use largest available font size. 

Colour Contrast 

To be tested primarily by creative team within the creative review of each ticket – this means that any necessary changes can be actioned before the app reaches UAT, meaning that the product handed over meets the required standard

Testers to complete a spot check of colour contrast as part of the accessibility regression. iOS to be tested using TPGI Colour Contrast Checker. Android Colour Contrast can be tested using Android Accessibility Scanner

Gesture Dictionaries

Testers to compile dictionaries of common device gestures that can be used when testing accessibility

Going forward, we are committed to ensuring that accessibility is a consideration for every single digital product we build. And should be a prominent feature from designs all the way through development and to testing, and integrated as almost second nature in a project

My hope is that the new guidelines that the testing team have carved out, help to collaborate across the production team to create a centralized way of working with accessibility!