Scope a logged-in product in roles, states and tasks, not in addresses. That is the whole answer, and the reason is mechanical rather than stylistic. W3C's evaluation methodology says outright that for a page inside a process, the web address will usually not be enough to identify the sample. The evaluator has to record the actions needed to get from one step to the next. Behind a login, almost everything is inside a process.
That single fact reshapes the quote. A marketing site can be scoped from a sitemap because a URL and a page are close to the same thing there. In an application, one address can be six different screens depending on who signed in, what they have already done, and whether the last request failed. Counting addresses in that setting produces a number that means nothing, which is why an audit quoted from a URL list usually arrives wrong.
What to have ready before you ask for a price
Three lists and one arrangement. The roles a person can hold in your product. The tasks that matter enough that a customer leaving means real money or a real duty unmet. The states those tasks pass through, including the empty and broken ones. And a way for a tester to get in, which is a test account with realistic data in it, arranged after scope is agreed rather than sent in an enquiry form.
Why a Role Is a Different Product Rather Than a Different View
Start with roles, because a permission model is the largest multiplier in the whole exercise and the one most likely to be left out. An administrator sees controls a standard user cannot reach, and those controls are often the newest and least reviewed part of the interface. A read-only viewer meets disabled buttons, empty action menus and permission messages that may not announce themselves at all. A support agent operating on somebody else's account sees a screen nobody designed as carefully as the customer's own.
The methodology backs this up from an unexpected direction. Among the factors that make a sample set larger, it names products available in different versions or served according to users and their preferences. A permission model is exactly that, and it means a product with four meaningful roles needs a bigger sample than a product with one, at the same page count.
So the first question in scoping is not how many screens you have. It is how many genuinely different products your one codebase serves, and which of them you want evidence about. Picking two roles out of five is a completely reasonable answer. Picking two and then describing the result as covering the application is not.
The States a Task Passes Through, Including the Ones Nobody Demos
Once the roles are settled, each task has to be walked through its states, and this is where an audit finds the failures that actually stop people. A form that is faultless when it succeeds can be unusable when it fails. The error message gets painted in red text, with no programmatic association to the field it belongs to and no announcement when it appears.
The methodology has a related instruction it applies to processes, and it transfers straight across. Record the default route through the task first, the one assuming no mistakes and no unusual choices. Then record the branch routes people commonly take that matter to finishing, and include those too. In an application, the branches are where the interesting failures live.
- Empty. A new account with no data. Zero states are usually the least designed screens in a product and often the least announced.
- Populated. Realistic volume, because a table with four rows and a table with four hundred are different components once virtualisation kicks in.
- Error. Every validation path, every failed request, every conflict. Not the happy path with a red border added.
- Blocked. What a role that lacks permission actually meets, and whether the reason reaches a screen reader or only the eye.
- Expired. Session timeout, and what happens to work in progress when it fires. This one is a Level A criterion with a short list of exceptions rather than a nicety.
The Roles, States and Access Worksheet
Written out, the whole scoping conversation fits in one grid. Fill this in for your own product before you ask anyone for a number, and the quote you get back will describe work you recognise. The example rows below are illustrative, drawn from a generic team-workspace product rather than from any client.
| Role | Task in scope | States to cover | Access needed |
|---|---|---|---|
| Owner | Invite a colleague and set their permission | Empty team, invite sent, invite failed, seat limit reached | Owner account on a plan with seats left, plus one at its limit |
| Owner | Update billing details | Card valid, card declined, session expired mid-form | Sandbox billing, no live charge |
| Member | Create and share a document | Empty, populated, share link error, permission denied | Member account with seeded documents |
| Read-only viewer | Open a shared document | Blocked actions, disabled controls, permission message | Viewer account on the same seeded workspace |
| Support agent | View a customer account | Impersonation banner, restricted fields, audit warning | Internal role, or an explicit decision to leave it out of scope |
The last row is deliberately awkward, because internal tooling is the thing most often discovered halfway through. Deciding it is out of scope is fine. Discovering on day four that it was never in scope, after your team assumed it was, is the outcome the grid exists to prevent.
Getting a Tester In, Safely and Without Sending Credentials
Access is a scoping question rather than an administrative afterthought, and the methodology treats it that way. Its exploration step carries a note saying it is critical that the evaluator can reach all relevant parts of the product. It may be necessary to create an account, and to make sure the configuration is representative. Where a product displays data, the note adds, it may be necessary to pre-fill realistic data before the evaluation starts.
That last clause is worth reading twice, because an empty demo tenant is a documented failure of representativeness rather than a convenient shortcut. Testing a dashboard with no data in it tells you about the empty state and nothing else, and the empty state is not what your customers spend their day in.
The practical arrangement is boring and should stay that way. Credentials never travel through a public form, which is why our own order form says in the field itself not to put passwords there and asks for access separately once scope is confirmed. A named test account per role, seeded with synthetic data that looks like the real thing, is the arrangement that works. Where a role can only be reached with an internal tool, that gets said out loud during scoping rather than discovered later.
What we do not claim about your environment
Working inside your product is an access arrangement, agreed in writing between us and set out in whatever your organisation requires. It is not a security assessment, a penetration test, or any form of certification about how your data is handled, and nothing on this page should be read as one. If your compliance team has requirements about accounts, recording or data residency, raise them during scoping so the arrangement can be written to match them, or so we can tell you it is outside what we do.
Intranets and Employee Portals, Where the Baseline Narrows
An internal system is the same scoping exercise with two differences, and one of them is unusually helpful. The unhelpful one first. Nothing on an intranet is reachable by a crawler, so there is no automated pass to clear the flat facts before a person starts. Our own scanner refuses private ranges, non-standard ports and internal hostnames by design. Everything has to be tested by hand, which changes what an equivalent scope costs.
The helpful difference is the support baseline. WCAG's definition of accessibility support accepts, as one of its four routes, content available in a closed environment such as a university or corporate network where the user agent the organisation uses is itself accessibility supported. The methodology says the same from the other side, that for a product in a closed network where both users and machines are known, the baseline may be limited to what is used inside it.
That is a real saving and an honest one. If every machine in the building runs one managed browser and the assistive technology your organisation licenses, the matrix that would be irresponsible on a public site is exactly right here. It also means the resulting evidence is about that environment, so the day the portal opens to contractors on their own devices, the baseline you agreed no longer describes your users. Our guide to which browsers and screen readers to test covers how that list gets built, and how it gets widened.
Where This Page Stops
One boundary is worth naming precisely, because internal systems bring it up every time. A duty owed to a disabled employee who cannot use an internal tool is an employment question, and it is answered by different law from the one covering your public website. It can require an individual accommodation in circumstances where no conformance level would have settled it, and it can bite whether or not the portal was ever in anybody's audit scope.
This page is about scoping a technical evaluation, so it stops there. What that duty is, whether it reaches your organisation, and what discharging it requires are questions for an employment lawyer in your jurisdiction. Our guide to accessibility at work is the closest thing here to a starting point. Send the roles, the tasks and the states, and the scope conversation can start from something concrete.