Add the accessibility audit to the pipeline
The accessibility audit moved from a report somebody runs to a gate new violations cannot pass.
The ticket
Add the accessibility audit to the pipeline so new violations cannot merge.
Acceptance criteria
- The audit runs on every pull request
- A seeded violation fails the build
- Existing violations are recorded as a baseline that can only shrink
- The baseline is visible rather than hidden in configuration
What lands as proof
A seeded violation failing the build, plus a baseline that ratchets down rather than absorbing new failures.
Why teams defer it
- Turning it on with existing violations blocks every pull request, so a baseline is required first.
- A baseline that can grow is not a gate, and configuring it to only shrink takes deliberate setup.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: add the accessibility audit to the pipeline so new violations cannot merge. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means a seeded violation fails the build, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops for the plan, and the review bar is raised afterwards so that smaller suggestions block the merge too, not only serious findings.