# Stabilization Is the Accessibility Deadline Not the Finish Line ## Claim Once a block leaves the experiments flag, its markup becomes public API, so accessibility verification has to be funded before stabilization rather than treated as post-launch cleanup. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for any block whose saved markup ships to the frontend and needs backward-compatible deprecations from that point forward. - Breaks for editor-only UI, where markup can still change freely between releases without a compatibility promise. - The claim is about timing (before vs. after graduation), not about whether accessibility work is needed at all — that's assumed. ## Evidence Gutenberg 23.6 graduated the long-experimental Playlist and Tabs blocks into the default block library. Before graduation, their markup could change freely; after, any accessibility fix that requires a markup change becomes a breaking change requiring a formal deprecation path — the same constraint that makes any other public API hard to fix retroactively. Verification that happens after stabilization inherits all the cost of a backward-compatibility-constrained fix; verification that happens before stabilization is free to change anything. ## Links - [[3. Resources/Permanent Notes/Accessibility Remediation Inside Vendor Tooling Trades Speed for Client Autonomy]] — contrasts: that note is about who bears remediation cost after the fact (vendor vs. client); this one is about preventing the after-the-fact cost from existing at all by timing verification correctly - [[3. Resources/Permanent Notes/Filesystem Checks Beat Declared Flags for Classification Stability]] — applies-in: both are cases where a WordPress core mechanism creates a hard-to-reverse commitment (classification, or now public markup) at a specific technical moment worth naming precisely - [[3. Resources/MOCs/DevRel MOC]] — applies-in: flagging the stabilization moment as the accessibility deadline is exactly the kind of pre-release testing message DevRel should push to Core contributors and plugin authors - [[3. Resources/MOCs/Accessibility & Disability Inclusion MOC]] — when access verification has to be funded, given markup becomes public API at stabilization ## Tests / falsifiers - Check whether Playlist or Tabs required an accessibility-driven markup change after 23.6 shipped; if none did, this instance doesn't prove the claim, but a later case with a costly post-stabilization accessibility fix would confirm it. - Find a Gutenberg block that WAS accessibility-audited before stabilization and compare its post-graduation deprecation/fix history to one that wasn't — fewer breaking accessibility fixes for the audited block would support the claim directly. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Full Document Contents/Articles/What’s new in Gutenberg 23.6 (July 22, 2026)]] — Playlist and Tabs blocks graduating out of the block-experiments flag (#80203, #80163).