WCAG — the Web Content Accessibility Guidelines — is the international standard for making web content usable by people with disabilities. It is published by the W3C, and it is the standard that essentially every accessibility law in the world points at rather than writing its own rules.
The current versions are WCAG 2.1 (2018) and WCAG 2.2 (October 2023). WCAG 2.2 adds nine success criteria and is backwards compatible: meeting 2.2 means meeting 2.1.
The POUR principles
WCAG is organised under four principles. Content must be:
- Perceivable — information must be presentable in ways users can perceive. Text alternatives for images, captions for video, sufficient contrast, content that does not rely on colour alone.
- Operable — the interface must be usable. Everything reachable by keyboard, enough time to read and act, no seizure-inducing flashing, clear focus indicators.
- Understandable — content and operation must make sense. Readable language, predictable behaviour, helpful error messages.
- Robust — content must work with current and future user agents, including assistive technology. Valid markup, correct roles and names.
Under those four principles sit guidelines, and under those sit success criteria — the specific, testable requirements you actually conform to.
Conformance levels: A, AA, AAA
| Level | Meaning | In practice |
|---|---|---|
| A | Minimum | Essential barriers removed. Not sufficient for any legal requirement. |
| AA | Standard | The level virtually all legislation requires. The realistic target. |
| AAA | Enhanced | Strictest. W3C itself states it is not required or achievable for entire sites. |
Target AA. It is what the law asks for, and it is achievable across a whole site. Pick individual AAA criteria where they meaningfully help your audience, but do not set site-wide AAA as a goal — the W3C explicitly advises against it.
A few of the most commonly failed AA criteria:
- 1.4.3 Contrast (Minimum) — 4.5:1 for normal text, 3:1 for large text. The most common failure on the web, and usually a decision made in a design tool by someone who never checked.
- 1.1.1 Non-text Content — every image needs an appropriate text alternative. Decorative images need an empty
alt="", not a missing one and not a description. - 2.4.7 Focus Visible — keyboard focus must be visible. Removing focus outlines with
outline: noneand not replacing them is a direct failure. - 4.1.2 Name, Role, Value — every control must expose a name, role, and state. Icon-only buttons with no accessible name fail this constantly.
- 2.1.1 Keyboard — all functionality available from a keyboard, with no traps.
- 1.3.1 Info and Relationships — structure conveyed visually must also be conveyed in markup. This is where heading structure and real form labels matter.
ARIA
ARIA (Accessible Rich Internet Applications) is a set of attributes — role, aria-label, aria-expanded, aria-live and others — that describe the purpose and state of interface elements to assistive technology when native HTML cannot.
The governing rule, from the W3C's own authoring practices, is blunt and worth memorising:
No ARIA is better than bad ARIA.
A native <button> is accessible for free. A <div role="button"> needs a tab index, key handlers for Enter and Space, focus styling, and correct state management — and most implementations get at least one of those wrong, producing something less accessible than the plain element would have been.
- Use native HTML elements first. Reach for ARIA only when no native element fits.
- Never change an element's implicit role without implementing the full expected behaviour.
- Keep
aria-*state attributes synchronised with reality. A stalearia-expanded="false"on an open menu actively misleads. - Give every interactive control an accessible name.
- Use
aria-livesparingly for genuinely dynamic updates; overuse makes a page unbearable to listen to.
What automated testing can and cannot find
This is the most important thing to understand about accessibility tooling, including Sitecheck's.
Automated tests reliably catch roughly 30–40% of WCAG issues. That is the consistent finding across the field, and any tool claiming to certify full compliance automatically is misrepresenting what is possible.
Automation is genuinely good at: colour contrast, missing alt attributes, missing form labels, empty buttons and links, invalid ARIA, heading order, missing page language, duplicate IDs. These are objective and machine-checkable, and they are also very common — so automated scanning is worth doing and worth doing continuously.
Automation cannot judge: whether alt text is meaningful rather than merely present, whether focus order is logical, whether an error message is actually helpful, whether a custom widget behaves sensibly with a screen reader, whether captions are accurate, or whether the page makes sense when linearised.
A serious accessibility process uses both:
- Automated scanning, continuously, to catch regressions and the high-volume objective failures.
- Manual testing — keyboard-only navigation, a real screen reader, zoom to 200%, and ideally testing with disabled users.
Sitecheck runs axe-core and QualWeb, both open-source implementations of the WCAG success criteria, so results map to named criteria rather than a score someone invented. It will find the automatable portion honestly and will not pretend to cover the rest.
Accessibility and SEO overlap
A large share of accessibility work improves SEO as a side effect, because both depend on machine-readable semantics:
- Proper heading structure serves screen reader navigation and content understanding alike.
- Alt text describes images to assistive technology and to image search.
- Descriptive link text ("2026 pricing guide" rather than "click here") helps both.
- Captions and transcripts make video content indexable as well as accessible.
- Semantic HTML gives both crawlers and assistive technology the same structural map.
They are not the same discipline and accessibility is worth doing for its own sake — but the overlap is real and worth using when arguing for the work.
The legal picture
Most accessibility law does not write its own technical rules; it points at WCAG.
- EU — the European Accessibility Act (Directive 2019/882) has applied since 28 June 2025, extending requirements to a wide range of private-sector products and services including e-commerce, banking, and transport. The harmonised standard is EN 301 549, which incorporates WCAG 2.1 level AA.
- EU public sector — the Web Accessibility Directive (2016/2102) has required WCAG 2.1 AA of public sector bodies since 2019, with a published accessibility statement.
- United States — Section 508 references WCAG 2.0 AA; ADA litigation in practice uses WCAG 2.1 AA as the benchmark.
- United Kingdom — the Equality Act 2010 plus public sector accessibility regulations.
If you operate in the EU, the practical summary is short: WCAG 2.1 level AA, and it already applies.