)
)
I cannot believe it has been nearly a year since becoming a Cube Academy graduate and starting full time on the testing team! In that time I have learned so much and worked on some amazing tech for good projects!
The testing team is the barrier of quality here at Cube – we’re responsible for ensuring that all the code the devs produce is up to as high a standard as possible, and that all our apps and sites are working as expected before being shipped into the big wide world. We work across all of the amazing tech for good projects that Cube produces, accepting (or re-opening) tickets and catching (most) bugs on the daily to ensure that users have the best experience!
Something my team, and the wider team has come up against more and more frequently is accessibility within our apps. Though this isn’t a new concept by any means, it has gained traction in the last 5 years and more people are becoming aware of how vital it is that we build technology that is able to be enjoyed by everyone!
Being that accessibility is still in its infancy, and there were no hard and fast rules out there to follow to enable accessibility within every build, my team sat down and went about putting together “guidelines” we can hold ourselves accountable with for every project.
What is accessibility?
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
Create a simple, clear layout. The initial step is to ensure you have a simple layout
Design a consistent navigation
Consider your text formatting
Make audio and video accessible
Give careful consideration to colour
Don’t forget to test!
Why is it important to us?
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.
What we are doing to ensure accessibility in ALL our apps
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.
3 Sided Cube’s Accessibility Guidelines:
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
The future of accessibility at Cube
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 centralised way of working with accessibility!
It’s not tech for good if it isn’t accessible to every single person! null
Published on 31 March 2022, last updated on 31 March 2022