EXPEDIA GROUP TECHNOLOGY — SOFTWARE
How Expedia.com Uses Accessibility Automation
Patterns for using open-source automation tools to scale accessibility efforts
As projects continue to accelerate, so does the frequency at which developers publish code to their repositories. With every code submission that affects the client experience, teams should be careful to test for any potential accessibility issues. However, without any accessibility automation process in place, heavy reliance is placed on those who are reviewing or developing code to call out any accessibility issues during the pull/merge request process, leading to inaccessible user experience and placing companies at legal risk. This is where accessibility automation starts to become useful.
Accessibility automation leverages technology to audit user interfaces against a rule set such as WCAG and other accessibility interface guidelines. With the data regarding violations, the automation engine can either generate a report or break a build process to prevent the publication of in-accessible code.
In web-based technologies, the automation engine usually works by sniffing HTML markup in the document object model and also by leveraging CSS properties to provide several styling-based tests. In native apps, the automation engine often looks for issues such as defined accessibility properties that must exist on different object types, touch size, and labeling.
Automation can help developers catch 20–30% of accessibility-related issues in their code, maximizing the output of each developer’s time.
This means that a portion of accessibility testing will be machine detectable and will still provide some level of accessibility feedback even in a worst-case scenario when the code reviewer or developer forgoes manually testing the code for accessibility issues. This puts up guard rails around projects and is incredibly useful, especially for those onboarding large waves of developers or those who have an open contribution model within their project.
Who should use accessibility automation?
Any project that works on the client-facing web or native app code can benefit from accessibility automation. A team having any level of testing maturity can benefit from accessibility automation within its projects. As a project evolves and develops more sophisticated testing, contributors will be able to continue to use accessibility automation as needed.
How do I get started with accessibility automation?
Thanks to the large open-source community around accessibility automation, getting started with accessibility automation is straightforward. You can start the process by asking yourself a few questions:
1. What does our technology stack look like? Are we using a modern web-based technology stack or older web-based technologies? Are we implementing accessibility automation for a native application?
2. What does our team know about accessibility? This is an important question. If you were to roll out accessibility automation before developers are familiar with fundamental accessibility concepts, it could harm project velocity and could also lead to improper remediation practices. Additionally, if developers are fixing issues reported by the accessibility automation engine, those developers must be able to verify the solution is acceptable in various assistive technologies.
3. What is the rollout plan for accessibility automation? Having a rollout plan for accessibility automation ensures that you’re able to introduce accessibility automation without crippling workstreams while still maintaining safeguards on your projects. For example, if a team were to implement accessibility automation within their project, there would be several initial issues that they would have to fix before that automation activity could be included in the project’s build. A phased rollout of accessibility automation could help.
Accessibility automation for web applications
Accessibility automation in web apps is multifaceted. The beauty of web-based technologies is the sheer abundance of open source technology for developers to utilize. Individual contributors and numerous companies have contributed to the open-source accessibility community to provide automation tools for accessibility static analysis, in-browser testing, linting, unit testing, and even end-to-end testing.
Exploring accessibility automation for web applications
With the number of open-source tools that exist for accessibility automation on the web, it may be tricky to figure out how to create a comprehensive automation package. Our contemporary web application builds have a linting stage, unit test stage, end-to-end stage, and potentially a performance testing stage. Looking at the different stages, we can start to break down where accessibility automation could be plugged into existing build processes. This can help us establish patterns for accessibility automation that we could potentially scale across teams.
Minimum: You want to at least have an accessibility linting plugin in your project’s configuration. Since linting is often one of the first processes in a build, it will report early in the build process, which will make it easier for developers to spot and correct problems. Additionally, adding a linting plugin is low effort and high reward in terms of the feedback that it gives. For web-based applications, you could use accessibility linting plugins such as
or similar accessibility linting plugins made for your technology stack.
Recommended: Extend the minimum pattern with accessibility automation within a live server/browser and end-to-end or client-based experience. In this pattern, the automation plugin for your linting config would help spot issues early in the development process so you can fix them before they’re compiled into your client experience. Browser-based feedback during development with a live server gives developers constant feedback as they’re working on a new feature or enhancement. Lastly, with accessibility automation integrated into an existing end to end testing framework, it is possible to run accessibility automation against your suite of tests aimed at simulating the client experience.
Tools that could be used to implement this recommended accessibility automation pattern include:
- Live-Server: React-Axe or Storybook-addon-a11y
- Linting: Eslint-jsx-a11y or Tslint-microsoft-contrib
- End to End: Cypress-Axe
Note that tools can be changed based on your technology stack whether you’re on Vue.js, Backbone.js, or any other frontend framework. The most important concept is ensuring that multiple stages of accessibility automation can be incorporated within the build. Even if the tools listed above don’t work for your given application, be sure to check for any alternatives. To look at available web accessibility tools and implementation strategies in greater detail, be sure to visit Expedia’s patterns for automation in a web context documentation.
Accessibility automation for native applications
When thinking about accessibility automation for native applications, the process can be different from that of a web application and varies depending on the platform.
Automation patterns for Android
Accessibility automation in Android is a streamlined experience. Google exposes many accessibility automation tools, like lint-checks and accessibility-checks, that developers have access to out of the box within the Android development ecosystem.
Minimum: As with the web, a minimum pattern includes an accessibility linting plugin. With Android, we’re provided with Android’s Lint-checks out of the box. To learn more about Android Lint-checks:
Recommended: In addition to linting, utilize accessibility checks within either your Espresso UI tests or Robolectric unit tests. This gives you a second layer of automation protection. Android implementation of recommended accessibility automation could include the following tools:
- Linting: Lint-checks
- UI/Unit testing: AccessibilityChecks
To learn more about Android accessibility automation patterns, be sure to visit our content on automation patterns for Android.
Automation patterns for iOS
One of the great parts of developing iOS applications is the built-in accessibility support that you get when you utilize native iOS components. However, using native iOS components does not guarantee that your application will be accessible. This is where automation is useful, as it will help you find issues that may have been missed. Accessibility automation can mean employing the Xcode accessibility inspector, test library extensions, and others via scripting.
Minimum: Defining automation patterns in iOS is trickier than in Android. Accessibility automation tools cannot explicitly interface with the project’s build, so the developer may need to use audit functionality or storyboard linting to verify that a pull/merge request will not introduce accessibility issues. Helpful tools for this are:
Recommended: Extend the minimum requirements to include unit test automation by way of A11yUiTests. Since A11yUiTests can interface with your iOS application’s build, you can break a build based on any detected violations from the plugin. This is especially useful since the minimum pattern relies on the developer proactively using Xcode Accessibility Inspector or Xiblint. A recommended automation pattern could include:
Putting it all together
You should use accessibility automation in ways that work for your unique development workflows and technology stacks. The open-source community continues to create incredible tools that we as developers should use to further help drive the inclusivity of our applications. Accessibility automation, however, is not perfect and will not be able to replace the need for manual testing. Manual testing ensures that your applications not only work for assistive technologies but also ensures that the experiences work for humans. Accessibility automation is a tool and when coupled appropriately with a robust manual testing strategy will improve code quality and enable us to create a rich application for all users. To learn more about accessibility automation in greater detail, be sure to visit our full accessibility automation blog in Expedia Accessibility Resources.
