Web Accessibility Regression Testing in CI
A tool that runs accessibility checks on every pull request and fails the build only for newly introduced problems, so a team with an imperfect existing site can stop it getting worse. The baseline comparison is what makes accessibility tooling adoptable.
Intermediate
A small team, or one strong student willing to learn something new.1 semester, 2 students
5 to ship
3 optional extrasSuggested stack
What you should ship
- Crawler and checker running a defined rule set across configured routes, including authenticated pages
- Baseline snapshot mechanism recording known existing issues
- Differential reporting that fails only on issues absent from the baseline
- CI integration posting a readable summary as a pull request comment
- Keyboard navigation checks covering focus order and keyboard traps, which automated rule sets miss
If you have time left
- Screen reader output comparison across builds
- Grouping issues by component so a single root cause is reported once rather than forty times
- A dashboard tracking the baseline shrinking over time
The problem
Accessibility tools exist and teams do not adopt them, for a specific and rational reason: pointed at an existing site they report four hundred issues, the build fails, and the check is disabled that afternoon.
What you build
A checker with a baseline. Record the existing issues once, then fail the build only for new ones. The site stops getting worse immediately, and the baseline can be reduced deliberately over time.
Why this framing is the contribution
Everything else here is available off the shelf. The differential model, and the tooling around maintaining a baseline sensibly, is what makes automated accessibility checking something a real team will keep switched on. Argue that case in your report.
The part automated rules cannot do
Keyboard navigation. Standard rule sets check markup and contrast and cannot tell you that focus order jumps around, that a modal traps focus, or that a control is unreachable without a mouse. Scripting those checks is the technically interesting half.
How to evaluate it
Run it against several real open source web applications and report what it found, including how much of the output was genuinely actionable. Honesty about false positives strengthens the report.
Scope warning
Automated tools catch a minority of accessibility problems. Say so explicitly and position the tool as a regression guard rather than a compliance certificate.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.