Search across all content
A free, open-source tool that checks lists of web pages against accessibility standards using multiple testing engines and publishes the results as a public report.
Government websites are how many people access public services — applying for benefits, paying taxes, finding information about their rights. But not every website works for every user. Someone who cannot see the screen and relies on a screen reader, someone who cannot use a mouse and navigates with a keyboard, or someone who needs larger text or higher contrast to read a page — each may find a government website difficult or impossible to use if it was not designed with accessibility in mind.
The tools available for running checks in-house require technical expertise to operate, produce reports that are difficult for non-technical colleagues to interpret or share, and often need to be run manually every time. For teams responsible for many web pages, maintaining a consistent picture of accessibility across all of them is hard to sustain.
There are proprietary tools that crawl websites and are able to provide an analysis of accessibility issues they find. Unfortunately, many are set up primarily as a safeguard from litigation. The costs of these tools range, but it can easily impact budgets for staff who can effectively fix the problems.
There is also a transparency problem. Government accessibility audits are often conducted by private firms, and the resulting reports are frequently kept private rather than shared publicly. Many governments around the world have a legal requirement to meet accessibility standards, but without public reporting there is no straightforward way to see to what degree those requirements are being met. At a time when many government teams face budget constraints, spending on expensive audit software or external consultants can be difficult to justify — particularly when that spending goes towards identifying problems rather than fixing them. EU members have monitoring bodies and regular reporting to track progress, but nations do not have a consistent approach to this.
Open Scans was built to address these barriers. It is a free, open-source tool that allows anyone to submit a list of web page addresses and receive a public report on how accessible those pages are.
The process is straightforward. A user visits the Open Scans website, enters a title for their scan and a list of web addresses (up to 500, though batches of 100–150 are recommended for best results), and submits the request. The tool then systematically visits each page and checks it against established accessibility standards. Results are typically available within 30 to 60 minutes, depending on the number of pages scanned. The report is published online, so anyone can be pointed to it directly — there is no need to send attachments, request access, or have technical expertise to view the results.
Scans can be set to run on a recurring schedule — weekly, monthly, quarterly, or on a specific day of the week — so that accessibility is monitored on an ongoing basis rather than depending on someone to start the process each time. A team can set up a scan once and have it run automatically every week, building up a picture of how accessibility changes over time without any further manual effort.
The tool also gives users a choice of how accessibility is assessed. Most people who check for accessibility rely on a single widely used testing engine. Open Scans supports five different engines — Axe, ALFA, Equal Access, AccessLint, and QualWeb — each of which has slightly different rules. By default, a scan runs Axe plus one randomly selected additional engine, providing broader coverage without the overhead of running all five every time. Axe prides itself on avoiding false positives, so that developer time is not wasted chasing phantom errors. Users can also choose to run specific engines or all of them at once, depending on how thorough they want the check to be.
Reports include pass, fail, and “can't tell” statistics for each page scanned, and are available in multiple formats including a readable summary, spreadsheet-ready data, and structured data for further analysis. This means the results can be used both by non-technical staff who want to understand the overall picture and by developers who need the detail to fix specific issues.
Open Scans runs entirely on free, publicly available infrastructure. It uses GitHub Actions — a widely available service for running automated tasks — and GitHub Pages for publishing results. No software needs to be purchased, no servers need to be maintained, and no external provider needs to be contracted. This means that a government team can set up regular accessibility monitoring using tools they may already have access to, at no cost.
The tool was built with the help of AI coding assistants during development — tools like GitHub Copilot were used for writing code, drafting documentation, and reviewing changes. However, the tool itself does not use AI when it runs. The tool emphasises automation where it can handle the work reliably, while recognising that some aspects of accessibility — judgements about whether something truly works for a person with a particular need — still require a person to review. The reports flag what the automated engines can detect; human review remains necessary for the aspects of accessibility that machines cannot assess on their own.
Open Scans is in active development, with core functionality for submitting scans, running multiple accessibility engines, and publishing public reports now working. The tool can also integrate with a companion tool called Top Task Finder, which identifies the most-visited pages on a website, allowing teams to prioritise accessibility checks on the pages that matter most to users. The project is open-source and publicly available for any team to adopt, test, and contribute to.





Connect with 500,000+ public servants solving your hardest challenges.





Connect with 500,000+ public servants solving your hardest challenges.
Help public servants worldwide learn from your work, what worked, what flopped and what you'd do differently
Share your project
Log in or sign up to continue the conversation