Accessibility
All Chroma components have been designed and built to meet WCAG 2.1 AA standard accessibility. In some cases it is the usage of the component rather than the component itself that ensures your application is compliant, please follow the advice and patterns that we have documented as well as general accessibility patterns such as associating labels and inputs or using alt tags on images etc.
What is WCAG
The World Wide Web Consortium (W3C) is an international community that develops the open standards for the Web. The W3C produces specifications on a wide range of web-related topics including HTML, CSS and Accessibility.
Within the W3C, there is a sub-group called the Web Accessibility Initiative (WAI) Working Group. This group has been responsible for developing the Web Content Accessibility Guidelines (WCAG).
The WCAG guidelines provide a standard for web content accessibility. WCAG 2.1 became a W3C Recommendation in June 2018. The next iteration, 2.2, is still in development with the latest release candidtate available to view on the w3.org website.
Types of disability
A disability is any continuing condition that restricts everyday activities such as using IAG's online services and content.
Disabilities are often broken down into the following four broad categories:
- Visual
- Auditory
- Motor skills
- Cognitive
Yale University have compiled a comprehensive list of the types of disabilities that affect our website and application users.
Accessibility isn’t something that you should be thinking about when a project is nearing completion or once in production, this is simply going to cause a lot of technical debt to accumulate and become more difficult to fix the underlying issues.
By continuously testing for accessibility issues during development the overall time spent addressing audit results will be greatly reduced.
Here are some of the ways that accessibility tools can help.
Development tools
Here are the tools that we recommend in order of ease of access:
Google Lighthouse
Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO, and more.
Because you can run Lighthouse in Chrome DevTools this becomes a very useful first port of call tool while developing an application.
Simply open Chrome DevTools for the page you would like to test, click on the Lighthouse tab and choose the Accessibility category before clicking the "Analyze page load" button.
The results will show any glaringly obvious accessibility issues with an informative description including screenshots and classes to affected elements in your page.
Deque Systems tools
axe Accessibility Linter
For those of you using VS Code for your IDE there is an excellent extension from Deque Systems called axe Accessibility Linter which will will aid in avoiding common issues as you code.
If you are using IntelliJ there is also a linter available based on axe-core by Fabian Bucher called Accessibility Linter.
axe devTools
While you are testing your code in a browser another useful tool is the free version of https://www.deque.com/axe/devtools/ which can run over a page and find any obvious mistakes.
jest-axe
Our Chroma components have a basic accessibility testing CLI tool integrated into our unit tests called jest-axe which, when run, will check for accessibility violations in the component DOM and report these violations in the terminal or cause your CI pipeline to fail and report the error:
import { axe, toHaveNoViolations } from 'jest-axe'
expect.extend(toHaveNoViolations)
it('should have no axe violations', async () => {
const { container } = render(<InformationAlert />)
const results = await axe(container)
expect(results).toHaveNoViolations()
})