What is different about buying accessibility monitoring for many sites instead of one?

Three things that do not appear in a single-site evaluation. First, tenancy: whether the platform models an estate as separate workspaces with their own permissions and their own scores, or as one giant page list with tags, which is what most tools designed for a single property actually offer. Second, the pricing unit, because a per-page or per-scan unit that is trivial on one site becomes the dominant cost line across forty. Third, the rollout, which is an organisational problem rather than a technical one — the properties are usually owned by teams who do not report to whoever signed the contract.

Should every brand get its own score or should we report one number?

Both, and they serve different readers. Each property team needs its own list, its own trend and its own backlog, because a shared queue makes every item somebody else's problem. The centre needs a roll-up, but the roll-up should be a portfolio view — how many properties are improving, how many are untouched, where the concentration of critical issues sits — rather than an average score, which is a number that can improve while your worst site gets worse. Check whether the platform can produce both without you exporting to a spreadsheet every month, because if it cannot, someone will stop doing it by quarter two.

How should we price-model a platform across many properties?

Take your actual estate — total URLs, how many of them are template duplicates, how often each property ships, how many people need logins — and ask each vendor to quote against those numbers for a three-year horizon including expected growth. Per-page pricing punishes catalogue and news sites that generate URLs mechanically. Per-scan pricing punishes teams that want scans in CI, which is the behaviour you are trying to encourage. Per-seat pricing punishes the federated model where thirty brand owners each need to see their own list. The right unit is the one that does not tax the behaviour you want more of.

Do agencies and franchises need something different again?

Yes, on two axes. Data separation has to be real, because one client seeing another client's findings is a commercial incident, so look for genuine workspace isolation rather than tag-based filtering. And the reporting has to be presentable to a third party without manual rework — white-labelled or at least neutral PDF and link output, per-client. Franchise estates add one more: the franchisor typically cannot compel a franchisee to fix anything, so the platform's job shifts toward evidence and notification rather than enforcement, and the useful feature is per-property alerting to an owner who is not you.

Should we roll out to every property at once?

No. Onboard the properties with the highest traffic or the highest legal exposure first, get one of them to a visible improvement, and use that as the internal case for the rest. A simultaneous rollout produces forty untriaged backlogs, which reads to every property team as a centrally imposed chore with no support attached, and that impression is very hard to reverse. Sequence it so that each wave has someone who can help the team read their first report, and expect the whole estate to take two to four quarters rather than a month.

How do multilingual and regional sites affect the choice?

More than teams expect. Some automated checks are language-aware — page language declaration, language-of-parts, readability heuristics, and alt-text quality suggestions — and a scanner that assumes English will either miss failures or raise false ones across your regional properties. Check that the crawler handles your locale routing, whether that is subdirectories, subdomains or country domains, without counting each locale as a wholly separate site for pricing. And if any of your regions are in the EU, the regional properties are the ones most likely to sit under EN 301 549 procurement expectations, which is a different reporting need from your US storefront.

Choosing an Accessibility Platform for Multi-Brand and Multi-Site Estates (2026)

Tenancy Is the First Fork, and It Is Usually Discovered Late

Ask one question in the first demo: show me two properties owned by two different teams who cannot see each other's findings. The answers divide the market cleanly. Some platforms model an estate natively — a workspace per property, its own users, its own baseline, its own trend, with a roll-up above it. Others model one site and then retrofit an estate as a single enormous URL list with tags, filters and saved views.

The tagged model demos beautifully and fails in month three for a reason that is organisational rather than technical. A shared list has no owner, so every item in it is somebody else's problem. A property team that opens the tool and sees eleven thousand findings across the whole company does not find their forty; they close the tab. The same team, given a workspace containing only their site and only their forty items, behaves completely differently. If your estate is more than a handful of properties with genuinely separate owners, treat real tenancy as a requirement rather than a preference.

The Pricing Unit Decides What Your Teams Stop Doing

On a single site the pricing unit is a line item. Across an estate it is a policy, because whatever the unit is, someone will economise on it — and the thing they economise on is usually the thing you were trying to buy.

Per URL punishes the properties that generate pages mechanically — catalogues, news archives, location pages, faceted navigation. The response is sampling, and sampling is fine as long as it is a deliberate choice about templates rather than an accident of budget.
Per scan or per run punishes frequency, which means it punishes putting a check into CI — the single highest-leverage place to put one, because it catches the regression before it ships to forty sites sharing a component library.
Per seat punishes the federated model. If thirty brand owners each need to see their own list and a seat costs real money, you will end up with four central seats and twenty-six people who receive a PDF, which is the arrangement that produced no fixes at your last employer either.
Per property, flat is the friendliest unit for an estate and the rarest. Where it exists, check what counts as a property — a locale subdirectory sometimes counts as one.

Model it with your real numbers over three years, including the acquisition you know is coming. The vendor that is cheapest at today's page count is frequently not the one that is cheapest at the count you will have when the contract renews, and renewal is the moment when a pricing unit that punishes growth turns into a bill nobody budgeted.

The Rollout Is an Org Problem Wearing a Tool Costume

