Organizations that operate multiple websites or web apps need a structured approach to accessibility for each domain. A single audit report or ACR does not cover your entire digital portfolio. Each domain requires its own evaluation, its own WCAG conformance tracking, and its own remediation workflow.
The core principle: treat every domain as a separate accessibility project. Shared templates and components can speed things up, but conformance is always assessed per domain.
| Consideration | What to Know |
|---|---|
| Conformance Standard | WCAG 2.1 AA or WCAG 2.2 AA per domain |
| Audit Scope | Each domain is scoped and evaluated independently |
| ACR Coverage | One ACR per product or domain, not one for all |
| Shared Components | Fix once in the design system, verify on each domain |
| Tracking | Separate issue tracking per domain with centralized visibility |
Why Each Domain Needs Its Own Audit
A (manual) accessibility audit evaluates the specific pages, components, and interactions of a single digital asset against WCAG criteria. Two domains under the same brand can have completely different templates, functionality, and third-party integrations. An audit of one does not apply to the other.
Even if two sites share a design system, the way components render, the content authors populate fields, and the third-party scripts loaded on each domain create different accessibility profiles. An auditor evaluates what is actually present on each domain, not what the shared codebase theoretically produces.
Do You Need a Separate ACR for Every Domain?
Yes. A VPAT is the template. An ACR is the completed document that reflects the conformance status of a specific product. If your organization sells or operates three distinct web apps, each one needs its own ACR. Procurement teams and buyers expect to see an ACR that maps directly to the product they are evaluating.
There is a common misconception that a single ACR can represent an entire company’s digital portfolio. It cannot. The ACR documents conformance for a defined scope. Mixing multiple products into one ACR makes it unreliable for anyone reviewing it.
How to Prioritize Domains in a Large Portfolio
When you have five, ten, or fifty domains, you cannot audit everything at once. Prioritization matters.
Start with domains that carry the most risk. Customer-facing products, revenue-generating platforms, and domains subject to ADA compliance requirements or Section 508 procurement reviews should go first. Internal tools and low-traffic microsites can follow.
A practical prioritization sequence:
- Domains with active ACR requests from buyers or procurement teams
- Public-facing domains with the highest traffic
- Domains that fall under regulatory requirements (ADA Title II, EAA, EN 301 549)
- Internal tools used by employees, including those with disabilities
- Legacy domains scheduled for redesign or retirement
Domains in group five might not need an audit at all if they are being deprecated. Spend your budget where it counts.
Shared Design Systems Help, But They Are Not a Shortcut
If your domains share a component library or design system, fixing an accessibility issue at the component level can propagate across every domain that uses it. This is a real efficiency gain.
But it is not a substitute for per-domain evaluation. A button component might be accessible in isolation and then break when placed inside a specific page layout with conflicting ARIA attributes or JavaScript. The auditor needs to see how components behave in context on each domain.
Think of shared components as a head start on remediation, not as proof of conformance.
Tracking Issues Across Multiple Projects
One of the hardest parts of managing accessibility across domains is keeping track of what has been identified, what has been fixed, and what still needs validation. A spreadsheet per domain works for small portfolios. It falls apart quickly when you are managing more than three projects.
For organizations with large digital portfolios, centralized tracking is what separates structured progress from scattered effort. Each domain should get its own project with its own issue set, while you maintain visibility across all of them. Mapping issues to WCAG criteria and applying prioritization formulas helps your team know what to fix first on each domain.
Automated Scans Across Domains
Running automated scans on every domain gives you a baseline. Scans are fast and can cover a lot of pages. But scans only flag approximately 25% of issues. They are useful for catching regressions and monitoring between audits, not for determining WCAG conformance.
A scan across all your domains can tell you which properties have the most detectable issues, which helps with prioritization. That data paired with a full (manual) audit on each priority domain gives you both breadth and depth.
How Often Should Multi-Domain Portfolios Be Re-evaluated?
Content changes, feature releases, and third-party updates introduce new accessibility issues constantly. A domain that was conformant six months ago may not be today.
A reasonable cadence: conduct a full audit on each high-priority domain annually, with automated scan monitoring in between. When a domain undergoes a major redesign or adds significant new functionality, schedule an audit for that domain regardless of where it falls in the cycle.
ACRs should be updated after significant product changes. They do not have a formal expiration date, but an ACR based on an audit from two years ago will not reflect the current state of the product. Buyers and procurement reviewers will notice.
Budgeting for Multi-Domain Accessibility
Audit pricing is based on scope, specifically the number of pages or screens, their complexity, and the conformance standard (WCAG 2.1 AA or WCAG 2.2 AA). A portfolio of ten domains does not cost ten times a single audit if you plan it well.
Domains with significant template overlap may have lower per-page costs after the first domain is audited, because the auditor already understands the shared components. Staggering audits across quarters also spreads the cost and keeps your team from being overwhelmed with remediation work all at once.
Can one audit report cover two domains that share the same codebase?
No. Even if the underlying code is identical, each domain is evaluated separately. Content, configuration, third-party scripts, and deployment environments differ. WCAG conformance is determined based on what the user actually encounters on each domain.
What VPAT edition should I use for products sold internationally?
The INT edition of the VPAT covers WCAG, Section 508, and EN 301 549 in a single document. If your product is sold to both U.S. and European buyers, the INT edition is the right choice. For products sold only in the U.S. market, the WCAG edition is typically the default.
How do I know which domains need an ACR first?
Start with any domain where a buyer, partner, or procurement team has requested an ACR. After that, prioritize domains with the highest public traffic and those subject to ADA compliance or EAA requirements. Revenue impact and legal exposure are the two clearest signals.
Managing accessibility across a portfolio of domains is an ongoing operational commitment, not a one-time project. The organizations that do it well treat each domain as its own project, share what they can through design systems, and track everything in one place.
Contact Kris Rivenburgh to discuss accessibility planning for your multi-domain portfolio.