Skip to content

Accessibility

Imogen Hardy edited this page Dec 15, 2023 · 4 revisions

Ensuring that the support site is as accessible as possible to as many users as possible is a critically important part of client-side work. Not only is it a core part of our principles as an organisation to make sure our products are accessible to all, an inaccessible checkout causes the Guardian to lose money- the spending power of disabled people in the UK alone is estimated in the billions.

All UI changes should be subject to both automated and manual accessibility testing.

Automated testing

We use the React-axe tool to automate accessibility checking on our pages. It tests pages running in dev with the axe-core accessibility testing library and shows results in the Chrome DevTools console.

React-axe output for the Digital Pack product page Screenshot 2019-09-11 at 17 11 11

Each item identified has a link to a page with an in-depth description of the problem and remediation suggestion. A full list of the accessibility rules checked is here

Axe is also incorporated into the accessibility add-on in Storybook, which runs the same checks against individual components. For a more detailed way to explore issues flagged by Axe, the Axe Devtools extension enables you to step through issues on a page.

Manual testing

In addition to automated testing we also need to make sure any non-trivial UI changes are tested manually, using keyboard navigation and a screen reader- many things that won't be picked up by automated tools will be surfaced by manual testing, such as a more confusing user experience with a screen reader.

The Guardian's accessibility repo has specific resources and recommendations for how to test using these tools.

πŸ™‹β€β™€οΈ General Information

🎨 Client-side 101

βš›οΈ React+Redux

πŸ’° Payment methods

πŸŽ› Deployment & Testing

πŸ“Š AB Testing

🚧 Helper Components

πŸ“š Other Reference

1️⃣ Quickstarts

πŸ›€οΈ Tracking

Clone this wiki locally