I Built a Free Accessibility Auditor That Actually Passes Its Own Audit

Source: Dev.to

Most free accessibility tools have an accessibility problem.

• WAVE – 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 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, and 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. An accessibility tool that doesn’t pass its own audit is indefensible.

Accessibility features

• Four themes: Dark, Light, High Contrast, CVD‑Safe
• CVD simulation modes: Protanopia, Deuteranopia, Tritanopia, Monochrome (inside the tool)
• Dyslexia font presets – Normal, Large, X‑Large (persisted across sessions)
• Font family and size controls – 14 pt to 20 pt, 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: [!] 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 performs static HTML analysis only, so it cannot:

• Test keyboard interaction
• Evaluate screen‑reader announcements in real assistive technology
• Assess cognitive load through user testing

It’s a fast, structured, WCAG‑mapped starting point—but not a replacement for manual review. I state this upfront in every client engagement, and the audit report documents it explicitly. Honesty about scope is a feature, not a disclaimer.

Where It’s Going

The next phase adds platform detection—identifying whether a client’s site is on a locked CMS (Squarespace, Wix, etc.) 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.

Future milestones:

• Color contrast checking
• Viewport meta checks
• Touch‑target CSS checks
• A web SaaS version with Stripe billing and team access

Try It

• GitHub:
• MIT licensed – free to use, fork, and build on.

If you’re doing accessibility work and have feedback on the module list, findings format, or anything else—I’m building this in public and want to know what’s missing.