ExperienceKit: Web Accessibility at Scale - Audit Components Once, Not Pages Forever

This post is part of the ExperienceKit series. New to ExperienceKit? Start with the introduction, which the whole series builds on.

Under the standard approach, the honest answer is that you don't. Commitment isn't the problem. The standard approach (audit pages, fix pages, re-audit pages) is arithmetic that fails at institutional scale. This article covers the arithmetic, the legal context that makes it unavoidable, and the structural shift that makes it tractable: moving accessibility from the page level to the component level, so you audit once and every page inherits the result. With AI generation now entering the picture, that includes every page created from here on.

The impossible math of page-by-page auditing

Take a typical large university website: tens of thousands of pages across a main site and dozens or hundreds of departmental sites, edited by hundreds of people with wildly varying training, changing daily.

Now run the numbers on page-level auditing. A meaningful manual accessibility review of a single page (keyboard testing, screen reader checks, judgment calls on alternatives and structure, well beyond an automated scan) takes an experienced reviewer somewhere between one and several hours. Multiply by ten thousand pages and you get a number measured in person-years, for one pass.

And one pass is worth little, because the site won't hold still. Every day, editors publish new pages, restructure old ones, embed new widgets. Pages audited in January drift out of conformance by June. The audit becomes a treadmill set slightly faster than you can run, with no end date in sight.

So institutions do what the arithmetic forces them to do: they sample. Audit the top 100 pages, the key user journeys, the homepage and admissions funnel. Sampling is rational triage, and it concedes that the other 9,900 pages stay unaudited, including the department page that happens to be the one a screen reader user needs today. Automated scanning helps stretch coverage, and you should use it, but automated tools detect only a fraction of WCAG failures; the rest require human judgment. Scale multiplies that need rather than removing it.

There's a second cost, less discussed: remediation whack-a-mole. Page-level audits produce page-level findings (this link text, that contrast ratio, this missing label) and page-level fixes. When the same flawed pattern exists on three thousand pages because everyone copied the same snippet, you get three thousand findings and three thousand tickets for what is, structurally, one bug.

That last observation points the way out.

Why this can't be deprioritized: the legal floor keeps rising

If accessibility at scale were only hard, institutions might deprioritize it. The law increasingly does not allow that, and the trend across jurisdictions runs in one direction.

• The EU Web Accessibility Directive requires public sector bodies in EU member states, including public universities in many contexts, to make their websites and mobile applications accessible, aligned with the harmonized European standard that incorporates WCAG success criteria. It also requires published accessibility statements and feedback mechanisms, with member-state monitoring. The obligation covers the website, not a sample of it.
• The European Accessibility Act extends accessibility requirements beyond the public sector to a range of products and services offered in the EU, with obligations that began applying in 2025. Organizations that assumed accessibility law was a public-sector concern are finding the perimeter has moved.
• In the United States, Section 508 requires federal agencies to make their information and communication technology accessible, with WCAG incorporated into its standards; related civil-rights law extends web accessibility obligations to federally funded institutions and state and local government entities, and universities have repeatedly been the subject of complaints and enforcement actions over inaccessible web content.

The specifics vary by jurisdiction and institution type; verify your own obligations with counsel rather than a blog post, ours included. But the pattern is stable: the scope is entire digital estates, the standards reference WCAG, and regulatory travel heads toward more coverage. "We audited our top pages" amounts to a triage report rather than a compliance posture. That returns us to the arithmetic problem, now with legal consequences attached.

There's also a softer forcing function worth naming: accessibility statements. Regimes like the EU directive require institutions to publish an honest account of their conformance status, including known limitations. Writing that statement forces the question this article opened with: what can you claim about ten thousand pages? An institution whose accessibility is carried in an audited component library can make claims with a defensible basis: these components, verified on these dates, compose every page. An institution auditing samples can only describe its sample.

The structural shift: accessibility lives in components

Look closely at those ten thousand pages and the problem changes shape: they are combinations of a few dozen repeating patterns (heroes, navigation, cards, accordions, tables, forms, media blocks). The page count is enormous; the pattern count is small.

Page-level auditing ignores this structure and pays for the page count. Component-level accessibility exploits it and pays only for the pattern count:

Build your site from a defined component library (in Drupal, Single Directory Components, where each component packages its markup, styling, and behavior in one place). Then make each component accessible once, thoroughly: semantic structure, keyboard operability, focus management, ARIA where warranted, contrast-safe design tokens, screen reader verification. Audit at that level, fifty components instead of ten thousand pages, and every page assembled from those components inherits the result.

The economics invert in two ways:

• Coverage: the audit that covered a 1% page sample now covers every component instance across the estate, and the arithmetic closes.
• Remediation: the three-thousand-page whack-a-mole becomes one fix. Patch the accordion component's focus handling, and every page using it is corrected on the next deployment. Findings converge to root causes instead of multiplying across symptoms.

What component-level accessibility does not cover, and why honesty here matters

Anyone who tells you components solve accessibility entirely is selling something too hard. WCAG conformance has layers, and components carry only some of them:

