You add an automated axe check to component tests running in a simulated DOM. A test that renders a lone button fails with "all page content should be contained by landmarks", and colour-contrast problems are never reported at all. Explain both results and how you would configure the check.

## Two different failures that look like one problem Both symptoms are versions of the same rule: only assert in an environment what that environment can actually decide. But they fail differently, and conflating them leads people to silence real defects. ## Symptom one — page-level rules on a fragment Accessibility rule sets are written for documents. A substantial fraction of the rules ask questions about the page as a whole: is all content inside a landmark region, is there exactly one main landmark, does the document declare a language, is there a mechanism to bypass repeated blocks, is the heading structure sane. A component test renders a fragment — one button, one card, one form field — into an otherwise empty container. There is no `<main>`, no `<html lang>`, no heading hierarchy, because none of those are the component's job. The rule is not wrong; it is being asked about a thing that does not exist at this scope. Answering it here produces noise, and noise is corrosive: it trains people to reach for the disable switch reflexively, which is how genuine failures get silenced later. There is a second wrinkle. Rules carry tags, and by default an unconfigured run includes best-practice rules alongside the ones that map to conformance criteria. Landmark containment is a best practice for a page, not a failure of a button. The fix is to narrow the rule set deliberately rather than case by case: ```js const results = await axe(container, { runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa'] }, rules: { region: { enabled: false } }, }); ``` Restricting by tag decides the *policy* once; the explicit `rules` entries handle the individual page-level rules that survive the tag filter. Every disabled rule deserves a comment saying why it is off and where that concern is covered instead — otherwise the disable list becomes an unexamined pile that hides regressions. ## Symptom two — rules that cannot run at all Contrast is different in kind. It is not out of scope for a component; it is undecidable in this environment. Evaluating contrast requires knowing the actual rendered foreground colour and the actual background behind it, which means resolving cascade, compositing and stacking — the product of layout and paint. A simulated DOM implements the tree and much of the API surface but does not lay out or paint anything, so those values do not exist. The engine handles this honestly: instead of guessing, it records the rule as **incomplete** — ran, could not decide, needs a human or a better environment. The `toHaveNoViolations` matcher only fails on the `violations` bucket, so incomplete entries pass straight through in silence. That is why nobody ever sees a contrast failure from these tests, and it is a trap if you assumed the suite covered it. Everything layout-dependent shares this fate: target size, overlapping controls, content that reflows out of reach at high zoom. The correct conclusion is not to force the rule on but to move the check somewhere pixels exist. ## Where those checks belong instead Contrast is usually better solved at the source than per component. The colours come from a small set of design tokens; validating the token palette once — every foreground/background pairing the system permits — covers every component that uses them, and it catches the problem at design time rather than at test time. What remains is the component that composes tokens in an unforeseen way, and that is caught by a real-browser pass over assembled pages. Page-level structure rules belong at page level too: a check run against an assembled route, in whatever environment renders full pages, is where landmark containment and heading structure are genuine and meaningful. ## How to keep the configuration honest Three habits keep this from rotting: 1. **One place.** Put the configured runner in a shared test helper — with jest-axe, `configureAxe` builds a pre-configured `axe` you import everywhere — so the rule policy is a single reviewable artefact rather than an accumulation of per-file options. 2. **Reasons, not just switches.** Every disabled rule carries a comment: out of scope at this level, covered by X, or known defect with a ticket. A disable with no reason is indistinguishable from a bug being hidden. 3. **Surface the incompletes when they matter.** For components where an undecided rule represents a real risk, log or assert on the incomplete entries so the gap is visible rather than implicit. At minimum, document that the component suite makes no claim about contrast. ## The general principle The interviewer is usually probing for one idea: a test asserting something its environment cannot observe is worse than no test, because it manufactures either false confidence or false alarms. Match the assertion to the scope and the capabilities of where it runs — fragment-level rules in component tests, document-level rules against assembled pages, pixel-level rules where pixels are actually produced.