Measuring WCAG Coverage by Page Template

2026-10-26

A site level accessibility score is a comforting fiction. It averages the lovingly built article template with the neglected account pages and reports a number that describes neither. Users do not visit averages. They visit templates.

Templates are also where the leverage is. On most sites, a handful of layouts produce nearly every page, so measuring coverage per template turns an overwhelming backlog into a short list of engineering jobs with enormous blast radius, in the good direction.

Why templates beat page counts

Auditing random pages spends effort proportional to page count. Auditing templates spends it proportional to impact. If the product template fails keyboard navigation, fixing random product pages fixes nothing. Fixing the template fixes the catalog.

Template coverage also explains strange audit results. A site can pass ninety percent of sampled pages while its checkout template fails, because sampling by volume underweights rare but critical paths. Weight templates by importance, not by population.

Building the template inventory

List the layouts that generate your site: usually ten to twenty for a commerce site, including the embarrassing ones everyone forgets, like password reset, order tracking, and error pages. For each, record how many pages it produces and what user task it serves.

Score each template with the same audit method and the same WCAG version, or the comparison is fiction. Note which components are shared, because a shared header or modal spreads its wins and its failures across every template that uses it.

Reporting coverage managers can use

A useful report is one line per template: pages produced, issues found by severity, the top barrier in plain language, and the owner. Sorted by a blend of severity and reach, it reads as a work queue rather than a compliance lecture.

Refresh it after each template changes and quarterly otherwise. Templates drift as teams ship, and last year's passing template is this year's problem more often than anyone expects.

Fixing in blast radius order

Repair order should follow impact: the template whose fix removes the most severe barriers from the most visited paths goes first. Often that is a shared component, a skip link pattern, a form error treatment, whose repair lifts five templates at once.

Track coverage after fixes at the template level too. Watching one template go from failing to passing, and knowing it carried forty thousand pages with it, is the kind of result that keeps accessibility funded.

Frequently asked questions

How many templates does a typical site have?

Most content and commerce sites run on ten to twenty page templates, plus shared components like headers, footers, and modals. The inventory is usually smaller than teams fear, which is why template level auditing is practical.

What does coverage mean for a single template?

The share of applicable WCAG criteria the template passes under a consistent audit method, reported with issue severity. A template can have high numerical coverage and still fail users if the missing criteria block a core task, so severity always travels with the score.

Why not just fix every page individually?

Because pages are generated. Fixing instances leaves the generator producing the same barrier on the next publish. Template and component fixes are the only repairs that stay fixed at scale.

How often should template coverage be remeasured?

After any significant change to a template or shared component, and on a quarterly cycle for the full inventory. Automated checks can watch continuously for regressions between manual audits.