Testing & Tools

HTML_CodeSniffer Explained: The Secondary Accessibility Scanning Engine

HTML_CodeSniffer (HTMLCS) is an open-source accessibility testing engine, originally developed by Squiz Labs, that predates axe-core and takes a somewhat different approach to rule coverage — including checks for WCAG AAA-level criteria and some presentational-markup patterns that axe-core's own ruleset doesn't cover.

Why run two engines instead of just one

No single automated engine catches every automatable WCAG issue — different tools' rule authors made different design decisions about what to check and how strictly. Running HTMLCS alongside axe-core as a secondary pass catches genuinely different findings that axe-core's own ruleset doesn't cover, at the cost of some overlap that needs deduplication (the same underlying issue reported by both engines should appear once to the user, not twice).

HTMLCS's three severity levels

Unlike axe-core's four-bucket result model, HTMLCS classifies each finding as an error, a warning, or a notice:

• Errors are treated as deterministic violations, similar to axe-core's violations bucket
• Warnings are also treated as findings requiring attention, though with somewhat less certainty than errors
• Notices are advisory, manual-review prompts for criteria that genuinely can't be fully automated (color-only information checks, timing-related checks, focus-behavior checks) — these get surfaced as "needs manual review" rather than counted as confirmed violations

A concrete example of HTMLCS's distinct coverage

HTMLCS's H49 technique check flags obsolete presentational HTML — <center>, <font>, the align attribute — a pattern axe-core's own ruleset doesn't specifically target. See Obsolete Presentational Markup for the exact tags this catches and how to fix each one; this is a good illustration of why a second engine's different rule authors catch genuinely different real-world issues.

How overlap gets handled

When both engines would flag the same underlying issue on the same element (a missing alt attribute, for instance, which both axe-core and HTMLCS can each independently detect), a well-built scanning pipeline deduplicates by rule-and-element fingerprint so the same real-world problem surfaces once in a report, not as two separate, redundant findings — treating the two engines as complementary layers rather than fully independent, unrelated reports.

The practical takeaway

Neither engine alone is "the" answer — axe-core's zero-false-positive design and broad industry adoption make it the right primary engine, while HTMLCS's different rule set (plus its willingness to flag AAA-level and presentational-markup issues axe-core skips) makes it a useful secondary pass for catching what the primary engine's own rule authors didn't prioritize.

Common questions

What is HTML_CodeSniffer?

An open-source accessibility testing engine by Squiz Labs that predates axe-core and checks a somewhat different, broader rule set, including WCAG AAA-level criteria and presentational-markup patterns.

Why run HTML_CodeSniffer alongside axe-core?

No single engine catches every automatable issue. HTMLCS surfaces genuinely different findings axe-core's ruleset omits, so running it as a secondary pass (with deduplication) improves coverage.

What are HTML_CodeSniffer's severity levels?

Three: errors (deterministic violations), warnings (findings needing attention with less certainty), and notices (advisory manual-review prompts for criteria that can't be fully automated).