Accessibility holds when it is enforced at the moment of authoring — by block validations, required content-role attributes, and publish-blocking checks — rather than recovered later through audits, overlays, or a one-time compliance pass. The reason is structural: an audit is a snapshot of a system that keeps changing, so it goes stale the instant the next edit ships, while a gate built into the editor refuses to let the inaccessible content exist in the first place. The same logic explains why automated overlay widgets fail (they promise "100% accessible" without touching how content is authored) and why the agency in the Made Right Media case only improved once it moved accessibility *into* the build process instead of bolting it on — "there's no finish line; it's like going to the gym." <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies to authoring systems that can intercept content before publish (block editors, CMS validation, CI checks). Where authoring can't be instrumented, auditing is the fallback, not the goal. - "Enforcement" means the right defaults plus a refusal path (block validation, required attributes), not merely a warning the author can ignore — a nag is still post-hoc in spirit. - Not a claim that audits are worthless: audits surface what slipped through and seed the next gate. The claim is about *where the leverage sits* — upstream at authoring time. ## Links - [[3. Resources/Literature Notes/Lit · Block validations prevent inaccessible content at source]] — the direct WordPress mechanism: a publish-blocking validation is accessibility enforced at authoring time, the concrete instance of this claim. - [[3. Resources/Literature Notes/Lit · Block attributes require explicit content role marking for accessibility]] — requiring explicit content-role attributes is the same authoring-time gate applied to semantics, so the editor can't emit role-ambiguous markup. - [[3. Resources/Literature Notes/Lit · Accessibility work shapes product and culture]] — why authoring-time enforcement also changes culture: baking it into the build (vs. selling it as an upsell audit) is what makes teams own it. - [[3. Resources/Permanent Notes/Encoding What Good Looks Like Is What Makes Agent Verification Trustworthy]] — the general principle this is a special case of: a publish-blocking check is "good" encoded as a gate, which is also what makes any automated verification trustworthy. - [[3. Resources/Permanent Notes/Being Anticipated Beats Being Tolerated - Visible Inclusion Shifts the Burden]] — the inclusion-stance sibling: enforcing access by default anticipates the disabled user instead of tolerating an after-the-fact fix. - [[State of Accessibility in WordPress 6.3 Gutenberg]] — evidence-for; the screen-reader audit shows how missing focus management and inconsistent controls become authoring-time accessibility failures. - [[3. Resources/Permanent Notes/Detecting a Property Is Not Evaluating Whether It Serves Anyone]] — the ceiling on this claim: authoring-time tools enforce detectable properties too, so shifting left narrows the audit surface without closing the evaluative gap - [[Accessibility Prompting Fixes Attributes Not Interaction Patterns]] — the AI-generation instance of the same upstream/downstream split: prompting is the authoring-time gate, and it holds for attributes while interaction behaviour still needs a later pass. - [[3. Resources/Permanent Notes/A Shared Accessible Component Library Makes the Accessible Choice the Default]] — extended by: the accessible choice must be what a developer gets by typing the obvious thing (giffgaff, LeadDev). - [[3. Resources/MOCs/Accessibility & Disability Inclusion MOC]] — applies-in: the MOC lists it in its 2026-10-05 section on access in congregations and design. - [[3. Resources/MOCs/DevRel MOC]] — applies-in: the MOC lists it under Accessibility as the advocacy lesson from the Made Right Media case.