# Disclosing a Limit Without a Verification Path Transfers Responsibility ## Claim Stating that a feature cannot guarantee a safety property hands that property's verification to the integrator without giving them a way to check it, so the disclosure is honest but the obligation it creates rarely gets met. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds where a framework or system explicitly says it "aims for but cannot guarantee" some property (accessibility, security, correctness) and stops there, without naming a target, a checking method, or a warning path for a miss. - Doesn't claim the disclosure itself is dishonest or wrong — naming a limitation openly is strictly better than implying the algorithm solves it. The gap is specifically the missing verification tooling, not the honesty. - Weakens where the integrator already has independent means to verify (an existing linter, a required test, a review gate) — then the disclosure is a pointer to an existing check rather than an unfunded mandate. ## Evidence WordPress 7.1's `ThemeProvider` generates a colour ramp from two seed colours and states plainly: "while the color algorithm aims for accessible contrast targets, it is not possible to guarantee for every color combination, so due diligence is still required to verify its outputs." No contrast ratio is named (AA? AAA? a specific number?), no checking recipe is offered, and no warning fires when a ramp misses its own unnamed target. A plugin that lets *users* pick brand colours and feeds them into the provider has just given those users a way to generate inaccessible admin UI, and the disclosed limitation does nothing to stop them — it only means core can point to the sentence afterward. ## Links - [[Open Source Governance MOC]] — disclosure that relocates responsibility without supplying the means to discharge it - [[3. Resources/Permanent Notes/A Safety Control That Cannot See Severity Becomes a Hazard]] — because contrasts; that note is about a control blind to what it's protecting (severity), this one is about a control honest about what it can't protect (contrast) but silent on how to check it — both leave the real work undone, by different routes. - [[3. Resources/Permanent Notes/Validation That Inspects Steps Cannot See Composition]] — because applies-in, loosely; both concern a check that is structurally unable to deliver the guarantee its presence implies. - [[3. Resources/Permanent Notes/Accessibility Enforced at Authoring Time Beats Post-Hoc Auditing]] — because contrasts; that note's whole claim is that enforcement belongs at authoring time with a refusal path — this feature is the counter-case, a disclosed limit with no refusal path at all. ## Tests / falsifiers - Generate `ThemeProvider` ramps from a wide sample of seed-colour pairs and measure the fraction that fail WCAG 2.2 AA — if the failure rate is near zero, the "transferred obligation goes unmet" half of this claim weakens for this specific case. - Track whether a verification recipe or contrast-checking tool gets attached to the WordPress docs before 7.1 ships to the public — if guidance arrives promptly, the claim's "without a verification path" premise no longer holds for this instance. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Full Document Contents/Articles/Design System Theming in WordPress 7.1]] — Make WordPress Core dev note, 2026-07-31; the `ThemeProvider` contrast disclaimer and the five-prop API it ships without a checking tool.