Accessibility Cannot Be an Afterthought

Web accessibility ensures that people with disabilities can use your application — screen reader users, keyboard-only users, users with low vision, color blindness, or motor impairments. Accessibility is both a moral obligation and, in many jurisdictions, a legal requirement. At Nexis Limited, accessibility testing is part of our development workflow, catching issues before they reach production.

What Automated Testing Catches

Automated tools can detect approximately 30-50% of accessibility issues, including:

  • Missing alt text on images.
  • Missing form labels and ARIA attributes.
  • Insufficient color contrast ratios.
  • Missing document language attribute.
  • Duplicate IDs.
  • Incorrect heading hierarchy (skipping levels).
  • Missing skip navigation links.
  • Focus management issues.

What automated testing cannot catch: whether alt text is meaningful, whether keyboard navigation order is logical, whether ARIA labels make sense in context, and whether the overall user experience works for assistive technology users. Manual testing with screen readers is essential for comprehensive coverage.

Testing Tools

axe-core

The leading open-source accessibility testing engine. Powers most other accessibility testing tools. Tests against WCAG 2.1 rules with zero false positives — every issue reported is a genuine accessibility violation. Integrations available for every major testing framework.

eslint-plugin-jsx-a11y

ESLint plugin that catches accessibility issues in JSX during development — missing alt attributes, invalid ARIA roles, missing form labels. Catches issues before code is even committed. Should be included in every React project's ESLint configuration.

Playwright / Cypress with axe

Integrate @axe-core/playwright or cypress-axe into your end-to-end tests. After navigating to each page, run an accessibility scan. The test fails if any violations are found. This provides automated accessibility regression testing for your entire application.

Lighthouse

Google's Lighthouse includes an accessibility audit based on axe-core. Run it in CI/CD or manually through Chrome DevTools. Provides a score and specific recommendations.

CI/CD Integration

  • Linting (pre-commit): eslint-plugin-jsx-a11y catches issues during development.
  • Unit/Component tests: Use jest-axe to test individual components for accessibility violations.
  • E2E tests: Run axe scans on rendered pages during Playwright or Cypress tests.
  • Lighthouse CI: Run Lighthouse audits on deployed preview URLs. Set minimum accessibility score thresholds.

Fail the CI pipeline on accessibility violations to prevent regressions from being merged.

WCAG Compliance Levels

  • Level A: Minimum accessibility. Must meet for basic usability.
  • Level AA: The standard target for most organizations. Required by most accessibility laws (ADA, EAA). Covers color contrast (4.5:1 for normal text), keyboard navigation, focus visibility, and text resizing.
  • Level AAA: Enhanced accessibility. Not typically required but recommended for public-sector applications.

Manual Testing Essentials

Automated testing is necessary but not sufficient. Regularly test with:

  • Keyboard navigation: Can you complete all tasks using only a keyboard? Is focus visible? Is the tab order logical?
  • Screen readers: Test with VoiceOver (Mac), NVDA (Windows), and TalkBack (Android). Is content read in a logical order? Are interactive elements announced correctly?
  • Zoom: Does the application work at 200% and 400% zoom? Does text reflow without horizontal scrolling?
  • Color and contrast: Is information conveyed through means other than color alone? Do all text elements meet contrast ratios?

Common Accessibility Issues in React Applications

  • Custom interactive elements (dropdowns, modals, tabs) missing ARIA roles and keyboard handling.
  • Client-side routing not announcing page changes to screen readers. Use aria-live regions or focus management.
  • Modals not trapping focus — keyboard users can tab to elements behind the modal.
  • Images used as buttons without accessible names.
  • Dynamic content updates not announced to assistive technology.

Conclusion

Automated accessibility testing catches a significant portion of issues with minimal effort. Integrate axe-core into your testing pipeline, lint JSX for accessibility issues during development, and complement automated testing with regular manual testing using keyboards and screen readers. Accessibility is not a feature — it is a quality standard.

Improving your application's accessibility? Our team implements accessibility testing and WCAG compliance.