Free accessibility testing tools are automated scanners — axe-core, Lighthouse, WAVE-class checkers — that flag patterns against WCAG success criteria. They commonly catch roughly 30–50% of real WCAG issues: contrast failures, missing alt attributes, unlabeled forms, ARIA misuse, and broken heading structure. They do not prove compliance. Treat them as a first-pass catcher before a human reviews meaning, focus order, and content that has to make sense aloud.
What automated tools actually catch
Automated libraries shine on deterministic rules. Missing alt on an <img>, a form control without an accessible name, contrast pairs that fail luminance thresholds, heading levels that skip from h1 to h4, and ARIA attributes that contradict the element’s role are all machine-checkable. axe-core — Deque Systems’ open-source engine — evaluates against WCAG 2.0, 2.1, and 2.2 success criteria and is the same family of checks behind SortMyFile’s HTML accessibility scan. Lighthouse and WAVE-class tools cover overlapping ground with different UIs and report shapes. If a page fails these checks, you have concrete tickets; if it passes, you only know the automatable slice is clean.
What they miss (and why that honesty helps)
Scanners cannot tell whether alt text is actually meaningful, whether a custom widget’s tab order matches the visual layout, or whether a paragraph makes sense when a screen reader reads it top to bottom. Those failures need a person. Framing automated scanning as a first pass — not a certificate — is the useful differentiation. Teams that pretend a green Lighthouse score equals “accessible” ship bugs that never appeared in the report. Teams that run axe early, fix the mechanical issues, then do keyboard and screen-reader passes waste less time arguing about missing labels that a bot already found.
axe-core vs a full audit
A full accessibility audit mixes automated findings with manual exploration, assistive-technology testing, and remediation guidance. axe-core is one input to that process, not a substitute. SortMyFile’s HTML accessibility check runs axe-core locally on HTML you paste — useful when you want a private, zero-upload first pass on a component or static page snippet. For production apps you will still want continuous integration hooks [VERIFY: current axe DevTools / CI product names and pricing] and a human review schedule. Contrast-only questions can go straight to a dedicated contrast checker; axe will surface many contrast issues too, but a pair-wise design check is faster when you are still choosing tokens.
Running a first pass in the browser
Paste the HTML you care about into SortMyFile’s HTML accessibility check, run the axe-core scan, and fix every serious finding before you debate edge cases. Pair that with the contrast checker when design tokens are still in flux. Then walk the real page with keyboard only, and listen once with a screen reader on the flows that matter (checkout, apply, login). That sequence — automate the 30–50%, then manually cover the rest — is how free tools earn their keep without lying about coverage.
Try it now
Open the matching SortMyFile tool — processing stays in your browser.