How it works

What we check

Every check is against WCAG 2.1 AA, the standard the ADA’s Title II rule sets for state and local governments. It includes WCAG 2.0 AA, the standard Section 508 sets for federal websites. On each page we run:

• 70 automated checks from axe-core, the open-source accessibility rules, so anyone can repeat a result. They cover WCAG 2.1 A and AA, plus one WCAG 2.2 check on the size of things to tap, which we report but never score, since the rule does not require it.
• A phone-width check: whether the page fits a screen 320 pixels wide without scrolling sideways, as people who enlarge text need.
• A keyboard test on the homepage, and for governments in the index on the first form too. We press Tab through the page as a keyboard user would and record focus that gets stuck, focus that can’t be seen, controls that can be clicked but never reached, whether a working “skip to content” link exists, and outlines and field borders too faint to see.

Every problem is described in plain words: what is wrong and who it affects. The words for each check are written once and reused, so the same problem reads the same way on every site.

Which pages

• Up to 20 pages a site: the homepage first, then one page of each kind.
• We read up to 40 candidate pages from the homepage’s links and the site’s sitemap, group them by layout, and keep one of each, so pages built from the same template don’t crowd out the rest.
• Pages where visitors get things done come first: a form to complete, such as paying a bill or applying for a permit, then the site’s search, news, events, services and documents.
• We never sign in, submit a form or get past a login.

Why twenty: on 136 Virginia government websites we compared scans of different lengths. Twenty pages found 93% of the different problems that thirty pages found.

How the score works

Each site gets a score from 0 to 100. Every kind of problem we find earns points, and each point takes 2.5% off what is left, so a site with no problems scores 100.

• How widespread: a problem on every page we checked counts in full; on just one page, 30% of its points; in between, in proportion.
• How often: a problem found ten times on a typical page counts half as much again; a hundred times, double.
• Our labels, not the checker’s: something the open-source rules call critical counts as serious unless it is on our list of critical barriers.
• The phone-width check counts as a serious problem.
• What we leave out: the size of things to tap, which we report but never score. The keyboard test’s findings are shown on every report but don’t count yet: each joins the score once it has proved reliable, and we date that here.
• Too few pages: we give a score only when at least 5 pages could be checked. A site with fewer pages of its own, or one that turns away our visits to its other pages, shows what we found on the pages we could check, without a score.

The band, in plain words:

• Ready (100): no automated failures found on the pages checked.
• Almost ready (75 to 99): a few problems found, none a critical barrier.
• Behind (45 to 74): many problems found, or at least one critical barrier.
• Far behind (below 45): many problems found across the pages checked.

Any critical barrier keeps a site at Behind, whatever its score, because one control nobody can use can block a whole task. Each report also shows what the score would be with its critical barriers fixed.

Version 1, October 2026. Any change to these numbers is dated below, so scores can always be compared fairly.

Critical barriers

A critical barrier is something a visitor can’t get past at all. This is our list, not the checker’s own labels:

• Always critical: buttons, picture buttons and custom controls with no name; a page hidden from screen readers; sound that plays by itself; clickable pictures that need a mouse; keyboard traps; controls the keyboard can’t reach.
• Critical on a task page, such as a form or the site’s search: fields, drop-down lists, checkboxes and custom fields with no label, and embedded content the keyboard can’t reach.

Links with no name, usually social-media icons, are serious but not critical: they confuse people, but rarely stop them.

The index of government websites

Every government in the index is checked again every three months, in January, April, July and October: federal websites, every state government, and the counties, cities and towns of Maryland and Virginia.

• Each has a public page with its score and band, its critical barriers, what is wrong and who it affects, and how it compares with governments like it.
• Its own staff can claim the page with an email address on the domain of the website we check, to see where each problem is and what needs to change, set the page’s status for residents, and scan again any day. A scan they start is published on the page like our regular check, marked as checked at their request.

What automated checks cannot see

Automated checks find many problems but not all. They can’t judge whether an image description is accurate, whether captions match what is said, whether the reading order makes sense or whether the language is plain. That is why we never call a site compliant, and why even “Ready” means only that no automated failures were found.

• A result is a snapshot. It shows what our scanner found on the date shown; a site can change the next day.
• Some content is out of reach. We don’t check anything behind a sign-in, and content that appears only after someone uses the page, such as a menu that opens or a form’s error messages, may not be fully checked. Documents a site links to, such as PDFs, aren’t part of a website’s scan; our PDF check reads them one at a time.
• Checks can be wrong both ways. An automated check can flag something that is fine, and miss something that isn’t. If you think we got one wrong, tell us.
• Not a certificate, and not legal advice. A result says what our checks found, not whether a site meets the law.

The surest next step after an automated check is a review by a person who knows WCAG, with testing using screen readers and other assistive technology, ideally by people with disabilities who use them every day.

Accessibility overlays

Some sites add an overlay, a script that promises to fix accessibility automatically. We check a site as its visitors receive it, overlay included, and say when we find one. Overlays don’t fix the site’s own code, and they can make automated results look better than what a person using a screen reader or a keyboard actually meets.

How we treat the sites we check

• Our scanner names itself on every request and links to a page that explains it.
• It follows each site’s robots.txt file, including any crawl delay, and opens one page at a time with a pause of at least two seconds between them, to keep the load on a site light.
• It never tries to get around a block. A site that turns it away, with a block page or by closing the connection on it, has no score, so it never counts as failing.

Documents

Scans don’t yet check the PDFs a site links to. When they do, PDF findings will sit beside the score, never in it: the rule exempts some older documents, and only a site’s owner knows which are still in use. Meanwhile anyone can check a PDF with our free PDF check.

Disputes and corrections

Anyone can tell us a result is wrong. A person checks it against the evidence we keep from that scan; if we were wrong, we correct the page and date the correction. We keep the evidence behind every published score for three years. Dispute a result.

Changes to this method

When the method changes, we say what changed and when, here, so scores can always be compared fairly.

• Version 1, October 2026: the first version.