Available
Find and prioritise the accessibility barriers on your website
We scan your pages in a real browser, on desktop and mobile, and tell you what fails, who it affects, where it is and how to fix it. In plain language, without overstating what a machine can detect.
Four types of scan
Start with a quick scan and move on to a full scan once you verify that the website is yours.
Quick scan
Up to 3 key pages of any website, without verifying ownership. Ideal for a first snapshot or for a sales proposal.
Full scan
Every page we find, up to the limit you set, with priority pages and exclusions. We read your sitemap and respect your robots.txt.
Custom scan
Only the URLs you choose: the checkout process, a new landing page or the page sample for a review.
Scheduled scans
Today you run the analysis again yourself, whenever you like, and each one is compared with the previous one. Scheduled weekly analyses will arrive with the paid plans, and daily ones with the Agency plan.
Full, custom and scheduled scans require you to verify that the website is yours: with a meta tag, a DNS record, a file or the Accessibility Centre snippet. Your whole history is saved and you can repeat any scan. More in How to organise fixes and follow up.
What we check
We run automated tests based on WCAG 2.2, levels A and AA, with axe-core, the most widely used open-source rules engine. We also turn on the target size check (success criterion 2.5.8), which is off by default.
On top of that, we add our own checks for barriers that the standard rules do not cover well:
- Content reflow at a width of 320 pixels (1.4.10).
- Increased text spacing (1.4.12).
- Tabbing through the page to detect keyboard traps and invisible focus (2.1.2 and 2.4.7), on one page per template and on your priority pages.
- Audio or video that plays automatically, and automatic redirects (1.4.2, 2.2.1 and 2.2.2).
- Language of the page (3.1.1).
- Third-party overlays, so you know what you have installed.
Each rule is linked to its WCAG success criterion and to the matching EN 301 549 clause. Best practices are shown separately and do not count towards the score.
What a machine cannot see
Automated tests only detect some of the barriers: according to published studies, between 14% and 57%, depending on the tool and how they are counted. That is why every scan ends with a list of success criteria that need your manual review, and the score is never presented as legal conformance.
Results sorted into five tabs
Each result goes where it belongs, so you never mistake a confirmed failure for an open question.
- Confirmed
- Failures the engine detects with certainty. They are your to-do list.
- Needs review
- Cases the engine cannot decide on its own. You mark them “It’s an issue” or “Not an issue”, with a justification.
- Manual review
- Success criteria that no automated test can check. We guide you step by step.
- Passed
- Rules your pages pass in the automated tests. This does not amount to conformance.
- Not applicable
- Rules with no elements to apply to, such as video rules on a website without videos.
Every issue tells you what to do
Severity is always shown with an icon, text and colour, never by colour alone.
| Severity | What it means | Example |
|---|---|---|
| Critical | Prevents people from using content or a feature. | A payment button with no accessible name. |
| Serious | Makes use very difficult for some people. | Text with insufficient contrast. |
| Moderate | Annoying or confusing, but people can still carry on. | Content outside the page’s landmark regions. |
| Minor | Has little impact, but is worth fixing. | Alt text that repeats the text next to it. |
Who fixes it
Each issue shows the role responsible: development, design or content. That way you can share out the work without having to decode technical reports.
Who it affects
We show who runs into the barrier: for example, people who use a screen reader, people who navigate with a keyboard only or people with low vision.
Where it is
Affected pages, device, template and the exact element, with a screenshot and code in the inspector.
How to fix it
A guide in Spanish with the WCAG success criterion, the EN 301 549 clause and code examples. Quick wins are highlighted.
Tracking between scans
Each issue has a stable fingerprint, so when you repeat a scan we know which issues are new, which remain and which you have fixed. What you decide is kept per element: if an element moves in the code, a check says so instead of counting it as fixed.
We store the engine version with every scan. If an engine update changes a result, we mark it as an “engine change”, not as a fix on your part.
An honest score
Today the score reflects the automated tests. Manual review is shown separately; when it feeds the score, it will make up 40%, the maximum without review will be 60, and until you have reviewed 80% of the success criteria you will see “Manual review pending”.
Start using SiteNorma
Create your account and start improving your website’s accessibility. The Free plan includes 10 scanned pages a month, with no card required.