WCAG, the Web Content Accessibility Guidelines, is the international technical standard for making web content usable by people with disabilities. For most business websites the practical target is Level AA of the current version, WCAG 2.2. This article explains how the standard is organised, what conformance actually requires and how to turn it into a manageable work plan.
What WCAG is and how it is organised
WCAG is developed through the W3C process. According to the W3C WCAG overview, WCAG 2.2 has 13 guidelines grouped under four principles: perceivable, operable, understandable and robust. Each guideline has testable success criteria, and each criterion is assigned a level: A, AA or AAA.
The four principles translate into everyday questions:
- Perceivable: can people see or hear the content in some form? Think alt text, captions and colour contrast.
- Operable: can people use every control without a mouse or fine motor precision? Think keyboard access and target size.
- Understandable: is the content and behaviour predictable? Think clear labels, consistent navigation and helpful form errors.
- Robust: does the code work with assistive technology such as screen readers?
Conformance levels in plain terms
The W3C conformance guidance explains that each level includes the lower ones, so AA means meeting every Level A and Level AA criterion. Level A is the minimum. The guidance also says that choosing a level is a policy decision and advises against requiring AAA for an entire site, because some content cannot satisfy every AAA criterion.
| Level | What it means | Typical business use |
|---|---|---|
| A | Minimum baseline | Always required as part of AA |
| AA | All A and AA criteria met | The common target for business sites |
| AAA | Highest, not achievable for all content | Applied selectively, for example to key forms |
Conformance also applies to whole pages, not fragments. Every page in a multi-step process such as a checkout must meet the claimed level, so a single inaccessible payment step breaks the claim for the journey.
What changed in WCAG 2.2
WCAG 2.2 became a W3C Recommendation on 5 October 2023, with an update in December 2024. It added nine success criteria and removed one, 4.1.1 Parsing, which is obsolete. The W3C summary of what is new lists the additions. The Level AA ones matter most for business sites:
- Focus Not Obscured (Minimum): a focused element must not be fully hidden, for example by a sticky header or cookie banner. See keyboard navigation and focus states.
- Dragging Movements: anything done by dragging needs a simple pointer alternative.
- Target Size (Minimum): clickable targets need a minimum size.
- Accessible Authentication (Minimum): logging in must not depend on a cognitive test such as remembering or transcribing something, unless an alternative exists.
Level A additions are Consistent Help and Redundant Entry, which stops forms asking users to re-enter information they already gave.
Content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0, according to the W3C overview, so there is no reason to build to an older version.
The Australian context
In Australia, the Disability Discrimination Act 1992 is the law that governs discrimination against people with disability, including in the provision of goods and services. The Australian Human Rights Commission has published guidance linking web accessibility to that Act and to WCAG. How it applies to a particular organisation depends on its circumstances, so treat this article as general information, not legal advice, and seek professional advice if you have a specific obligation or complaint. Government agencies and some larger organisations have additional requirements.
A practical scoping plan
- Pick the target. Declare WCAG 2.2 Level AA for new work.
- Audit the templates, not every page. Header, navigation, article, form, search, checkout and footer cover most of the problems because they repeat.
- Fix the high-impact failures first: keyboard traps, missing form labels, low contrast text and missing alt text.
- Combine automated and manual testing. Automated tools catch a subset of issues. Keyboard-only walkthroughs and a screen reader pass catch much of the rest. Our guides on colour contrast and keyboard navigation cover two of the most testable areas.
- Build it into the process. Add accessibility checks to design reviews and to the definition of done, so new pages do not reintroduce old faults. Accessibility also tends to support conversion because clearer forms and readable text help everyone.
- Publish contact details for accessibility problems and respond to them.
Limits to keep in mind
Meeting WCAG does not guarantee that every person can use a site, and WCAG itself is aimed at technical audiences. Third-party embeds, PDFs and booking widgets are still your responsibility to check. A one-off audit decays as content changes, so schedule re-checks.
Where Radiance Impact fits
Radiance Impact’s Technology division builds and redesigns business websites, and accessibility is a sensible part of the brief. If you are planning a build or a redesign, get in touch or see the Technology page.
Sources
- WCAG Overview, W3C Web Accessibility Initiative
- What’s New in WCAG 2.2, W3C Web Accessibility Initiative
- Understanding Conformance, W3C Web Accessibility Initiative
