Short answer. Most government websites are assembled from a shared set of components. If those components have been tested for accessibility, every page built from them starts in a better place, and fixes made once flow through the whole site. Ask your builder for component-level evidence against WCAG 2.2 Level AA, then test your site on top of it.

What a component audit is#

A component library is the set of building blocks a website is made from: buttons, forms, menus, accordions, tabs, cards and page templates. On GovCMS and other Drupal platforms, sites are assembled from a shared theme and component set.

A component audit tests those blocks directly. That beats finding the same fault again on page after page.

Why it matters for your website#

  • Problems repeat. A menu that traps keyboard focus or a form field with no label repeats on every page that uses it.
  • Fixes flow through. Fix the component once and every page built from it improves.
  • Site audits get simpler. When components are already tested, testing your site can focus on your content, journeys and anything custom.
  • WCAG 2.2 changes land here. Focus visibility, target size, dragging alternatives and accessible logins are mostly component issues.

What good component testing covers#

  • Keyboard: every control can be reached and used with a keyboard, in a logical order, with focus always visible.
  • Screen readers: each component announces what it is, its current state and its value, using the right roles and labels.
  • Visual: text and controls have enough contrast, and nothing relies on colour alone.
  • Zoom and reflow: it still works at 200% zoom and on narrow screens, without scrolling sideways.
  • Pointer and touch: targets are big enough, and anything done by dragging has a simple alternative.
  • Forms and errors: fields have labels and instructions, and errors are clear and announced.
  • Motion: anything that moves can be paused, and nothing flashes.

In isolation and in context#

A component can pass on its own and fail on a page. Common examples:

  • duplicate or missing page landmarks
  • headings in the wrong order once components are combined
  • focus order that breaks when sections are combined
  • a sticky header or cookie banner covering the element that has focus

So good testing covers each component in isolation first, then inside a representative set of real page templates.

Where lived experience testing fits#

Checkpoints tell you whether a component meets a criterion. People who use assistive technology every day tell you whether it works.

Our testers use the components as part of real tasks. That finds problems a checklist misses, such as a control that technically conforms but is slow or confusing to use with a screen reader.

What to ask your builder for#

  • A dated component audit report: which components were tested, against which WCAG version and level, by whom and when.
  • Usage guidance for each component, so your content team uses it correctly. A conforming accordion can still be misused.
  • A list of known issues, with planned fixes and dates.
  • A retest record showing fixes were verified.
  • Their process for re-testing when components change or the platform is upgraded.

If your builder hasn't had its components tested, we can do it with them: we test, report the findings, and work with their developers on the fixes. Ask your builder to bring us in.

What a component audit does not cover#

  • Your content. Headings, link text, alt text, plain language, tables and documents.
  • Your full journeys, such as applying, booking or paying.
  • Anything custom or third-party, such as maps, embedded forms, chat tools and booking widgets.

That is why component testing pairs with a site audit of your key journeys. For what that evidence should include, see our article on accessibility evidence in government procurement.

Keeping it current#

Component evidence is only current for the version that was tested. Ask for re-testing when a component changes, when the platform is upgraded, and when the standard changes.

Retest any components that were not designed against WCAG 2.2. AS EN 301 549 still references WCAG 2.1, but federal digital standards already require 2.2. See our article on AS EN 301 549 and WCAG 2.2 for government websites.

Frequently asked questions#

How is a component audit different from a website audit?#

A component audit tests the building blocks your site is made from. A website audit tests your site as people use it, including your content and journeys. You need both, and component testing makes the website audit faster.

Who is responsible for the accessibility of our content?#

Your agency. Accessible components make it easier, but headings, link text, alt text and documents are written and published by your team.

What if our site has no formal design system?#

Every site has repeated templates and elements, even without a formal library. Testing the most-used ones first still gives you most of the benefit.

Can component evidence go into our accessibility records?#

Yes, as part of the record, alongside testing of your site. On its own it does not show that your site conforms.

Talk to us#

Want to know whether your site's components have been tested, or what to ask your builder? Book a free 15-minute call.