WCAG measures one thing, and it is not your website. It measures the web page, which the standard defines as a non-embedded resource obtained from a single address, plus every other resource used in rendering it or meant to be rendered along with it. Conformance is claimed for pages. A site never conforms, because the standard offers no mechanism by which it could.
That reads like a technicality right up until you meet the case most people arrive with. A single-page application, where the whole product lives at one address and swaps its screens in place, is one web page under this definition. W3C says so using its own worked example. And once that lands, the requirement about whole pages does something uncomfortable to any claim you were planning to make.
The definition stretches in the other direction too. Images, media, stylesheets and the content your scripts fetch twenty seconds after load are all part of the page. So is a long description sitting at its own address, as long as the page links to it. So is every layout the page presents at every screen width. A web page in WCAG is a conformance construct rather than a URL, and the distance between those two ideas is where most scoping arguments actually live.
The Definition, and the Three Parts That Carry It
The whole definition is one sentence, and each part of it decides real cases.
- Non-embedded. A resource has to be non-embedded within your scope of conformance to count as a page at all. So the document inside an iframe is not a page of its own for your purposes. It is part of yours, which is why an embedded booking widget, a chat bubble or a consent banner belongs to the page that hosts it.
- Obtained from a single address. This is the anchor, and it is the part that decides the single-page application question. One address, one page.
- Plus any other resources rendered together with it. This sweeps in the images, the media, the stylesheets, the scripts, and anything those scripts load later. It is the reason a page is never just the markup that arrived first.
One note attached to the definition does more work than its length suggests. Those other resources are rendered together with the primary one, and the standard adds that they would not necessarily be rendered at the same time as each other. So content that appears only after somebody opens a panel, switches a tab or scrolls far enough to trigger a load is still part of the same page. Nobody ever sees all of it at once, and all of it counts.
Why a Single-Page Application Is One Page
W3C answers this directly, and the answer is sitting in the definition's own examples rather than buried in commentary. The second example describes a web mail program built with AJAX. It lives entirely at one address, it contains an inbox, a contacts area and a calendar, and links or buttons cause each of those to display without changing the address of the page as a whole. It is given as an example of a web page. Singular.
The other three examples run the same way and widen it further. A plain resource with its embedded images and media. A customizable portal where visitors choose which content modules to display, which establishes that user-selected content is still part of the one page. And an interactive shopping environment you move around inside, which W3C closes by saying it might be a single-page website or just one page within a website. So the example set ends by admitting the boundary is judged rather than computed.
Now the case the definition does not name, because it did not exist in this form when the wording was written. Most modern applications route. The framework writes a distinct address for each view, the address changes as you move, and entering any of those addresses directly returns that view. Each one is then a non-embedded resource obtained from a single address, which is the definition's own test, so each one is its own page. W3C has not published that as a position. The test it gives produces that answer.
The question that settles it in about ten seconds
Open a deep part of your application. Copy the address out of the bar, paste it into a fresh window and press Enter. If you land where you were, that view has its own address and is its own page. If you land on the home screen instead, it does not, and everything you can reach without the address changing is part of one single page for conformance purposes. Run that test on the three or four screens that matter most and you have your unit.
What Happens to a Failing Screen Inside One Page
This is where the unit stops being trivia. The second of the five conformance requirements is called Full pages, and it says conformance is for full pages only and cannot be achieved where part of a page is excluded. W3C restates it plainly in the guidance. Statements about part of a page conforming cannot be made.
Put those two things together and the result follows on its own. If your application is one page, then a broken settings screen inside it is not a failing page sitting in an otherwise passing site. It is a failing part of the single page, and under the Full pages requirement, that page does not conform. There is no version of the claim that quarantines the bad screen, because the standard does not offer a way to exclude part of a page from a claim.
The reverse is also worth saying, because it is the more cheerful half. Where every view has its own address, you are looking at many pages, and conformance is judged one at a time. A failing screen is then one failing page rather than a fault that spreads across the whole product. Same code, same bug, different consequence, and the only thing that changed is whether your router writes to the address bar.
Every Responsive Layout Is Part of the Same Page
A full page includes each variation the page presents automatically at different screen sizes, and the standard is explicit that every one of those variations has to conform, or carry a conforming alternate version, for the page as a whole to conform.
Notice what that does and does not say. Your breakpoints are not separate pages. They are folded into the one page, and all of them have to hold up before that page passes. The effect on scope is identical either way, and the mechanism matters when somebody argues about it, because you cannot pass a page by testing whichever layout happens to look best. A menu that traps focus below 768 pixels is a failure of the page, not of the phone.
This is why our own audit method carries desktop-only testing as a stated limit rather than burying it. Testing one layout tests part of a page, and part of a page is not a unit the standard recognizes.
A Long Description Somewhere Else Still Belongs to This Page
The boundary runs the other way as well, which is the clearest proof that the unit is a construct rather than an address. Where a graphic links out to a longer description held on a separate page, W3C treats that content as part of the web page it came from, and the Full pages requirement is satisfied for the combined set considered as a single page.
So a page can pull in content from another address and still be one page. It can hold content nobody sees at the same time as the rest. It can present four different layouts. And it can contain an embedded third-party document that is not a page in its own right. The address is where the definition starts and it is not where the page ends.
Sets and Processes Are Different Units Again
Two other units sit alongside the page, and mixing them up produces most of the confusion in audit reports. Neither replaces the page. Both are built out of pages.
A set of web pages is a collection sharing a common purpose and created by the same author, group or organization, and both halves have to hold. Five success criteria are judged across a set rather than a page, which is why they cannot be tested by reading one page carefully. Different language versions count as different sets.
A complete process is a series of pages presenting a sequence of steps somebody has to finish to get something done. Conformance across it is all or nothing. Every page conforms at the level claimed, or none of them does, and that holds at A, AA and AAA alike.
The interaction with the application question is neat, and it cuts the same way whichever architecture you chose. A checkout built with an address per step is a series of pages presenting a process, so the all-or-nothing rule applies in the ordinary way. A checkout built at one address with steps swapped in place is a single page, so there is no series for that rule to reach, and the Full pages requirement does the work instead by demanding that the whole page conform with every step included. Two routes, one destination. There is no way to build a checkout where the failing step can be set aside.
What This Does to a Site-Wide Claim
A conformance claim can cover more than one page. That is allowed and it is common. What it cannot do is cover pages nobody checked, because the claim is assembled out of per-page conformance and holds only where every page inside it was evaluated, or produced by a process that guarantees each one passes.
W3C's own evaluation methodology draws the conclusion for you. A conformance claim cannot be made for an entire website on the strength of a sample of its pages, because there is always a chance an unexamined page carries an error. So the sentence people want, that their site is AA, is available only when every page inside the claim has actually been through it. For most sites that is not what happened, and the honest version names the pages instead.
How to Count the Pages on Your Own Site
Four steps, and the whole thing takes an afternoon on most sites.
- Run the address test on anything that behaves like an application. Deep-link into it from a fresh window. If the view comes back, it is a page. If it does not, everything reachable without an address change is one page together.
- Fold in what the page loads later. Panels, tabs, drawers, lazy-loaded sections and anything a script fetches after the first render. All of it belongs to the page it appeared in, whether or not it was visible when the tester arrived.
- Fold in every layout. Each variation the page presents automatically at a different width is part of the same page, so a page is not tested until its layouts are.
- Draw the processes separately. Checkout, sign-up, booking, application. List the steps end to end, including the branches people commonly take, because those steps are judged together whatever the addresses say.
The one sentence to take away
The unit is the page, and the page is defined by its address plus everything rendered with it, so an application at one address is one page and a routed application is many. Get that decision right first, because what your conformance claim can say is built on top of it, and no amount of testing later fixes a claim that was scoped against the wrong unit.