Accessibility by template checks a sample of your site's pages with axe-core, a widely used accessibility rule engine, and groups what it finds by rule and by page template. It tests a sample, not every page, and automated rules find only a part of the problems in the Web Content Accessibility Guidelines (WCAG). Passing every rule does not make a site accessible.
Open Site Crawler, then Accessibility, and pick a site from My Sites.
What gets tested
PerfBee puts a site's pages into templates: pages built from the same HTML skeleton (read in detailed scans) or with the same URL pattern, such as /products/{slug}. Accessibility problems usually sit in the template (the menu, the footer, the product card), so one page per template finds the problems that a template repeats on its pages. A run tests one example page of each of your 10 biggest templates, so it never tests more than 10 pages. Templates come from your scans, so a site that has not been scanned has none.
The pages are opened in Chromium as PerfBeeBot, the same way a scan renders a page, at the pace your site's robots.txt asks for. A page robots.txt disallows is skipped. Nothing is clicked, typed or submitted. The run does not sign in, and it does not send the PerfBee token or the Staging access you saved in My Sites. So a page behind a login, or on a site that lets PerfBeeBot in only with that token or access, shows what any visitor would get. An error such as 401 or 403 is listed as could not be tested.
Starting a run
Before anything is spent you see the pages that would be tested and the credits for them. Each page that gives a result costs credits. A page that could not be tested (it answered with an error, took too long or sent the browser to another site) and a page skipped by robots.txt cost nothing, and the run lists them with the reason. You confirm the number you were shown: if the pages or the price changed in the meantime you are shown the new number and asked again. One run at a time per site, with a short wait before the next. Viewers can read results but not start a run.
PerfBee keeps the newest 3 runs of a site.
Reading the results
- Violations: an element that breaks a rule. Each one shows the rule, how serious axe rates it (critical, serious, moderate, minor), how many elements on the page break it, and the first element with a short piece of its code.
- Needs review: axe could not decide by itself. A person has to look.
- By rule lists each rule once in each group, Violations and Needs review, with the templates it appears on. Open a rule to see the WCAG criteria it relates to, an About this rule link and the pages that break it. By template shows each tested page with its findings.
A finding that comes from a template's shared layout is likely on the template's other pages too. One that comes from a single page's own content, such as a photo an editor added without alt text, is not. It is a sample: a page of the same template with different content can have problems the example page does not.
The same findings appear on a page's detail, in the Accessibility tab under Accessibility by template, for the template of that page. Each finding there also shows its WCAG criteria.
In Fixes
The newest completed run also appears in Fixes, one fix for each rule it found as a violation (needs-review findings are not fixes). A fix says how many tested pages carry the rule, on how many templates, how serious axe rates it, how many elements it hit and an example page, and its pages are those tested pages. It ranks among your other fixes by three things: how serious the rule is, how many tested pages carry it, and how much those pages matter. Pages matter more when they are well linked, close to the start page and in the sitemap. Because the run tests a sample, the counts are tested pages, never a share of your site's pages. Fixes made from a run are for you only: they are not in the API, the assistant (MCP) tools, webhooks or emails, and they never change a site's score.
On these fixes the Check if fixed card has no check button: a scan does not run the accessibility rules, so only a new run tells you whether the problem is gone. Start a new run from the Accessibility tab after you change the template. A fix whose rule the new run no longer finds is marked resolved, with the run as the reason. A fix whose pages left your site, or whose run was removed, drops off the list without being marked resolved. You can accept a fix, mark it won't fix or snooze it like any other.
What automated rules cannot tell you
axe checks what a program can decide from the page: missing text alternatives, colour contrast, form labels, button and link names, document structure and valid ARIA. It cannot tell whether alt text describes the image, whether the page works with a screen reader, whether the reading order makes sense, whether every function works with a keyboard alone, or whether the text is easy to understand. It does not test states that need an action, such as menus that open on a click, forms after an error, or content behind a login. Those need a person, and for a legal or procurement requirement an audit by an accessibility specialist.
PerfBee phone check
Each page that gave a result is also opened a second time at phone width: 412 pixels wide, as a touch screen, with images not loaded. PerfBee measures four things on that view and lists them next to the other findings, marked PerfBee phone check · not WCAG. They are PerfBee's own measurements, not WCAG tests, and the pages are the same sample. The rules above do not change: axe still reads the desktop view.
- Page scrolls sideways on a phone (serious): the content is wider than the screen and the page does not hide the overflow.
- Page not laid out for a phone (serious): the page has no usable viewport tag, so the phone lays it out wider than its screen and shrinks it.
- Tap targets small and close together (moderate): links, buttons or fields smaller than 48 by 48 pixels with another target within 8 pixels. A link inside running text is not counted. A target that is small only because its image was not loaded is listed under Needs review.
- Text too small on a phone (moderate): more than 40 percent of the visible text is smaller than 12 pixels. A page with less than 50 characters of text, or with the viewport finding above, gets no text-size result.
The phone view is one more page load of your site for each tested page, sent as PerfBeeBot at the same pace, and it costs no extra credits. Scripts and styles come from the run's cache. The confirmation before a run says so. If the second load fails or runs out of time, the page's phone view is listed as not measured and the page is still charged as before; a failure is never read as "no problems". A site that serves a different page to phones, or that covers the page with a consent banner, can give different results.
Accessibility by template and the PageSpeed Accessibility tab
A page's detail also has an Accessibility tab with the accessibility audits from the PageSpeed (Lighthouse) test you ran on that page. That test is run by Google, from Google's servers, so a page that blocks Google or is not public cannot be tested. This feature opens the page itself, as PerfBeeBot, and tests a sample of templates rather than one page. The two overlap and do not replace each other.
Download
Download the findings of a run as CSV or Excel (Starter and up) with the Download button in the Accessibility tab of Site Crawler. The Accessibility tab in a page's detail has no download.