accessibility-selenium-testing

v2026.09.24

Accessibility testing toolkit using Selenium WebDriver 4+ with Java 21+ and axe-core engine. Use when asked to validate WCAG 2.2 AA compliance, scan pages or components for a11y violations, test keyboard navigation, audit color contrast, check ARIA semantics, generate accessibility reports, filter axe rules, debug screen reader issues, or implement POUR principles (perceivable, operable, understandable, robust).

GitHub
Install command
npx skhub add fugazi/accessibility-selenium-testing
Markdown
SKILL.md

Accessibility Testing with Selenium WebDriver & Axe Core

This skill enables automated accessibility analysis within the Selenium WebDriver framework using the axe-core engine to detect WCAG violations and best practice issues directly in the browser.

Activation: This skill is triggered when you need to validate WCAG compliance, scan for accessibility violations, test keyboard navigation, audit ARIA semantics, or generate a11y reports.

First Questions to Ask

  • What app URL(s) or user flows are in scope (and what is explicitly out of scope)?
  • Is there an existing Selenium setup and how is CI run?
  • Which standard is the target (WCAG 2.2 AA by default), and are there org-specific policies?
  • Which pages/components are highest risk (auth, checkout, forms, modals, navigation)?
  • Are there known constraints (legacy markup, third-party widgets) that require exceptions?

Prerequisites

ComponentVersionPurpose
Java JDK21+Runtime with modern features
Maven3.9+Dependency management
Selenium WebDriver4.xBrowser automation
axe-core-selenium4.10+Deque axe-core integration
JUnit 55.10+Test framework
AssertJ3.xFluent assertions for readable failures
Allure2.xReporting with a11y violation attachments

Note: Use com.deque.html.axe-core:selenium Maven dependency for axe integration.


Target: WCAG 2.2 AA (wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22a, wcag22aa). See WCAG 2.2 spec.

Do NOT Use For

  • Playwright/TypeScript accessibility testing (use a11y-playwright-testing).
  • Authoring Selenium functional UI tests (use webapp-selenium-testing).
  • Full conformance sign-off — automated axe scans catch ~30-50% of issues; manual audit + assistive-tech testing is still required.

Axe-Core Tools Reference

AxeBuilder Configuration

MethodPurposeExample
new AxeBuilder()Create scanner instanceEntry point
.withTags(List<String>)Filter by WCAG tagswcag2aa, wcag21aa, wcag22aa
.include(String)Scan specific selector#main-content
.exclude(String)Skip selector from scan.third-party-widget
.disableRules(List<String>)Disable specific rulescolor-contrast
.withRules(List<String>)Run only specific ruleslabel, button-name
.analyze(WebDriver)Execute the scanReturns Results

Results Object

MethodReturnsPurpose
getViolations()List<Rule>Rules that failed
getPasses()List<Rule>Rules that passed
getIncomplete()List<Rule>Rules needing manual review
getInapplicable()List<Rule>Rules not applicable to page
violationFree()booleanTrue if no violations

Violation Impact Levels

ImpactSeverityCI Action
CriticalBlocks users completelyAlways fail build
SeriousSignificant barrierAlways fail build
ModerateSome difficultyWarn or fail
MinorInconvenienceLog for review

Step-by-Step Workflows

Workflow 1: Add A11y Scan to Existing Test

  1. Add dependency to pom.xml

    <dependency>
        <groupId>com.deque.html.axe-core</groupId>
        <artifactId>selenium</artifactId>
        <version>4.10.0</version>
    </dependency>
    
  2. Create AccessibilityHelper utility

  3. Add scan after page loads

    driver.get("https://example.com");
    waitForPageReady();
    AccessibilityHelper.verifyPageAccessibility(driver);
    
  4. Run and review violations

    mvn test -Dtest=A11yTest
    

Workflow 2: Test Specific Component

  1. Navigate to page with component visible

  2. Trigger component state (open modal, show dropdown)

  3. Scan only the component

    Results results = new AxeBuilder()
        .withTags(List.of("wcag2a", "wcag2aa", "wcag22aa"))
        .include("#login-modal")
        .analyze(driver);
    
  4. Assert and log

Workflow 3: Keyboard Navigation Audit

  1. Identify all interactive elements
  2. Tab through the page programmatically
    element.sendKeys(Keys.TAB);
    WebElement focused = driver.switchTo().activeElement();
    
  3. Verify focus order is logical
  4. Test Escape closes modals
  5. Verify no keyboard traps

Workflow 4: CI Integration

  1. Configure headless browser

    mvn test -Dheadless=true -Dgroups=a11y
    
  2. Set zero-tolerance for Critical/Serious

    long criticalCount = violations.stream()
        .filter(v -> List.of("critical", "serious").contains(v.getImpact()))
        .count();
    assertThat(criticalCount).isZero();
    
  3. Generate JSON report for tracking


Code Patterns

See references/code-patterns.md for full AxeBuilder scan patterns, violation logging, JUnit 5 integration, and CI/CD YAML.

Key snippet:

Results results = new AxeBuilder()
    .withTags(List.of("wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22a", "wcag22aa"))
    .analyze(driver);
assertThat(results.violationFree()).as("A11y violations").isTrue();

Troubleshooting

ProblemCauseSolution
Axe returns empty resultsPage not fully loadedAdd explicit wait for page ready state
False positives on contrastDynamic themesTest both light and dark modes
Violations in third-party widgetsCannot modify vendor codeUse .exclude() with documented ticket
Incomplete rulesRequires manual reviewLog for manual audit, don't auto-fail
Different results between runsAsync content loadingEnsure deterministic page state before scan
CI fails but local passesDifferent viewport/browserUse same headless config as CI

Triage by POUR Principles

PrincipleFocus AreasCommon Violations
PerceivableText alternatives, captions, contrast, structureMissing alt text, low contrast, missing labels
OperableKeyboard access, focus order, bypass blocksKeyboard traps, no skip link, focus not visible
UnderstandableLabels, predictable behavior, error handlingUnclear instructions, unexpected changes
RobustValid HTML, ARIA, name/role/valueInvalid ARIA, duplicate IDs, missing roles

Running Tests

Maven Commands

CommandPurpose
mvn test -Dgroups=a11yRun all accessibility tests
mvn test -Dtest=A11yTestRun specific test class
mvn test -Dheadless=trueRun headless (CI mode)
mvn allure:serveView Allure report with violations

CI/CD Integration

- name: Run Accessibility Tests
  run: mvn test -Dgroups=a11y -Dheadless=true

- name: Upload A11y Report
  uses: actions/upload-artifact@v3
  with:
    name: a11y-report
    path: target/a11y-results/

Red Flags

  • Treating a clean axe scan as full WCAG conformance — automation covers only ~30-50% of criteria.
  • Globally disabling rules instead of scoped .exclude() with a documented remediation ticket.
  • Scanning before the page is fully loaded — async content yields false "0 violations".
  • Failing the build on incomplete rules — those need manual review, not automatic failure.

References


Verification

  • Axe WebDriver audit passes — AxeBuilder.analyze(driver) returns zero critical violations
  • Keyboard accessibility verified — Tab navigation reaches all interactive elements
  • WCAG 2.2 AA compliance — All rules for AA level pass (includes WCAG 2.2 additions: focus-not-obscured, dragging movements, target-size minimum)
Discovery
Tags

No tags published for this skill.

Version
Latest version metadata

Version

v2026.09.24

Published

Sep 24, 2026

Category

Uncategorized

License

MIT

Source path

skills/accessibility-selenium-testing

Default branch

main

Latest commit

db514b5

Tree SHA

337a095