/// Section 508 testing
Section 508 testing that runs on every page, every build
Accessibility compliance is a reporting problem as much as a testing problem. L3git turns the Section 508 / WCAG 2.0 AA audit into a checkbox on tests you already run and produces the per-page evidence a reviewer asks for — offline, from code you own.
What "508 testing" has to produce
Section 508 of the Rehabilitation Act requires federal agencies’ ICT to be accessible; the Revised 508 Standards incorporate WCAG 2.0 Level A and AA. Procurement and ATO reviewers do not want to hear that a tool exists — they want evidence per page, dated, repeatable, and ideally produced by the same pipeline that tests everything else.
One checkbox at startup: “Section 508 audit of every page.” No new step types, no new script, nothing to wire into each test.
Each page a test visits is audited with the bundled axe-core engine against the Section 508 and WCAG 2.0 A/AA rule sets — offline, inside your pipeline.
Results attach to each scenario in the Cucumber / Allure report, and a standalone Section 508 Compliance Audit chapter (HTML + JSON) is written to target/a11y/ on every run.
What the compliance chapter contains
Per-page results, dated
Every URL audited, which scenario reached it, when, and whether it was clean — the index a reviewer reads first.
Per-rule evidence
For each failing rule: impact, the standard it maps to (Section 508, WCAG 2.0 A / AA), how many nodes failed, the first failing element’s selector and HTML, and a link to the fix guidance.
Report-only or gate
Default is report-only so switching it on never breaks a green build. Set a11y.audit.fail=true and a violation at your chosen impact fails the scenario. The explicit per-page A11y step remains for targeted gates.
Honest scope
Automated checks cover the machine-testable criteria — roughly half of WCAG success criteria. The chapter says so, and we recommend pairing it with a manual keyboard and screen-reader pass for a complete assessment.
This site passes the same audit: 0 violations across 17 pagesWhy it fits regulated environments
- Nothing leaves the network. axe-core is bundled; no hosted accessibility service, no page content sent anywhere. Air-gapped keys make zero outbound calls.
- Drives the IT-installed Edge. No browser binaries downloaded onto hardened hosts.
- Standard output. The audit runs from an ordinary Maven project you own; the same
mvn testthat runs functional tests produces the 508 evidence. - No code required to author tests. Point-and-click recording means the analyst who knows the application can produce the coverage.
Regulated & air-gapped details → · Security & data handling → · Release notes →
Common questions
Does L3git make an application Section 508 compliant?
No tool can. It automates the machine-checkable rules (axe-core covers roughly half of WCAG success criteria), produces repeatable per-page evidence, and catches regressions on every run. Keyboard, screen-reader and cognitive criteria still need a manual pass; the report says this explicitly.
Which standards does the audit run against?
By default the axe-core rule tags section508, wcag2a and wcag2aa - the Revised 508 Standards incorporate WCAG 2.0 Level A and AA. You can add wcag21aa or wcag22aa in one property.
Is this the same as a VPAT or ACR?
No. A VPAT / Accessibility Conformance Report is a vendor document describing conformance; the L3git chapter is test evidence you can cite in one. It does not generate or sign an ACR.
Does the audit send page content to a cloud service?
No. axe-core runs inside the browser on your machine or CI agent, from a bundled copy. Nothing is transmitted.
What does it cost?
It is included in every edition at no extra charge: L3git UI is $49 per user per month with unlimited runs in your own CI. A 14-day trial needs no key or card.