A set of web pages is a collection of pages that share a common purpose and are created by the same author, group or organization. Both halves have to hold. That is the whole definition, and it is the unit five WCAG rules are measured against, which means those five cannot be judged by reading one page carefully. They are judged by opening several pages side by side and comparing them.
The reason this matters commercially is that the boundary rarely falls where people assume. A checkout that strips the site navigation is usually a different set from the product pages it came from. A blog on a subdomain written by different people is a different set again. A translation is always separate from the original. Each of those boundaries decides whether an inconsistency you have just found is a failure or a design choice.
The Five Rules That Are Judged Across a Set
Exactly five success criteria use the term in their binding text. Four of them are about consistency and one is about orientation, and none has an automated test rule behind it, so all five arrive in an audit through a person comparing pages.
| Rule | Level | What it compares across the set |
|---|---|---|
| 2.4.5 Multiple Ways | AA | Whether there is more than one route to any page in the set, with an exception for pages that are a step in or the result of a process |
| 2.4.8 Location | AAA | Whether a reader can tell where in the set they currently are |
| 3.2.3 Consistent Navigation | AA | Whether repeated navigation keeps the same relative order everywhere it appears |
| 3.2.4 Consistent Identification | AA | Whether components that do the same job are identified consistently |
| 3.2.6 Consistent Help | A | Whether help, where it exists, sits in the same place in the page order |
Two of those five are worth reading twice. Multiple Ways carries an exception that removes every checkout step, every order confirmation and every search results page from its scope, because a page that is a step in or the result of a process is exempt. And Consistent Help never asks you to provide help in the first place, so help being absent from a page is a business problem rather than a failure.
The Three Worked Examples, and the One That Reverses Expectations
The definition comes with three worked examples, and they do more work than the definition itself, because each one draws a boundary somewhere a reasonable person would not have drawn it.
- A publication split across pages is one set. Each page holds a chapter, the work is a single continuous thing, and there is navigation that reaches every page of it. This is the case where a set looks exactly like a set.
- A shop is at least two sets. The product pages share navigation and identification and form one set. Then the checkout arrives, the template changes, the navigation and other elements are removed, and those pages are functionally and visually different. The example states its conclusion in terms, which is that the checkout pages are not part of the set of product pages.
- A blog on a subdomain can be its own set, where it has different navigation and is written by a different group of people from the main site. Same brand, same company, two sets.
A note under those three adds the boundary with the widest reach. Different language versions are considered different sets of web pages. So an English site and its French translation are two sets, each of which has to be internally consistent, and an inconsistency between them is not a failure of any of the five rules.
Why help disappearing at checkout is not a 3.2.6 failure
This is the finding we see reported most often against Consistent Help, and it is wrong three times over. The rule is about the order a help mechanism occupies when the page is serialized, not its position on screen. The rule only applies to pages that carry help at all, and the guidance says outright that the absence of a help mechanism on some pages within a set is not a violation. And a checkout that drops the site template is the standard's own example of a separate set, so there is nothing to be consistent with. Losing your support link at the moment a customer is holding a card is still a bad idea. It is not this rule.
How to Draw the Boundary on Your Own Site
There is no procedure published for this, so what follows is how we scope it before an audit. It errs towards fewer, larger sets, because a large set is the harder test and passing it satisfies any smaller reading.
- Start from purpose. Group pages by what a reader is there to do. Browsing and buying are different purposes. Reading the marketing site and using the application behind the login are different purposes.
- Split on authorship. Where a section is written and maintained by a different team, or by a supplier, that is a second condition failing and a strong signal of a second set.
- Split where the template changes. The checkout example turns on the navigation and other shared elements being removed. A page that looks and behaves like a different product usually is one.
- Split every language version. This one is not a judgment call. The note says different language versions are different sets.
- Write the boundaries down before you test. The set you assumed is the set your findings are measured against, and a disagreement about scope after the report lands is much more expensive than a paragraph before it.
One caution on the third step. If your checkout keeps the site header, the navigation and the footer, it is plausibly still the same set, and the defense above stops applying. The published example describes a checkout that strips those things, not every checkout that exists.
What Consistency Actually Requires Inside a Set
Two words in these rules do less than teams expect, and knowing that prevents a great many false findings.
Same relative order does not mean same position. It means the same position relative to the other items, and WCAG says explicitly that items may be inserted or removed without breaking it. An expanding menu that adds a level of detail is fine. A secondary navigation block inserted into the reading order is fine. A search field that is the last item on every page is fine, because last is a position too, as long as it is always last.
Consistent does not mean identical, and the guidance makes this point four separate times, which is a good sign of what people get wrong. Links reading page 2, page 3 and page 4 are consistent. A printer icon labeled Print receipt in one place and Print invoice in another is consistent, because the labeling pattern holds and the functions genuinely differ. The failure is two different names for the same function, which is the search button called find somewhere else.
The version of that failure a visual review will never catch is two buttons that look identical, carry the same visible text, and have been given different accessible names through aria-label. To a sighted reader they match. To a screen reader they are two different controls. It is listed as a failure primarily affecting assistive technology users, and it is the reason a consistency pass has to read the accessibility tree rather than the page.
Conformance Is Still Judged One Page at a Time
These two ideas sit awkwardly together and both are true. The rules are evaluated across a set, and the unit of conformance in WCAG is a single page. A page can read perfectly on its own and fail because of what the pages around it do, and the failure is still recorded against that page.
That is what makes these five rules expensive to fix late and cheap to fix early. A naming inconsistency found across forty product pages is one component with the wrong label in it, and the same forty findings collapse into a single change. It is also why sampling has to be structured. Auditing ten pages that all render from the same template tells you almost nothing about a set, because you tested one template ten times.
What a scanner tells you about any of this
Nothing again, and this time it is all five. There is no published test rule for Multiple Ways, Location, Consistent Navigation, Consistent Identification or Consistent Help, which is unsurprising when the question is whether two pages agree with each other and a scanner is looking at one page. A tool can tell you a search box exists. It cannot tell you the search box misses half your catalog, and that is the failure we actually find.