Adopting accessibility in a product can be quite an overwhelming task. There are a lot of different sources out there on the topic. We did some internal research to come up with action points we could put on roadmap, and now we want to share it publicly. This might be useful in case you have an existing product and want to adopt accessibility too.
What is accessibility and why should we care?
The meaning of the term “accessibility” can be summarized by this quote:
Accessibility is the practice of making your websites usable by as many people as possible. (source)
We usually think about accessibility as usage by people with disabilities and we usually only think about the most obvious ones, like blindness, for example. However, accessibility is a much broader term. There is a wide range of different disabilities that can affect how people use our websites and, yes, some of them can be quite limiting. Other limitations could include the inability to control a mouse, cognitive limitation because of age, etc. But accessibility is not only about the physical abilities of people, it is also about their circumstances. It includes more technical issues like mobile access, slow internet connections, or under-performing, old hardware (imagine people in poor areas of Africa or Asia).
We might also think of accessibility as giving everybody equal opportunities, no matter what their ability or circumstances are. Committing to support accessibility is not just a technical issue, but also cultural and social. This is aligned with our company values and we want to address accessibility because it’s the right thing to do.
As a last, but nonetheless important point, providing accessible sites is already part of the law in some countries/regions (California, for example), and we can expect more and more countries following this trend in the future. Thus, having accessible products could bring in customers or sales deals that could otherwise be lost.
Who sets the rules?
There is a tremendous effort to standardize accessibility. The number one source for accessibility is the Web Accessibility Initiative site run by W3C. It hosts an extensive amount of information on the topic. They also develop guidelines and standards that are cornerstones in the evaluation of accessibility adoption:
WCAG (Web Content Accessibility Guidelines) are documents that explain how to make web content more accessible to people with disabilities. They are authored by W3C. The current 2.1 version was published in June, 2018. These documents represent stable, referenceable technical standards. They consist of guidelines organized under four principles: perceivable, operable, understandable, and robust (a.k.a. POUR). For each guideline there are testable success criteria, which are at three levels: A, AA and AAA. See this overview for more details.
POUR is an acronym used for the four principles of WCAG:
- Perceivable – Information must be presented to users in a way they can perceive.
- Operable – User interfaces and navigation must be operable.
- Understandable – Information and operation of user interfaces must be understandable.
- Robust – Content must be robust enough that it can be interpreted by a variety of devices, including assistive technologies.
The success criteria of WCAG are written, testable criteria that objectively determine whether content satisfies them. Each criterion has three levels of conformity: A, AA, and AAA. Higher levels include conformity with lower levels. The A level is the minimum level. Usually, AA level conformity is what’s targeted, as some of the AAA criteria might be impossible to achieve for certain content.
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is an acronym used for the ARIA specification to distinguish it from other usages of the ARIA acronym itself. The current 1.1 version was released in December, 2017. It’s a technical specification focused on making the web more accessible for people with disabilities and it focuses on dynamic content and advanced user interfaces developed with JavaScript and related technologies. It provides a framework for adding attributes to identify features of user interactions (menus, overlays, etc.). See this overview for more details.
Why haven’t we adopted it yet?
Since we’ve established that adopting accessibility into our products is such a positive thing to do, why haven’t we done it yet? For us, the problem is that we haven’t followed any rigid accessibility standard or guideline during development in the past, thus our accessibility compliance throughout our products is not very systematic. Some parts work, but others might be completely broken. We need to change this and incorporate accessibility into our products and development process. The adoption can be broken down into a few subproblems:
- We need to select tools that will allow us to easily discover accessibility issues and evaluate our level of accessibility, ideally categorized per the success criteria and principles. We could also consider using specialized tools like screen readers, etc. for more specific evaluations.
- Then, we need to go over all our products manually, using the selected tools, to check for accessibility issues, then fix them.
- We need to put in place a process that will ensure accessibility is not broken by future development.
Let’s go over each step in detail.
1. Evaluation tools selection
There is huge ecosystem of different tools related to evaluating accessibility. One quite extensive list is maintained by the WAI itself here: https://www.w3.org/WAI/ER/tools/.
It is important to understand that there is currently no tool that can evaluate accessibility in a fully-automated way. The evaluation can be simplified, partially, through automated checks, however it still requires manual checks too. Fortunately, there are some tools to help navigate this manual process. The evaluation is also not limited to a single tool, but rather a composition of different tools and checks.
What follows is a list of what we think are the most interesting tools and the ones we’ve decided to use.
ESLint React accessibility plugin
There is a plugin for ESLint named eslint-plugin-jsx-a11y that does check some basic accessibility rules in a static manner in React components. Since we rely heavily on React and ESLint anyway, this plugin is a no-brainer for us.
Axe-core
Axe-core is an open-source accessibility testing engine, used and integrated by many other tools and libraries. There are other similar libraries available, however this one seems to be the most used based on its GitHub stars and the ecosystem built around it. We’ll rely on this library heavily, however not directly, but rather through other tools leveraging it:
Storybook addon
There is an addon to storybook named addon-a11y that is based on axe-core. It lists any accessibility issues in a story, thus helping evaluate each component in our design system.
E2E tests
Accessibility can also be tested as part of E2E tests. For example, every screen visited by a regular test can be evaluated, or there could even be dedicated accessibility tests going through and testing major screens. This will not serve as complete prevention of accessibility issues, but rather as an indicator of potentially deeper issues. A failed accessibility tests will be followed with deeper, manual checks for any potential accessibility issues.
The integration of axe-core into E2E test frameworks seems to be simple and straightforward. We rely on Robot Framework for E2E tests and the integration with axe-core is quite simple as for example this guide shows.
Microsoft Accessibility Insights
Microsoft Accessibility Insights is an amazing browser extension built on top of the axe-core library. This extension will be used for manual and semi-automated checks of runtime applications. It provides two different modes:
- FastPass is an automated check for around 50 a11y requirements. It displays the nicely visualized results on the website itself and suggests ways to fix them.
- Assessment helps with the execution of manual checks. It follows WCAG 2.1 Level AA.
This extension will be our main tool to help us evaluate accessibility in our applications and, thus, should become a standard part of our developer and QA toolchains.
Tab key
The “Tab key” is not a tool on its own, it’s more a method of evaluating that our applications are properly navigable, that all control elements are focusable, etc. This simulates use of our applications without a mouse. Properly working focuses, tab orders, etc., are also a base for proper navigation by assistive technologies like screen readers.
When testing “Tab key” in an application, the following criteria should be met:
- All interactive elements are focusable and have a visible focus state.
- The tab order should make sense, it should follow the visual order of elements.
- The focus should be trapped in modals, meaning we shouldn’t be able to tab to other elements outside of it while it’s open.
Together with “Tab key” check, other keys should be tested to work as expected in advanced user interfaces (arrow keys in Menu, etc.). A detailed list of which keys should work and how in each component can be found in examples provided by WAI-ARIA.
Assistive technology
For even better evaluation of accessibility, we can leverage other technologies that simulate how people with different disabilities experience our applications (or websites in general), like screen readers, for example. However, since we don’t have any evaluation basics implemented yet, this should be left as an opportunity for future improvements.
2. Fixing current accessibility issues in products
This is the main part of the implementation. With help from the tools selected, we will evaluate every product and fix any potential issues we have. We will aim to achieve WCAG 2.1 Level AA in all our products.
Applications
To fix our applications, we will rely mainly on the Microsoft Accessibility Insights browser extension. Follow this process to evaluate each application:
- Start with the FastPass check and turn any found problems into issues (tickets in the developer ticketing system). Run the FastPass on every screen of the application (or on every type of screen if they’re generated), or at least on every major screen if not possible otherwise.
- Use the Assessment to manually evaluate the application. Potentially involve multiple people to verify and/or cross-reference the results.
- Export the result of the checks and turn any failed checks into actionable issues.
- Once everything is fixed, repeat the evaluation again to verify it.
Design system
We develop our own design system that is used by all our applications. Put simply, the design system is a library of components of different complexity, and to implement accessibility for it, each of the components have to follow specific accessibility rules. For basic ones (like buttons and images, for example) accessibility is usually straightforward and should be covered by both the ESLint plugin and the Storybook addon. For more advanced components (like selects and menus, for example) we need to try harder to make them accessible and usable for different use cases, especially for assistive technologies.
The accessibility of these components is covered by WAI-ARIA. There is a document called WAI-ARIA Authoring Practices that lists design patterns for each different type of component. Each listed component in the document will be mapped to appropriate design system component, and the design pattern will be implemented properly for it.
The correct implementation can’t be confirmed by automatic checks alone and will require manual verification.
3. Incorporate accessibility evaluation into the development process
A one-time only evaluation of accessibility and fixing any found issues is not enough on its own. We need to ensure that there are no regressions in the future, the same as we need to ensure that newly developed products adhere to accessibility criteria too. We have already mentioned automated E2E tests to be used as an indicator of potential issues and notify us when some regression appears. However, developers, QAs, designers, and other members of R&D should have a good understanding of how accessibility “works” and apply this knowledge during design, development, and the testing of their changes, to create products where accessibility is supported from the beginning.
Such understanding can take some time to develop. For those reasons, the WAI website provides a rich source of information on how to teach and advocate about accessibility. It includes curricula for presentation and trainings, so we could leverage this source to build our own presentation, then host an internal workshop about accessibility and discuss how it will affect the development and testing process.
After that, assessing effects on accessibility for any changes should become a standard part of our code review process. We already do pay a lot of attention to code quality, to UI quality, and to user testing during the review, and we can add specific guidelines for accessibility on our checklists too.
On top of that, to ensure that nothing slips through our “daily” checks, a similar process that was used to fix our current issues should be repeated at least once per year to re-verify that everything is working properly and no criteria were broken undetected.
Conclusion
As you can see, adopting accessibility properly can be a long and tedious process. However, we’re lucky that there is so much effort put into the standardization and documentation of accessibility by WAI that makes it so much easier. There is also wide range of tools and libraries that can help with the adoption and make the inevitably manual process more manageable. I’ve listed our selection, but there are many other available that you can choose from to tailor to your needs. I hope this write up can help you in tackling the adoption of accessibility in your products too!