The contract is signed centrally. The fixes happen in teams that do not report to the signer, on roadmaps that were set before anyone mentioned accessibility, often at agencies who will quote for the work. This is the part of an estate programme that actually determines whether anything improves, and no feature comparison addresses it.

What works is unglamorous. Start with two or three properties chosen for traffic or exposure rather than for enthusiasm. Give each of them a real person for the first report — most teams have never read one and the first reaction to four hundred findings is despair rather than action. Get one property to a visible, dated improvement, and use that as the internal artefact for the next wave. A big-bang rollout to the whole estate produces forty untriaged backlogs and a company-wide impression that this was a central mandate with no help attached.

One structural shortcut is worth more than any amount of governance: if your properties share a design system or a component library, fix it there. A single mislabelled control in a shared header is one fix and forty sites of improvement, and it is the only lever in an estate programme with that ratio. Ask each vendor how it would show you that a finding recurs across properties, because the tools that can group by component rather than by URL make this obvious and the ones that cannot will bury it.

Do Not Average the Score

The most common reporting mistake in an estate programme is a single portfolio score. It can rise while your most exposed property gets worse, it hides the untouched sites behind the well-run ones, and it gives an executive a number that is comfortable and uninformative. Report a distribution instead: how many properties have been scanned at all, how many are improving quarter on quarter, how many have unresolved critical issues older than ninety days, and which three carry the most traffic-weighted risk.

Traffic weighting is the part that changes decisions. Forty sites are not forty equal risks — one of them probably carries most of your visitors and most of your complaint surface, and a portfolio view that treats it the same as a regional microsite will send your remediation budget to the wrong place.

A Shortlist Test That Only Takes an Afternoon

Give every finalist the same three properties from your real estate — ideally your largest, one on a different stack, and one in another language — and ask for the same deliverables: a per-property view, a roll-up, and a demonstration that team A cannot see team B. Then check the four things that decide the next three years.

Can it reach the properties that sit behind a login, a bot filter or a geo-redirect?
Does a finding leave the platform into whatever the property team actually uses — their tracker, not yours?
Does the pricing unit match how your estate grows, at the count you will have in three years?
Can it show the same defect recurring across properties, so the component-level fix is visible?

Questions Estate Owners Ask

We inherited sites on six different stacks. Does that constrain the tool choice?

Less than you would think for scanning and more than you would think for fixing. A browser-based crawler does not care what rendered the HTML, so detection is broadly stack-agnostic. Where the stack matters is the remediation path and the CI integration: a platform whose value is concentrated in a framework plugin or a CMS app is worth much less across a heterogeneous estate than one whose value is in a CLI and an API that any pipeline can call. Weight portability over any single deep integration.

Should we standardise the estate on one platform or let brands choose?

One platform, for a reason that is about evidence rather than efficiency. Scores are not comparable across vendors — different engines, sampling and severity weighting produce different numbers on the same site — so a federated tool choice makes your portfolio view meaningless and makes any cross-property trend unprovable. Let brands own their backlog and their schedule; do not let them own the measuring instrument.

How do we handle properties an agency builds and maintains?

Put the requirement in the agency contract rather than in the platform. Name the standard, require that the property is onboarded to your platform at launch, and make a clean scan a deliverable of the build rather than a remediation project afterwards — retrofitting is several times the cost of getting it right at build time. Give the agency a scoped workspace so they can work the list directly, and keep the account ownership with you so the history survives a change of agency.

What does a realistic first year look like across forty properties?

Quarter one: contract, onboard three to five properties, produce one visible improvement. Quarter two: extend to the properties carrying the most traffic, and find the shared components behind the most repeated findings. Quarter three: fix at the component or design-system level and watch the count fall across multiple properties at once. Quarter four: the long tail, where the constraint is attention rather than tooling. Anyone promising the whole estate in a quarter is selling you a scan, not a programme.

Our locales are separate country domains. Will that multiply our cost?

Ask explicitly, because the answer varies and it is rarely on the pricing page. Some vendors count a country domain as a distinct site with its own subscription; some treat locale variants of the same templates as one property. On a heavily localised estate this single definition can change a quote several-fold. Get it in writing with your actual domain list attached, not as a general assurance.

Is a single portfolio score ever the right thing to report?

As a headline for people who will never open the tool, with the distribution immediately underneath it, and never as the only number. The failure it creates on its own is real: an average improves when your well-resourced properties improve, which is exactly the situation in which your worst-performing and most-exposed site is being ignored. If an executive wants one number, make it coverage — the share of properties scanned and triaged — which cannot be gamed by your best sites getting better.

Start With One Property, Measured Neutrally

Before you model a forty-site contract, take an independent reading of the property that carries the most traffic. It tells you what the estate's real backlog shape probably is — and it gives you a dated reference point that belongs to you rather than to whichever vendor you end up signing.

Then run every finalist against the same four structural lines: can it reach the hard properties, can a finding become a ticket in someone else's tracker, does the pricing unit match how your estate grows, and can it show you the one shared component that is failing on all forty sites at once.