Automated web testing, especially at an integration level, saves time, money and effort. It ensures UI structure and basic web functionality work properly for every release of new content. Over the last 5 years, there has been a massive upswing in teams requiring these UI tests, and in that upswing there has been a push to automate as much as possible, including accessibility.

Now that teams have begun to have a well oiled machine of UI regression tests, there is a natural need to expand that testing. Currently testing teams are looking to add mobile UI automated test cases to their suite. This would allow for specific test cases to be run just for mobile web content.

How can your automated accessibility tests become a part of your mobile UI tests? Lets find out!

A11y Automation for Web Content

Automated accessibility testing for web content has started to gain a lot of traction over the last few years. The biggest reason is the ease of use in the development testing lifecycle and the multiple different open source integrations that are available. Using automation libraries such as axe-core or pa11y catches around 40% of accessibility issues and 57.6% of them by volume.

These integrations work with either the component level UI tests (Jest, Karma) or integration level testing libraries (Puppeteer, Cypress). It creates a seamless process for accessibility tests to become a part of what you are already using to test for content!

Emulating Mobile Browser

When a team decides they want to add mobile UI test cases to their integration level testing suite, they have to make a choice if they are going to use the testing library to emulate the browser or use Appium to emulate a real device with native browser.

Using Test Library

Almost all testing libraries have a configuration in which you can emulate a specific browser type or size (viewport). This allows for the dynamic sites created to render in their mobile state for testing. Here are just a few of the top testing libraries and how to emulate a mobile browser:

• Cypress
• WebdriverIO
• Puppeteer
• PlayWright

Using Appium

Appium allows you to test with a device emulator and through that device test in the browser of your choice. Development teams who have mobile first websites love to use it for it's ease of use and the ability to test device specific actions.

To see more on how you can run accessibility automation with Appium check out a previous article on it here

Putting the Pieces Together

So where do the automated accessibility libraries fit in? Well the truth is, right where they were before! The greatest benefit of accessibility testing at an integration level is the same implementation you had been using with your testing library of choice, will work again with the mobile UI configuration. For a bit more clarity, let's do an example with cypress!

Let's say our development team is doing both integration level testing for web content on desktop AND mobile browsers, and they are using the cypress-axe integration.

In the setup function, where all the configuration is done, I can configure that I want a specific browser width or device size to be emulated like so:

 js
describe('Space Jam', () => {
  context('Mobile UI Suite', () => {
    beforeEach(() => {
      cy.viewport('iphone-x');
      cy.visit('https://www.spacejam.com/1996/');
    })
  })
})

Now that I know it will render in the proper size, I can simply do what I have done for the other web test cases and add an accessibility check for said mobile web page like so:

 js
describe('Space Jam', () => {
   context('Mobile UI Suite', () => {
    beforeEach(() => {
      cy.viewport('iphone-x');
      cy.visit('https://www.spacejam.com/1996/');
      cy.injectAxe();
    })

    it('is an accessible mobile Space Jam page', () => {
     cy.checkA11y()
    })
  })
})

Just like that! Same setup we would have for desktop browser testing, but now we are checking for mobile web accessibility issues in our UI tests!

Benefits of A11y Mobile Automation

There are many benefits to doing mobile accessibility testing including:

• Catching critical accessibility issues with content that doesn't get tested all that often
• Can help build more robust UI testing for mobile web
• Cuts down on manual testing for mobile web
• Add accessibility into your CI/CD metrics

In Summary

With how simple it is to include automated accessibility testing within your mobile UI tests, there is no excuse not to do it. Leveraging the libraries you are already using, and maximizing the scope of content you are testing will help ensure both in desktop and mobile browser your content is accessible for all to use!