Running an accessibility audit for an entire web app (or even just part of it) isn’t rocket science – but depending on the product’s complexity, it can be quite challenging. It gets really tedious when the tools used for documentation get in the way instead of helping. That’s exactly where my frustration began.
The starting point: cheat sheets, spreadsheets, frustration
Over time I tried all sorts of things:
- simple notes / cheat sheets
- Excel or Google Sheets
- loose Markdown files
- scattered links to WCAG references
None of these actually integrated smoothly into my workflow. Either writing down results was too slow, or the structure became messy quickly – or I spent too much time filtering out things that weren’t relevant at that moment.
So I asked myself:
What if I could record with a single click or keystroke: Test passed? Yes/No.
Add notes – precisely in context.
And: Jump quickly to the matching rule if I’m unsure.
Also: Filter out tests that don’t apply in this context (e.g. video or audio-specific requirements in a purely text-based app).
The result of these thoughts is: a11yAuditHelper.
Goals of the tool
I wanted a tool that:
- doesn’t get between me and the audit
- supports my thinking instead of making me think about the tool
- enables fast navigation and evaluation
- shows me progress at any time
- stores data locally only (privacy, confidentiality!)
Core features
- Local data storage All data stays strictly in the browser (Local Storage / IndexedDB). No server. No transmission.
- Built-in rule sets WCAG and BITV are integrated (structured tests / criteria).
-
Granular filtering
- WCAG level: A / AA / AAA
- Thematic areas (e.g. Audio, Video, Structure, Forms, Contrast, etc.)
-
Real-time status overview
- How many tests have been evaluated?
- How many passed / failed / still open?
- Multilingual German and English – switch without data loss.
- Keyboard control & shortcuts Standard shortcuts included – freely re-definable (for power-user flow).
- Contextual notes Every evaluation can include a note (e.g. “Missing aria-label on icon button”).
- Direct rule reference Jump to documentation (WCAG/BITV) for quick lookup.
-
Export & further processing
- Tabular summary (for reports or handover to teams)
- Download as CSV (e.g. import into ticket systems or DMS)
Why not just keep using Excel?
Excel (or Google Sheets) is:
- too generic
- not keyboard-first
- not context-aware (you constantly have to rebuild structure)
- no direct linking to rule descriptions
- no filtering flow that guides you through only the relevant tests
In short: Spreadsheets are great for data – less so for guided review processes with semantic context.
Roadmap / ideas (feedback welcome!)
- Add other rule sets
- Data import
- Dark mode (accessibility first: contrast checked)
If you’re missing something: let me know!
Where can I find the project?
https://a11yaudithelper.frontendcoder.de/
Conclusion
Accessibility audits shouldn’t be harder just because the documentation tool slows you down.
a11yAuditHelper is my attempt to make the process more focused, faster, and less frustrating – especially for recurring reviews.
If you audit regularly: give it a try.
If you have ideas or miss a feature: let me know
Do you have questions or suggestions? Feel free to leave them in the comments.
Happy auditing!
Top comments (0)