Skip to content

Automated Testing

Automated tests enable quick and scalable detection of common barriers. They are particularly suitable for use in early phases of development and for continuous quality assurance throughout the project.

Contents of this page:

Goals of automated tests: Efficient identification of typical errors, quick feedback for developer teams, integration into build and CI/CD processes

Typical types of errors:

  • Missing alternative texts for images
  • Contrast problems between text and background
  • Missing or unclear form labels
  • Empty links or buttons without semantic role

How automated tools work:

Automated testing tools analyze the source code of a page – especially the structure of the DOM (Document Object Model) – and apply rule-based heuristics to detect known violations of WCAG criteria. This involves using predefined rule sets that typically relate to WCAG 2.1 or 2.2 at level A or AA. Tools like Axe or Lighthouse visually mark problematic areas and provide guidance for correction.

It should be noted: Automated tests can reliably cover only about 20–30% of WCAG success criteria. Many requirements, especially regarding semantic meaning, usability, and comprehensibility, cannot be detected mechanically. This can lead to “false negatives” (undetected errors) or “false positives” (incorrectly reported problems).

Common tools and features:

  • WAVE: Browser extension for visual analysis
  • Axe DevTools: Developer-friendly, easily integrable into development environments
  • Lighthouse: Integrated in Chrome, also covers performance and SEO
  • Microsoft Accessibility Insights: Offers both quick tests and step-by-step checks
  • BAAT (BITV test tool): Suitable for German requirements

Limitations of automated tests:

  • No assessment of keyboard operation or screen reader compatibility
  • No understanding of context, meaning, or user guidance
  • No holistic assessment of user-friendliness for people with disabilities
  • Combination with manual tests for complete coverage
  • Automated tests as part of the continuous quality process
  • Use as a preliminary check for legally relevant tests (e.g., BITV, BFSG)
  • Use in the pull request process or as part of automated builds (CI/CD)