• Structural and interactive accessibility (semantics, keyboard support, focus order within a widget, contrast of design elements, touch target sizing) lives in components. This is the largest and most technically demanding share, and it's the share editors most often get wrong when hand-building. Components carry it completely.
• Content accessibility (meaningful alt text for this photo, link text that makes sense, plain-language writing, logical heading hierarchy across a page) depends on what humans put into components and how they sequence them. No component can know what an image depicts.

A serious component approach handles the second layer by constraining and prompting: components that require alt text (or an explicit decorative flag) before saving, heading levels managed by the system rather than hand-picked, editor guidance embedded where content is entered. The component layer carries the structural share and makes content failures harder, and it shrinks the human audit burden to the content layer, a problem editors can own.

The next ten thousand pages: where AI generation enters

Component-level accessibility secures the pages you have. But institutions keep producing pages: every campaign, program launch, event, and announcement adds more, each one a fresh opportunity to reintroduce the failures you just engineered out, because deadline pressure is when accessibility gets skipped.

This is where AI page generation, done correctly, turns from an accessibility risk into an accessibility mechanism.

The risk version first, because it's real: general-purpose AI tools make up each page from scratch. Ask a chatbot for a landing page and you'll get a page with no accessibility guarantees: plausible-looking, unaudited, and headed for your domain under deadline pressure. Editors are already doing this, and ungoverned AI output is on track to become the biggest source of new accessibility regressions on institutional sites.

Now the mechanism version. Governed AI generation builds pages only from an approved, audited component library. This is what ExperienceKit does: BrandKit, the audited component library we build for your brand, defines the building blocks, and CampaignKit, the generation engine, can draw from nothing else. Prompt: "a landing page for the open day: hero with registration call to action, three program highlights, a student testimonial, an FAQ accordion." CampaignKit selects and arranges those components and fills their content slots. Because it generates only from that library, the result is on brand and accessible from the start, without an unlabeled form or a low-contrast button slipping in. Most of the time no structural change is needed at all.

Follow the inheritance chain: the accordion was audited once, at the component level. Every page CampaignKit generates with that accordion inherits that audit at generation time, before the page exists, at whatever speed pages are created. New pages arrive with their structural accessibility already decided. When a page genuinely needs something new, your team can adjust a component or build a new one from the same audited building blocks; a change to a component's structure deserves careful review, possibly a new component, sometimes a small redesign, but generally that reach isn't needed. Human review can then concentrate where humans are irreplaceable: is the alt text meaningful, is the language plain, does the page make sense read in order?

For accessibility leads, this reframes the AI conversation. Your editors will use AI to make pages faster; that is already happening, with or without you. The open question is whether the pages AI makes come from your audited components or from a language model's improvisation. The first scales your accessibility work; the second buries it.

What this looks like in practice

A realistic sequence for an institution on Drupal:

1. Inventory your patterns. Crawl the estate and identify the repeating structures. Expect dozens of patterns rather than hundreds, and expect to find five slightly different accordions that should be one.
2. Consolidate into an audited component library. Build the canonical set as SDC, with accessibility acceptance criteria per component: keyboard paths, screen reader behavior, contrast tokens, required content fields. Audit each component manually, with assistive technology, once, and record the result. That takes weeks of expert work rather than years, because you're auditing fifty things instead of ten thousand.
3. Make components the only way pages get built, through the editorial tooling and through AI generation constrained to the same library. Every governance guarantee depends on the library being the sole path to production.
4. Refocus human auditing on content and journeys. With structure inherited, your accessibility expertise goes to sampling content quality, testing critical user journeys end to end, and processing user feedback: the work that requires judgment.
5. Treat component updates as accessibility releases. When WCAG evolves or an issue surfaces, fix the component, re-verify, and deploy; the fix propagates estate-wide.

Two honest caveats about the transition. First, the existing estate doesn't convert itself: legacy pages built outside the component system remain legacy until they're migrated or retired, so pair the component program with a content audit that prunes what nobody should be maintaining anyway. Most large estates carry a long tail of pages whose best remediation is deletion. Second, the model only holds if leadership resists the exception requests. Every "just this once, let us paste custom HTML for the gala microsite" reopens the hole the architecture closed. The governance conversation is easier than it sounds, though, because for the first time the accessible path is also the fastest path: editors get better pages in less time by staying inside the system.

This is the approach ExperienceKit brings to Drupal organizations: BrandKit is the governed, accessibility-audited component library we build for your brand, living in your own codebase as native Drupal SDC, so the components stay yours and we keep them updated. CampaignKit is the AI engine that generates production-ready landing pages from a prompt, built entirely from those approved components. The marketing team gets pages in minutes. Your team gets accessibility decided once, at the component level, and inherited by every page the AI generates.

The workload that matters is fifty components, not the ten thousand pages built from them. Audit the components, govern how pages get made, and the arithmetic works, even at the speed AI now creates pages.

Next step

See the inheritance chain live: book a demo and watch a prompt become a Drupal landing page built from audited, accessible components, or ask for our whitepaper on governed AI page generation and we'll send a copy for your accessibility and web governance teams.