Skip to main content

Accessibility at CRUK – Why It Matters

At Cancer Research UK (CRUK), accessibility is fundamental to our mission. We are committed to making our digital services inclusive for everyone, ensuring that people of all abilities can:

  • Access vital information
  • Receive support
  • Engage with our work and initiatives

Our commitment also aligns with:

  • Legal requirements under the Equality Act 2010
  • Web Content Accessibility Guidelines (WCAG) 2.2 AA standards

For more details, visit CRUK Accessibility

Overview​

Accessibility testing ensures our applications are usable by people of all abilities, including those relying on assistive technologies such as:

  • Screen readers
  • Keyboard navigation
  • Voice control

At CRUK, we use AXE and Lighthouse as our primary accessibility testing tools to:

  • Identify accessibility issues early
  • Remediate problems before release
  • Support both automated and manual testing practices

Coverage​

Our accessibility testing coverage is guided by:

  • WCAG 2.2 AA standards – the benchmark for accessibility compliance
  • Critical user journeys – ensuring accessibility for key flows such as:
    • Registrations
    • Supporter sign-ups
    • Donations

To achieve this, we employ a combination of manual and automated testing methods, utilizing tools such as AXE and Lighthouse. This approach allows us to ensure accessibility in the areas that have the most significant impact for our supporters.

Dev/QA Role in Accessibility​

At CRUK, accessibility is a shared responsibility across developers and QA engineers. While automated tools like AXE and Lighthouse help identify some issues early, compliance is always validated against WCAG 2.2 AA standards through manual checks and testing.

Developers​

Developers ensure accessibility from the start (“shift-left testing”) by:

  • Writing accessible code using semantic HTML, ARIA best practices, and CRUK design guidelines.
  • Using ESLint in the IDE to catch accessibility issues early during development.
  • Running quick manual checks for headings, form labels, alt text, and focus states.
  • Conducting keyboard-first testing to confirm all functionality works without a mouse.

QA Engineers​

QA engineers ensure accessibility before release by:

  • Reviewing automated reports from AXE/Lighthouse and validating findings manually for WCAG 2.2 AA compliance.
  • Manually testing critical user journeys for keyboard navigation, colour contrast, and error states.
  • Confirming accessibility acceptance criteria to ensure features meet WCAG 2.2 AA standards before sign-off.

Tools & Platforms​

To support accessibility testing, we utilise AXE and Lighthouse across multiple environments and workflows, enabling scalable, repeatable, and reliable accessibility checks.

AXE (by Deque)​

What is AXE?

  • Industry-standard accessibility testing engine by Deque Systems.
  • Provides automated accessibility testing within browsers and CI/CD pipelines.
  • Integrates with developer tools (Chrome, Firefox, Playwright, etc.).
  • Aligns with WCAG 2.2 AA standards and ARIA best practices.

For more information, see Deque AXE Documentation.

AXE Tooling Options:

  • AXE DevTools Browser Extension – Run quick accessibility scans in Chrome or Firefox.
  • AXE-core Library – Integrates with frameworks like Playwright for regression testing.
  • AXE Linter – Highlights accessibility issues as code is written (“shift-left testing”).

Lighthouse​

What is Lighthouse?

  • Open-source tool by Google for auditing web applications.
  • Provides accessibility scores (0–100) with actionable recommendations.
  • Runs in Chrome DevTools, the command line, or CI/CD pipelines.
  • Complements AXE by offering audits for performance, SEO, and best practices.

For more information, see Google Lighthouse Documentation.

At CRUK, Lighthouse is used to:

  • Run quick accessibility audits on key pages.
  • Generate high-level accessibility scores to monitor improvements over time.
  • Support release readiness checks by validating accessibility alongside performance and SEO.

Automated Accessibility Testing​

Playwright + AXE-core​

  • Simulates user journeys across browsers while AXE-core scans for accessibility violations.
  • Enables accessibility checks in regression suites and CI/CD pipelines.
  • Ensures new code does not introduce accessibility regressions.

Manual Accessibility Testing​

While AXE and Lighthouse are powerful, automated testing cannot catch every accessibility issue. At CRUK, we combine automated checks with targeted manual testing, including:

  • Keyboard-only navigation – Verifying users can navigate all interactive elements without a mouse.
  • Browser Extensions (Chrome/Firefox) – Ideal for quick manual checks during development. Recommended for developers and QA engineers during active feature development.

Lighthouse in Chrome DevTools:

  • Provides quick accessibility scoring during development.
  • Useful for identifying areas of improvement at a higher level.
  • Can be run locally or automated in CI/CD pipelines.

Frontend Accessibility Release Checklist​

Before a feature is marked as release-ready, the following accessibility checks should be completed:

  • Lighthouse audit – Run Lighthouse plugin and confirm no critical accessibility issues are flagged.
  • Keyboard navigation – Verify all functionality (forms, buttons, menus) can be used with a keyboard only (no mouse).
  • Automated tests – Ensure AXE-core automated checks (via Playwright or CI pipeline) pass without accessibility violations.

Support & Queries​

For questions about accessibility testing with AXE or Lighthouse, please contact Raj or a lead QA.