WCAG 2.2 Demo SuiteStep 1 — Define the scope of the evaluation
Everything in an audit is disputed later on the basis of this step. Write it down before you look at a single page, and get the client to agree it.
1a. Define the website
"The website" sounds obvious and never is. Decide, in writing:
- Which domains and subdomains are included. Does
shop.example.orgcount?blog.example.org? - Whether authenticated areas are in scope — and if so, whose account you will use.
- Whether third-party embedded content is in scope: payment iframes, maps, chat widgets, embedded video. You usually cannot fix these, but they still affect the user, so they must be reported even when they are excluded from the conformance claim.
- Whether documents (PDF, Word, spreadsheets) are included. They are part of the web page's content if you link to them.
- Whether the mobile app is included. It is not a website, and WCAG-EM does not cover it.
Partial scope is allowed, but must be honest
You may evaluate part of a site — "the checkout process" or "the public help centre" — as long as the boundary is defined by a URL structure and stated clearly. What you may not do is evaluate a convenient subset and then describe the result as being about the site.
1b. Define the conformance target
State the level and the version: WCAG 2.2 Level AA is the normal answer, and what most legislation and procurement policy requires.
- Level A alone is rarely an acceptable target for a public service.
- Level AAA should not be a blanket target. W3C says explicitly that it is not possible to satisfy all AAA criteria for some content. Adopt individual AAA criteria where they fit — 1.4.6 Contrast (Enhanced) is usually affordable — and say which ones.
- Note whether you are additionally reporting against EN 301 549 or Section 508, which wrap WCAG with extra clauses.
1c. Define the accessibility support baseline
WCAG requires that the techniques you rely on are "accessibility supported" — which the standard deliberately does not define, because support changes constantly. So you define it, and you list it.
A typical baseline:
| Platform | Browser | Assistive technology |
|---|---|---|
| Windows | Chrome (latest) | NVDA (latest), JAWS (latest) |
| Windows | Firefox (latest) | NVDA (latest) |
| macOS | Safari (latest) | VoiceOver |
| iOS | Safari | VoiceOver |
| Android | Chrome | TalkBack |
| Any | Any | Keyboard only; 400% zoom; Windows High Contrast |
This matters practically: a technique that works in JAWS and fails in NVDA is a failure if NVDA is in your baseline, and a footnote if it is not.
1d. Additional requirements
Record anything beyond WCAG that the evaluation must consider — an organisational style guide, a plain-language policy, a legal deadline, a procurement clause.
Common mistakes at this step
- Leaving "the website" undefined and discovering mid-audit that the client meant something different.
- Not agreeing whether third-party content is in scope, then arguing about it in the report.
- Omitting the baseline, so every finding can be answered with "it works in my browser".
- Accepting "make it accessible" as a target instead of a named level.