Accessibility

An automated scan of each site against the WCAG rules a machine can check, every week, in plain words — and an honest line about what it cannot see.

The Accessibility check sends up to ten pages of a site to Google’s PageSpeed Insights, which loads each one in a real Chrome and runs Lighthouse’s accessibility audits — the rules of axe-core, the open-source engine most accessibility tools are built on. CheckRoost keeps what fails, words it plainly, and compares each scan with the one before.

What it never says

That a site is compliant, certified or accessible. Automated checks find roughly a third of accessibility problems; using the site with only a keyboard, with a screen reader and zoomed in still needs a person. So there is no score and no badge: counts, the problems behind them, and a list of what to test by hand.

Which pages

The homepage, and up to nine pages from the sitemap: pages with forms first (contact, booking, donate), a couple of posts, and for a shop its shop page, a product and the cart.
Chosen once and kept, so each scan compares a page with itself. Settings on the check lists them, takes your own list instead, or chooses again from the sitemap.
Both widths, phone and desktop: a menu that becomes an unlabelled icon on a phone is only found at phone width.
As a first-time visitor, so a cookie banner is scanned too. It is part of the page, and often where contrast fails.
Public pages only. Nothing is signed in to, and checkout needs something in the cart, so it is left out.

What it reports

Each problem once, by rule: “Text with too little contrast — 14 elements on 3 pages”, with who it affects, how it is usually fixed on a WordPress site, examples of the elements, and Deque’s guide to the rule.
Which WCAG, grouped as WCAG 2.1 A and AA — the level the U.S. Justice Department’s rule for public bodies names — what WCAG 2.2 added, and good practice that is not a requirement.
New and fixed since the last scan, counted only on pages both scans read in full. A page PageSpeed could not load this week keeps last week’s result, said so, and is neither fixed nor new.
An accessibility statement, whether the homepage links to one or the site has a page at /accessibility/. A recommendation, never a failure.

When it warns

Only for a critical or serious problem under a WCAG A or AA rule. Moderate and minor ones, and good practice, are listed and never warn. It never fails: an inaccessible page is not an outage. Like broken links, it leads with what is new, and the Changes tab records each problem that appears or goes away.

How often, and the quota

Weekly by default, or daily at most; Check now on the check scans straight away. Each page at each width is one PageSpeed request, so a site is up to twenty a scan, from the same allowance as the Lighthouse check — connect your own key under Integrations → PageSpeed Insights. When PageSpeed runs out of quota the check stops asking and says so, rather than reporting pages as clean.

When Google moves PageSpeed to a new version of Lighthouse, new rules can arrive with it. That scan becomes a fresh baseline, so a new rule is not reported as a new problem on every site at once.

What still needs a person

The keyboard alone: every link, menu, form and popup reached and used, with the focus always visible.
A screen reader: VoiceOver or NVDA through headings, form labels, errors and anything that updates.
Zoom: at 200% and 400%, nothing cut off or overlapping, and no sideways scrolling.
Forms filled in wrongly on purpose: whether the error says what and where.
Media and the rest: captions that are right, not only present; checkout, and anything behind a login.