Methodology

How we check UK council websites, what our results mean, and what they don’t.

Version 0.1 (draft), October 2026. See changes.

In short

  • We check every UK council website, regularly and automatically, against WCAG 2.2 level AA.
  • We check the same set of pages on every council so results can be compared fairly.
  • Automated tests find only some accessibility problems, often estimated at around a third. Our results are an early warning, not an audit, a certification or a judgement of legal compliance.
  • A site with no issues found can still be difficult or impossible for disabled people to use.

Which websites we check

Every current principal council in the UK: 382 councils (317 in England, 32 in Scotland, 22 in Wales and 11 in Northern Ireland). Councils that share one website, such as Adur and Worthing, are checked once and reported together, which gives 379 websites.

The list of councils and their homepages comes from GOV.UK’s Local Links Manager, the same data that powers GOV.UK’s “Find your local council” service. We update it when councils are created, merged or abolished.

Which pages we check

On every council website we check:

Pages checked on each council website
PageHow we find it
HomepageGOV.UK’s record of the council’s website
Accessibility statementThe link to it on the homepage
Making a complaintThe link GOV.UK publishes for that council and service
Finding your councillor
Paying a parking fine
Applying for a council tax discountAs above. County councils in England don’t provide these services, so these pages aren’t checked for them
Reporting fly-tipping

We use GOV.UK’s published links rather than searching each site ourselves, so every council is checked on the page it has told GOV.UK is the right one for that service.

Many of these pages are run by suppliers on separate systems, such as payment, reporting and committee websites. We check them because they are part of the council’s service, and the accessibility regulations apply to them too.

We record whether the homepage links to an accessibility statement, because public sector websites are required to publish one. We don’t yet assess what the statement says.

How we test a page

  • Each page is loaded in a real browser (Chromium, via Playwright) at a desktop window size of 1280 by 720 pixels, as a visitor who isn’t signed in.
  • We wait for the page to finish loading, then run axe-core (currently version 4.13), an open source testing engine widely used by accessibility professionals.
  • We run only the axe-core rules that test WCAG 2.0, 2.1 and 2.2 success criteria at levels A and AA. We don’t run its “best practice” rules, which go beyond WCAG.
  • We don’t click, type, dismiss cookie banners or fill in forms. We test each page as it first appears to a visitor.

What automated testing can’t tell you

Automated tests can reliably find some kinds of problem, such as missing text alternatives, low colour contrast, form fields without labels and broken page structure. They cannot judge whether, for example:

  • text alternatives and link text actually make sense
  • everything can be done with a keyboard, without getting stuck
  • a screen reader announces changes and errors helpfully
  • content still works when zoomed or on a small screen
  • video has accurate captions and audio description
  • language and instructions are clear enough to follow

We also don’t currently check PDFs or other documents, or the steps after the first page of a service, such as completing a payment.

So our results show problems that definitely exist. They can’t show that a page is accessible. The only way to know that is a manual audit and testing with disabled people.

Pages we can’t scan

Sometimes a page can’t be checked. We record why, and the page is never counted for or against the council:

  • Blocked: the website refused our request, for example with a “403 Forbidden” response or a bot challenge. We also treat a page as blocked if it is a challenge or “access denied” page, even when the website reports it as a normal response. We never try to get round a block
  • Blank: the page loaded but had almost no content to test, usually because it didn’t finish loading
  • Disallowed: the site’s robots.txt file asks crawlers not to visit, or the robots.txt file can’t be reached
  • Error or not found: the page returned an error or didn’t load in time. This includes links in GOV.UK’s data that have gone out of date

If a council’s homepage can’t be scanned, we don’t check any of its other pages and the site is shown as not checked. For each site we show how many of its pages were checked.

How results are counted

For each page we record:

Issues
The number of different axe-core rules the page fails. A rule that fails on several parts of a page counts once.
Elements affected
How many parts of the page fail those rules.
Severity
Each issue is labelled critical, serious, moderate or minor, using axe-core’s own impact ratings.
Needs review
Rules that axe-core couldn’t decide automatically. These need a person to check and are never counted as failures.

For a whole website, an issue found on several pages counts once, at its most severe level. This means a problem in a shared header or footer isn’t counted again on every page.

How sites will be compared

We don’t publish a league table yet. Before we do, this section will set out exactly how websites are compared, and we will run it for several weeks to check that the results are stable and fair.

Whatever approach we use, these principles will apply:

  • We compare like with like, and show results for each type of council and each nation.
  • Serious and critical issues count for more than moderate and minor ones.
  • Pages we couldn’t scan don’t count for or against a council, and websites where too few pages could be checked aren’t ranked.
  • We never describe a site as “accessible”, “compliant” or as passing. A site with no issues found is described as exactly that.
  • Every result links to the full findings, so anyone can check them.

How we crawl

  • Our crawler identifies itself as PerceivableBot, with a link to our about page.
  • We follow robots.txt, including Crawl-delay. You can stop us checking your site by disallowing PerceivableBot.
  • We request one page at a time from each website, with a pause between pages, and check fewer than ten pages per site each time. If several councils use the same supplier’s system, requests to that system are spaced out in the same way.
  • We currently check every site once a day, overnight (UK time).

Corrections and disputes

If you think a result is wrong, or a page has been fixed and you’d like it checked again, email hello@perceivable.co.uk. Tell us the website and page. We’ll look at every request and correct anything we’ve got wrong.

Data sources and licences

  • Council and service page data: GOV.UK Local Links Manager. Contains public sector information licensed under the Open Government Licence v3.0.
  • Testing engine: axe-core by Deque Systems, used under the Mozilla Public License 2.0.
  • Raw results are available as JSON from /api/sites. We keep summary results indefinitely and the full findings for each check for 90 days.

Changes to this methodology

Any change that affects results will be listed here, with the date it took effect.

  • October 2026, version 0.1: first draft. No league table published.