Accessibility (WCAG) Overview
Codity's accessibility scan is a one-time run against a live website, bought one run at a time from One-Time Runs, like a pentest. It opens your deployed site in a real browser, the way a visitor does, and checks every page it reaches against the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. Run it against staging before a release and you find the unlabelled button, the image with no text alternative or the focus outline a CSS reset removed before your users do.
It is not a repository or pull request scan. It never reads your code, it does not run on pull requests, and it has nothing to configure per repository. You point it at a URL and run it when you choose.
It is built around one rule: a reported failure is a real failure. Anything a browser cannot decide on its own, such as text drawn over a photograph, is listed separately for a person to check and never counted. A page that could not be checked is listed as not checked, never as passing.
Download an example report (PDF)
How it works
- Add a site. Open One-Time Runs → Accessibility (WCAG), pick a domain you have verified (the same verified domains Pentesting uses) and give the start URL, usually your staging site. Add a test login if the pages that matter are behind one.
- Check the site. A free check loads the start page (with your login, if it is not a login form) to confirm the scanner can reach it. Nothing is charged until it passes.
- Run the scan. Buy a run, by card or from your wallet. It crawls the site, checks each page, and emails you when the report is ready. Run it again whenever you want a fresh report, for example before each release.
See Getting Started for each step in detail.
What a scan checks
On every page it reaches, a scan:
- runs the automated checks for the WCAG A and AA success criteria that a browser can decide, from missing text alternatives and form labels to colour contrast, page language and touch target size;
- walks the page with the keyboard, pressing Tab the way a keyboard user does, to find controls whose focus is invisible and places where focus gets stuck;
- lays the page out at 320 pixels wide to find content that forces sideways scrolling;
- opens menus, accordions and dropdowns and checks what was hidden behind them.
See What Gets Checked for the detail and the limits.
What you get
A report grouped by element: the same failing button in a header shared by 400 pages is one issue, not 400. Each issue has its WCAG criterion, a severity, the failing markup, where it is, and a link to the W3C's guidance on fixing it.
Every scan of the same site is compared with the one before, so you see what is new and what was fixed. Issues that do not apply to you, such as one inside a third-party widget, can be dismissed for the site, and stay dismissed on later scans.
The report also lists every WCAG 2.2 A and AA criterion with where it stands: failed, flagged for review, no automated failures, or needing manual review. It never claims a criterion is met, because automated testing cannot show that. See Reading the Report.
What it is not
An automated scan finds a large share of real-world failures quickly and repeatably, but not all of them. Whether captions are accurate, error messages helpful or a reading order sensible needs a person. Use the scan to find and fix what can be found automatically, release after release, and the report's criteria list to plan the manual review that a conformance claim or a VPAT needs.
Pages in this section
- Getting Started: turn scans on, add a site, run a scan
- What Gets Checked: the checks, and what they cannot see
- Scan Modes and Pricing: page budgets, the free check, free re-runs
- Reading the Report: issues, severity, the criteria list, comparisons
- Scope and Safety: what the crawler will and will not do on your site
- FAQ
