Most free accessibility tools have an accessibility problem.
WAVE is a browser extension with no keyboard-only workflow. Lighthouse runs in Chrome DevTools, a tool screen reader users navigate with workarounds. axe DevTools free tier gives you findings with no WCAG mapping unless you pay.
I'm a CIS student in Grand Rapids, MI doing freelance web accessibility work on the side. I needed a tool I could actually use in client engagements — structured output, WCAG-mapped findings, severity grouping — without paying $200/month for a platform.
So I built one.
What It Does
The MAS Accessibility Audit Toolkit is a free, open-source desktop GUI built in Python and Tkinter. Paste a URL, click Run Audit, get a structured findings report in under 60 seconds.
It currently runs 14 WCAG 2.1 AA check modules:
Alt text detection
Heading structure (h1 count + descent order)
Form label association
Language attribute presence
Tabindex abuse (positive values)
Empty links and empty buttons
Autoplay media detection
PDF link warnings (no user notice)
Page title check
Duplicate ID detection
Landmark roles (main, nav, header, footer)
Skip navigation link check
Accessibility patterns (generic link text, placeholder-as-label, onclick on non-interactive elements, missing table headers, blank target)
62 more modules are in the queue — including Color Contrast, Screen Reader Simulation, Platform Detection, and Touch Target CSS checks.
The Part I'm Most Proud Of
The auditor itself is fully accessible. It seemed like the minimum viable requirement — an accessibility tool that doesn't pass its own audit is indefensible.
Here's what that means in practice:
Four themes: Dark, Light, High Contrast, CVD-Safe
CVD simulation modes: Protanopia, Deuteranopia, Tritanopia, Monochrome — inside the tool, so you can see what your color choices look like to users with color vision deficiencies before you ship
Dyslexia font presets — Normal, Large, X-Large — persisted across sessions
Font family and size controls — 14pt to 20pt, user-adjustable, persisted
Word spacing and line height sliders — persisted
Screen reader announcements — on theme change, scan complete, and error states
Non-color prefix cues throughout — [!] for errors, [OK] for passes, [>] for informational — because color alone isn't enough
None of this exists in WAVE, Lighthouse, or the free tier of any tool I've used. An accessible auditor that audits for accessibility is the whole point.
What It Can't Do
Automated tools catch roughly 30–40% of WCAG failures. The MAS Toolkit is in that same range. It's static HTML analysis — it can't test keyboard interaction, evaluate screen reader announcements in real assistive tech, or assess cognitive load through user testing.
It's a starting point. A fast, structured, WCAG-mapped starting point — but not a replacement for manual review.
I say this upfront in every client engagement. The audit report documents it explicitly. Honesty about scope is a feature, not a disclaimer.
Where It's Going
The next phase of the build adds platform detection — identifying whether a client's site is on a locked CMS (Squarespace, Wix, res-menu.net) and flagging every finding with a PLATFORM RESTRICTED marker. Because there's no point handing a developer a remediation roadmap for a site they can't modify.
After that: color contrast checking, viewport meta checks, touch target CSS checks, and eventually a web SaaS version with Stripe billing and team access.
Try It
GitHub: github.com/MosleyAutomationSystems/MAS-audit-toolkit
MIT licensed. Free to use, fork, and build on.
If you're doing accessibility work and have feedback on the module list, the findings format, or anything else — I'm building this in public and I want to know what's missing.
Damascus (Bear) Mosley — Lead Developer & Accessibility Specialist, Mosley Automation Systems · Grand Rapids, MI
Top comments (2)
The platform detection feature you're planning is incredibly smart — I've seen so many accessibility audits that produce a beautiful remediation roadmap only for the client to realize they're on Squarespace and can't touch half the markup. Flagging findings as PLATFORM RESTRICTED upfront would save a ton of wasted effort in client engagements.
I run a large programmatic SEO site with thousands of pages generated from templates, and accessibility at that scale is a problem I think about a lot. When you're generating pages programmatically, a single template-level accessibility issue (missing landmark roles, bad heading hierarchy) multiplies across every page instantly. A tool that gives structured, WCAG-mapped output would be really valuable for catching those template-level issues before they propagate.
Your honesty about the 30-40% coverage ceiling is refreshing too. Most tools in this space oversell their coverage. The non-color prefix cues ([!], [OK], [>]) are a nice touch — curious if you've considered adding a CLI mode or API endpoint alongside the GUI? For programmatic sites, being able to pipe audit results into a CI/CD pipeline would be a killer feature.
Thanks for this — the template propagation problem is real and something the structured output is built to catch. Good to know that use case resonates.
CLI mode is actually already there — py audit.py example.com works today. JSON output is planned and would make CI/CD piping straightforward. Worth prioritizing based on what you're describing.
Platform Detection is next in the build queue for exactly the reason you named. A roadmap that doesn't account for whether the client can implement anything isn't complete.
Appreciate the honesty callout. 30–40% is the real number — clients deserve to know that upfront.