Picture the exchange. A buyer asks for your Accessibility Conformance Report, someone on the platform team says the design system already has one, and a document arrives carrying a table of success criteria and a column of “Supports.”
If that document is scoped to the library, it does not answer the buyer’s question, and the reason is textual. WCAG defines conformance for one unit of content, and a component library is not that unit. The argument that follows is textual throughout: it reads the standard, the template and the regulation, and no adjudicator has ruled on any of it. The scope line in the header is what tells a reviewer whether the rows below speak to the thing being bought, which is where our VPAT and ACR work starts.
WCAG says it twice, in two different subsections
The rule gets repeated as “WCAG says conformance is for full pages.” The shorthand is right as far as it goes. What it loses is that WCAG says this in two places doing two different jobs, and the second one is what closes the exit a component library tries to use.
The first is in WCAG 2.2 section 5.3, Conformance Claims (Optional): “Conformance is defined only for web pages. However, a conformance claim may be made to cover one page, a series of pages, or multiple related web pages.” That sets the unit, and it does not contain the phrase “full pages” at all. The claim section is optional; the requirement it presupposes is not, and that is the second sentence.
The second is Conformance Requirement 2, section 5.2.2 Full pages: “Conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded.” That closes the exit: you cannot carve a region out of a page, conform the region, and report the region.
Understanding Conformance, which is supporting material rather than part of the standard, draws the consequence in one line: “This provision simply requires that the whole page conform. Statements about ‘part of a page conforming’ cannot be made.”
A component is part of a page, and a library is a collection of parts. Neither is a web page under the WCAG glossary, which defines one as “a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent.” A dropdown inside somebody else’s checkout is not a resource obtained from a URI; it is part of one.
View the data as a list
- WCAG 2.2, section 5.3: “Conformance is defined only for web pages”
- Conformance Requirement 2: Not achievable if part of a page is excluded
- A component is part of a page: A library is a collection of parts, not a page
Can a component library conform to WCAG 2.2?
No, and the standard offers no lesser level to fall back on. Conformance Requirement 1 reads: “One of the following levels of conformance is met in full.” A, AA and AAA are the whole list, and each is a property of a page. Nothing in WCAG defines a conformance level for a component, a module, a pattern or a token.
The Voluntary Product Accessibility Template inherits that scoping. Each of its five conformance terms is defined against “the product,” starting with “Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation,” and ending with “Not Evaluated: The product has not been evaluated against the criterion.” A library-scoped report borrows the vocabulary of a product report and points it at something it was not written for.
There is no gatekeeper either. ITI, which publishes the template, states that it does not review or approve VPATs, and the template never defines “product.” Nothing stops an author from entering a package name in the Name of Product field, and nothing tells them they have changed the meaning of every row below it.
Accessibility support is a property of the environment, not of the package
Conformance Requirement 4 is where a component result loses its footing when the component moves: “Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria.” A use of a technology qualifies, per the glossary definition of accessibility supported, only where it “has been tested for interoperability with users’ assistive technology in the human language(s) of the content.” Support attaches to a way of using a technology, not to a package version.
The requirement says nothing about context. That point comes from a different document and should be cited as one: Understanding Conformance states that “accessibility support of web technologies varies by environment,” and notes that technologies “may only need to be supported by those specific user agents and assistive technologies deployed at a company.”
Two limits follow. WCAG sets no threshold for how much support is enough: W3C and the Working Group “do not specify which or how many assistive technologies must support a web technology in order for it to be classified as accessibility supported.” And no text says how much of a component-level result survives a move into a different page, framework wrapper or screen reader. The nearest answer is advice, not rule: the ARIA Authoring Practices Guide advises testing “with each browser and assistive technology combination that is relevant within a target audience.” W3C publishes patterns and then tells you to retest them in place.
What a component test record looks like when it is doing its job
The clearest published example located for this article is federal. The US Web Design System publishes per-component test records, and each of the four read for this article carries the same two sentences, unchanged apart from the component name: “USWDS tests components in isolation. You need to test the combo box component in the context of your own site to ensure compliance with Section 508 accessibility standards.”
They are specific about what cannot be settled in isolation. On the combo box, 4.1.2 Name, role, value is Conditional: “This can only be tested in your implementation of the component.” On the table component, 2.1.1 Keyboard is Passed with exceptions, and the exception names the assistive technology: “A scrollable table does not scroll with left and right arrow keystrokes in JAWS and NVDA.”
Here are the four records as published, read on 24 August 2026.
| USWDS component | Tests | Passed | Passed with exceptions | Conditional | Failed |
|---|---|---|---|---|---|
| Combo box | 15 | 13 | 0 | 2 | 0 |
| Modal | 14 | 13 | 0 | 1 | 0 |
| Date picker | 16 | 13 | 1 | 2 | 0 |
| Table | 11 | 10 | 1 | 0 | 0 |
Those are counts of four public pages, reproducible by anyone. The USWDS sitemap lists 257 URLs, of which 44 end in /accessibility-tests/, so four is a sample of forty-four, and no aggregate score is published. The pages stamp each result with the USWDS version it was tested against, and the combo box carries “Last test: v3.8.0” against 4.1.2, but they carry no browser and assistive technology baseline stating what the results were produced against, which is the first thing a product team needs from them. That is what a component test record is: evidence with a named scope and named defects, not a conformance claim, and USWDS does not present it as one.
What a product-scoped ACR looks like
The counterexample located for this article sits on a design system site too. GitLab publishes its ACR on the Pajamas design system, and it is scoped to the assembled product rather than to Pajamas: Name of Product/Version “Self Managed GitLab Ultimate 19 with GitLab Duo Agentic Platform,” Report Date “August 4, 2026,” on the VPAT 2.5 International Edition template.
Three things in it are worth copying. It says what is out of scope: “This evaluation only refers to GitLab the product and does not include the about.gitlab.com or docs.gitlab.com websites.” It names the environment: “Manual audit was performed using Chrome on Windows … Assistive technologies employed included latest version of NVDA.” And it carries a Scope of Evaluation table listing 112 pages by title and path. The paths are templated against an unnamed instance ([url]/demo-group/project-1/...), so a reviewer cannot open them, but they turn “full pages” from an assertion into an enumerated list, which is more than a bare claim offers.
View the data as a table
| USWDS component test records | GitLab ACR on Pajamas | |
|---|---|---|
| What it is scoped to | Components tested in isolation, one record per component | The assembled product rather than the Pajamas design system |
| Environment named | No browser and assistive technology baseline | Manual audit using Chrome on Windows, with latest version of NVDA |
| What it enumerates | Per-criterion outcomes: Passed, Passed with exceptions, Conditional | A Scope of Evaluation table listing 112 pages by title and path |
| What it says it cannot settle | 4.1.2 “can only be tested in your implementation of the component” | about.gitlab.com and docs.gitlab.com are outside the evaluation |
| What it claims to be | Evidence with a named scope and named defects, not a conformance claim | A conformance report on the VPAT 2.5 International Edition template |
No library-scoped ACR was located and read for this article. USWDS and GitLab are the two documents that were.
The VPAT already carries the page-scoping rule
The template needs no amending, because the sentence is already in it. Under the WCAG 2.x Report heading, VPAT 2.5Rev, International Edition, reads: “Note: When reporting on conformance with the WCAG 2.x Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.1 Conformance Requirements.” GitLab’s report carries that sentence through, updated to WCAG 2.2. A library-scoped report leaves the note standing above rows that contradict it.
Two required fields are where scope is fixed or lost: the Product Description field, which the template describes as a brief description of the product, and the Evaluation Methods Used field, which asks for a description of the evaluation methods used to complete the VPAT for the product under test. Naming which components were exercised in place is a recommendation we make rather than a template requirement, and those are the fields to make it in. The template also handles the two-artifact case: “When multiple reports are used for a complex product, it is required to explain this and how to reach the other reports in the Notes section of each report.”
None of the section508.gov ACR and acquisition pages read for this article mentions design systems, component libraries or pattern libraries: the ACR page, the how-to-create-an-ACR guide, the ACR and VPAT FAQ, and the authoring tool requirements page. They address products, authoring tools and support documentation. No federal guidance on scoping an ACR for a design system turned up in this research, and the general rules are the ones that apply.
Design tokens carry no conformance semantics at all
One layer down, the ground gives out. The Design Tokens Format Module 2025.10 is a Final Community Group Report of the Design Tokens Community Group, and it says of itself: “It is not a W3C Standard nor is it on the W3C Standards Track.” A full-text scan of it on 24 August 2026 returns zero occurrences of “WCAG,” zero of “accessibility” (the word “accessible” appears three times, all about resolving references) and zero of “contrast.” Its Conformance section concerns which parts of the specification are normative and how MUST and SHOULD are to be read, and nothing else.
So “our tokens are accessible” is not a conformance statement in any standard’s terms. A token is a named value in an exchange format, and whether a color pair clears a contrast ratio is a property of the rendered page, judged under success criteria 1.4.3 and 1.4.11.
Is a design system an authoring tool under Section 508?
It depends on what you ship, and the gate is the first clause of the provision. 504.1 of the Revised 508 Standards, codified at 36 CFR part 1194 appendix C, reads: “Where an application is an authoring tool, the application shall conform to 504 to the extent that information required for accessibility is supported by the destination format.”
The definition sits in a different appendix. E103.4 defines an authoring tool as “any software, or collection of software components, that can be used by authors, alone or collaboratively, to create or modify content for use by others, including other authors.” Read alone, “collection of software components” reaches a component library. Read with the exception at 504.2, the consequence narrows rather than disappears: “Authoring tools shall not be required to conform to 504.2 when used to directly edit plain text source code.” The exception relieves conformance with 504.2 in that mode of use. It does not remove the classification, and it does not reach 504.3 or 504.4. GSA reads it the same way on its Authoring Tool Requirements page, where an editor such as Notepad “complies with the Revised 508 Standards, because it only functions as an editor of plain text files.” A package a developer imports into hand-written code sits inside that exception for 504.2. Whether it owes 504.3 and 504.4 anyway is not resolved by the regulation.
Where the clause bites is a builder, a generator, a page composer or a shipped template set. That same GSA page lists “Software used to develop software” among its examples of authoring tools, which pulls toward the broad reading, and nothing in the regulation resolves the boundary. The practical test is whether the thing you ship assembles or generates content for an author who is not writing the code. If it does, 504.2 requires a mode of operation “to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0,” 504.3 a mode “that prompts authors to create content that conforms,” and 504.4 conforming templates where templates are provided. The VPAT row carries the fork in its own instruction: “504.2 Content Creation or Editing (if not authoring tool, enter ‘not applicable’).”
View the data as a table
| A package imported into code | A builder, generator or composer | |
|---|---|---|
| 504.2 content creation or editing | Relieved by the exception for directly editing plain text source code | A mode that creates or edits content conforming to WCAG 2.0 Level A and AA |
| 504.3 prompting and 504.4 templates | Not resolved by the regulation | A prompting mode, and conforming templates where templates are provided |
| Classification under E103.4 | The exception does not remove the classification | GSA lists “Software used to develop software” as an example |
| The practical test | The developer writes the code the package sits inside | It assembles or generates content for an author who is not writing the code |
There is a hard limit on what that lets you claim, stated in ITI’s Reporting Conformance to ICT Accessibility Standards: “In the case of a customer-licensed authoring tool for creating web sites and applications, a conformance statement may also include information about the tool’s output. This information can only describe what the tool is capable of producing, not what the output actually conforms to, because that is a function of how the tool is used.” A design system can promise a conforming path. It cannot promise a conforming product.
What to hand the product team instead of an ACR
The library artifact is not worthless. It is worth what its scope says, and five things carry across.
View the data as a list
What the library artifact is worth: Five things carry across to the product team
- A support baseline: Browsers, OS and assistive technologies
- A component test record: What cannot be settled in isolation
- Reference outputs: Assembled pages, the unit WCAG judges
- A product-level ACR: Scoped to the assembled product
- Authoring-tool rows: Only where 504.1 applies
A named accessibility support baseline. The browsers, operating systems and assistive technologies, with versions, that results were produced against. Requirement 4 needs it, and W3C publishes model wording: “based on testing content in language(s) of the content with User Agents A, B, and C, and Assistive Technologies X, Y, and Z.”
A per-component test record. Criteria checked, outcome, and an explicit list of what cannot be settled in isolation. USWDS is the working example, down to marking 4.1.2 Conditional rather than claiming it.
Reference outputs. GSA’s Authoring Tool Requirements page tells buyers to “request the vendor provide samples (also known as reference outputs) of at least one example of every type of interface element,” and to test them. For a design system that means assembled pages, because an assembled page is the unit WCAG can judge.
A product-level ACR. Name of Product, Product Description, Notes and Evaluation Methods Used describing the assembled product, with a scope statement listing what was evaluated. For software sold to government or education buyers this is the document that clears procurement, and it is what our SaaS accessibility work is built around. Reading somebody else’s is a separate skill, covered in how to score a vendor ACR.
Authoring-tool rows, if and only if 504.1 applies. A second report is allowed, and the template requires each report to explain the split and say how to reach the other.
WCAG-EM 2.0 is the best available account of how to scope the evaluation, and it should be labeled correctly: a W3C Group Note published 23 July 2026, endorsed by the Accessibility Guidelines Working Group and not by W3C itself. It is designed “to evaluate full, self-enclosed digital products, such as websites,” and its single mention of design systems puts them among “other systems relied on for conformance” that an evaluator identifies alongside authoring tools and front-end frameworks: identified, not evaluated. On reuse it says, in a sentence worth quoting rather than paraphrasing, that “while the requirement is to check full pages, typically these components do not need to be re-evaluated on each occurrence unless they appear or behave differently.” Component-level work cuts the cost of a product evaluation. It does not replace it.
What is not settled
No published decision, settlement or enforcement action applying WCAG’s full-pages requirement to a component library’s conformance report turned up in the research for this article. No adjudicator has tested the reading set out above.
The line between a design system and an authoring tool is drawn nowhere in the regulation. E103.4 read broadly reaches a component library, and the plain-text-source-code exception relieves conformance with 504.2 without saying whether 504.1, 504.3 and 504.4 still attach. GSA’s example list pulls one way and the exception pulls the other.
And the two real examples here are two examples. USWDS and GitLab were the instances located, and four of the forty-four USWDS component records were read. Nothing here supports a statement about what design systems in general do.
Whether a specific contract obliges a supplier to deliver a product-level ACR, and what a buyer may reject when a library-scoped report arrives instead, is a contracts question. The standard, the clause and the scope rule are above. The reading of your contract belongs to counsel and, on a federal buy, to the contracting officer.
Next step
Open the ACR your design system publishes and read one field: Name of Product/Version. If it holds a package name and a semantic version, the report describes parts, and the buyer asked about the assembled thing. The fix is not a bigger component test matrix. It is a product-scoped report naming the pages evaluated and the assistive technology they were evaluated with, with the component record attached as evidence rather than offered as a substitute.