skip to content

In a component library where every component passes automated accessibility scans, why can apps built from it still fail WCAG, and who must catch what?

level: middleimportance: should knowfreq 40%

answer

  1. rules versus judgment
  2. one component versus the whole page
  3. names that exist but mean nothing
  4. consumer overrides and composition
  5. conformance is for full pages

basics

~20 s

Scans check rule-detectable defects in isolated components; they cannot judge meaning, keyboard flow, or how components combine on a page. The library guarantees each part's semantics; the app owns label wording, page structure, focus order and overrides.

solid answer

~40 s

A component-level scan runs rules against one component in isolation. It catches missing names, invalid role use and some contrast failures, but it cannot judge whether a label actually describes its purpose (WCAG 2.4.6), whether keys work end to end (2.1.1), whether focus moves logically across the components on a page (2.4.3), or whether an app's override broke contrast (1.4.3 needs 4.5:1 for normal text). WCAG conformance is also defined for full pages, so a component cannot conform on its own. The library's job is to guarantee each component's role, name wiring, keyboard contract and default contrast - with interaction tests and manual review beyond scans. The app's job is meaningful label text, page structure, composition order, and re-testing with its own content and overrides.

go deeper

for a junior

Recall that automated scans check rules, not meaning, and name one failure they miss, such as a vague label or a broken arrow-key interaction.

for a middle

Explain the ceiling in terms of isolation and judgment, map failures to WCAG criteria, and say which side - library or app - owns each.

for a senior

Show how a library raises its own ceiling - state coverage, theme contrast checks, keyboard tests, manual review - and pushes classes of app failure back into defaults.

for a principal

Discuss what accessibility claims a design system can honestly publish, and how to share accountability with consuming teams without letting either side assume the other covered it.

## What a component-level scan sees An **automated accessibility scan** evaluates rendered output against a set of machine-checkable rules: does every interactive control have an **accessible name**, are roles and states used validly, are computable text colors above the contrast threshold, do form fields have associated labels. In a **component library**, scans usually run on each component rendered in isolation, often once per variant and state. That is valuable - it cheaply catches the most common regressions - but it has a ceiling, and the ceiling is where many real failures live. ## What it cannot see In a recruiting tool built from a shared library: | Failure in the app | WCAG 2.2 criterion | Why an isolated scan misses it | Who owns it | |---|---|---|---| | Every candidate row's action button is named 'Actions' with no candidate | 2.4.6 Headings and Labels (AA) | A name exists; its meaning needs judgment | App (supplies the text) | | The interview-slot picker cannot be operated with arrow keys | 2.1.1 Keyboard (A) | Rules inspect structure; they do not press keys | Library | | Focus jumps from the filter bar to the footer, skipping the candidate list | 2.4.3 Focus Order (A) | Order emerges from how the page composes components | App | | A team restyles stage labels with lighter text that falls below 4.5:1 | 1.4.3 Contrast (Minimum) (AA) | The override is applied in the app, after the library's scan | App | | A custom card border is the only cue for selection, below 3:1 | 1.4.11 Non-text Contrast (AA) | The library never rendered the app's customization | App | | Visual headings on the pipeline page are not marked up as headings | 1.3.1 Info and Relationships (A) | Page structure does not exist at component level | App | ## Conformance is a page property WCAG's conformance requirements say conformance is for **full web pages** only and cannot be achieved if part of a page is excluded. A component library can therefore make components that *enable* conformance and are free of known defects, but it cannot claim that its components 'conform' in isolation. Native mobile apps apply the same criteria by analogy, and the same logic holds: the screen is the unit that passes or fails. ## Splitting responsibility The **library** owns: - each component's role, states and name wiring, so a supplied label actually reaches the accessibility tree; - the keyboard contract of each interactive pattern; - default visual contrast and focus indicators in every shipped theme; - documentation that states what the consumer must supply, such as a label for an icon-only button. The **consuming app** owns: - the words - labels, headings and error text that make sense in context; - page structure, landmarks and heading order; - focus order across the components it composes; - any override of colors or styles, and re-checking contrast after it. ## Raising the library's ceiling beyond scans 1. **Pin keyboard contracts in interaction tests**, since scans do not press keys. 2. **Scan every variant and state**, including open, error and disabled, not only the default render. 3. **Check contrast across every shipped theme**, not only the default. 4. **Review with assistive technology manually** before a component is marked stable, on each supported platform. 5. **Make misuse hard** - fail loudly in development when a required label is missing - so consumers cannot silently ship an unnamed control. ## The interview point A strong answer does not dismiss scans; it places them. They are the cheapest regression guard a library has and should run on every change. But 'all green' is a statement about the rules the scanner implements, applied to components in isolation - not a statement about any page a user will actually meet.

  • Should a component library advertise its components as WCAG-conformant?
    Not in those words. WCAG defines conformance for full pages, so the honest claim is that components are built and tested to support conformance - with named criteria covered by the library - and that the consuming app remains responsible for content, structure, composition and overrides.
  • How can a library reduce the failures that land on consuming apps?
    Make the right thing the default and misuse loud: required label inputs that warn in development when missing, themes that already meet contrast thresholds, documented override points that preserve contrast, and per-component notes listing what the consumer must supply. Each moves a class of app failure back into the library, where it is fixed once.
  • Why scan every state instead of just the default render?
    Many defects exist only in non-default states: an error message without an association to its field, an open menu with unnamed items, a disabled style that hides the selection cue. A scan of the default render never sees them, so each documented state needs its own render in the scanned set.

saying these in an interview costs you the question

  • A clean automated scan means apps built from the library meet WCAG.
  • If a label exists, the accessible name is good enough.
  • Focus order is the library's responsibility, not the consuming app's.
  • Consumer color overrides are covered by the library's own scans.
  • Components can be certified WCAG-conformant on their own.