Manual and automated accessibility testing at TELUS

Our approach to accessibility at TELUS is about much more than ticking boxes and meeting minimum standards. We want to give everyone equal access to the devices and services we need to work, play and stay connected. That’s one way we can help build a friendlier future.

At TELUS Digital we work on many internal and external digital products. Some of these products are done in house by the TELUS Digital teams and others are done by our trusted and valued partners. For internal products we apply the same criteria we do to all external customer facing products, this ensures we deliver to the highest standards. 

Senior Accessibility Strategy Manager at TELUS, Oskar Westin, summarises this best “One of the main goals we have here at TELUS is to ensure customers and team members can do what they want, easily. Making something accessible makes it easier to use and that's something that's really good for all of us. You can't make exceptions to that rule because we may all have disabilities in some way at some time, situational, permanent or otherwise. It is really important to remember that when you're building products for your teams.”

For partners who work with us, we expect our high standards to be adopted and championed by them. James Malone Design Director at NearForm says “Working with TELUS on internal and e-commerce products has been a great experience. We really value accessibility at NearForm and gaining access to the TELUS teams meant we didn’t need to convince anyone this was the right thing to do. From the initial designs all the way through to development we had support, practical advice and guidance from the accessibility team. This not only made the products we were working on accessible, it made them easier and better to use.” 

Making accessibility part of the design and development process

Accessibility often gets added at the end of a development process, this causes friction and development debt. Retrofitting is a painful process and can lead to issues in unexpected places. By putting accessibility on the table during any initial discussions, prioritises it and makes the delivery expectations clear for everyone. 

Senior business systems analyst at TELUS Mary Elizabeth J. Sullivan agrees saying “One of the things that we want partners to do is we want you to annotate accessibility from the beginning. If you design and develop accessibility upfront instead of at the end, when you have to go back and fix everything, it's consistent. Your developers know what they have to build and how to build it from the user experience side and your testers can test it and know what they're testing so they don't have to test absolutely everything.”

James Malone from NearForm worked on the TELUS e-commerce journey, he says “Annotating the designs forced me to rethink some design decisions as it became clear how certain navigation elements can be done better. These issues made me really look hard at optimising the journey for everyone which ultimately resulted in a much more streamlined experience. Changing designs takes a few minutes versus the challenges faced when development is underway. Annotating in this way also helped the development team who also fed back into the process with their own accessibility suggestions.”

Manual testing, a step by step guide 

To meet accessibility standards we expect our products (web, mobile web, mobile native, and electronic documents) to meet colour contrast requirements and make sense to screen readers.

Our desktop web applications also need to work with a keyboard alone; they need to look and work at 200% text resize, and pass Google Lighthouse or Deque’s accessibility engine axe with a score of 99%-100%.

Mobile web and mobile native need to work with Switch Control and Switch Access functions in the phones, should be reviewed in inverse and grayscale to review colour and geographic copy references, and either allow pinch zoom or respect Larger Text OS

level controls. Mobile web also need to pass Lighthouse or axe with a score of 99%-100%

Complete.

Jack Clark senior software engineer at NearForm has some tips to help you with manual and automated accessibility testing:

• Work with the accessibility team to complete the TELUS Accessibility Matrix, this helps you look at certain issues through a different lens. 

• Navigate to each page in the application and use the axe browser plugin.

• Go through all Storybook stories and check for a11y violations.

• Navigate to each page and validate the HTML. You can find more information here. 

• Use the application with a keyboard - perform all actions with the keyboard alone, this helps to make a list of any potential navigation issues. Ensure focus is visible at all times, all actionable elements such as links, buttons, inputs for example, are focusable. Ensure the tabbing order makes sense and focus is managed well e.g. focus must be trapped in a modal when open and return to original when closed.

• Use the application with a screen reader like VoiceOver on OSX. It's hard to use this as an experienced user would, but learning the basics so that all actions can be performed can help us empathise. 

• Run through a WCAG compliance checklist which goes through recommendations for implementing accessibility principles and techniques to ensure WCAG compliance.

Automated testing, CI and Storybook integration

There are many tools to help with automating accessibility testing, and choosing the right one can be challenging. One toolkit in particular that we recommend is axe, an accessibility testing API by Deque Systems, a market leader in digital accessibility. Axe analyses web pages and checks for compliance with a comprehensive ruleset that’s based on WCAG 2.0. It generates a report that shows passes, flags violations and highlights any inconclusive results that need to be manually checked. It can be integrated into your own development workflows via the browser extensions or the open-source axe-core API, which is actively maintained by Deque Systems themselves. 

At Telus we treat automated accessibility tests no differently to traditional automated tests, we run them with the same priority in our Continuous Integration (CI) pipeline. This way we prevent the application from being released if new features aren’t accessible or if any regressions have been introduced. Prioritising accessibility in the development workflow ensures that our products are accessible from the start and the team are constantly exposed to it, raising awareness and educating our team at the same time.

At a full-page, browser level, we run Google’s Lighthouse in CI against every page in the application. Lighthouse performs analysis on performance, accessibility, best practices, SEO and progressive web app categories and gives a score out of 100 for each. For the accessibility category, Lighthouse uses the  `axe-core` library and produces a report with any violations. When running Lighthouse in CI we maintain a threshold of 90 for accessibility and will fail the build if the score drops below this.

Testing full pages with Lighthouse is useful to get a high-level idea of how well we’re doing, but it’s not enough in a modern web application that can have many different states. On the front end, we use React to build reusable components with TDS, the design system at Telus. We already use Storybook to document the various states for each component and page in the application, so it makes sense to utilise these and do some automated accessibility testing here too. Storybook already has an officially supported accessibility add-on, which is great for live feedback in the browser as you’re building your components, but it doesn’t prevent us from shipping when there are violations. To achieve this we hook into Storybook’s addon-storyshots and provide a custom test. This test loads each component story in a headless browser with puppeteer and runs axe via axe-puppeteer, failing the tests if there are any violations.

Accessibility APIs like axe cover a lot of bases for us, but we still like to write custom integration or end-to-end tests to ensure good keyboard interactivity, focus management and live updates are supported.

Working together as one team

The benefits of integrating accessibility into a project early on and using automated and manual testing improves many aspects of your project. Mary Elizabeth J. Sullivan agrees  “...leverage the automated tools available, they're great. They get a lot of things done quickly which helps you complete the accessibility matrix. There are a few things that automation won't catch and the TELUS accessibility matrix also talks a bit more about the experience. If you've done everything with accessibility in mind up to this point filling out that accessibility matrix should be pretty straightforward.”

It’s important to know that TELUS is committed to accessibility and the team is there to support both partners and internal teams. As part of the accessibility team Oskar Westin emphasizes inclusivity “We’re working hard to make an inclusive customer experience and employee experience. And I really do want to re-emphasize employees are important. We all need accessibility and a lot of us have disabilities. Some of us identify as having them some people don't. That's okay. You still need to consider accessibility because you don't know who in the room has one or doesn't.”

And finally, we really want your feedback, customers, partners and internal teams. Obviously, we can't do this alone. If there's anything you have a question about, just talk to the accessibility team directly or contact somebody through TELUS’ DRB (Digital Review Board) and they'll be sure to help you work through it.

We're looking to work closer with everyone. So give us your feedback, any thoughts you have or improvements we could make, we want to hear from you.

Thank you James Malone and Jack Clark for taking the time to sit down with us!

Follow us on Instagram and Twitter @telusdigital for more events and updates. If you’re interested in joining our team, check out our careers page!