# A Feature Plugin's Name Sets Expectations Its Code Cannot Meet ## Claim What a WordPress feature plugin is called shapes whether disabled users and accessibility professionals expect it to retroactively fix core, independent of anything the plugin's code actually does. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Sharpest for accessibility- and security-adjacent names, where a misread has trust consequences rather than merely disappointment. - Less relevant for cosmetic or performance features, where the name promises less. - The failure is asymmetric: a name that undersells costs adoption, a name that oversells costs credibility with exactly the users the work was for. - Applies to any opt-in artifact whose name reaches a wider audience than its changelog. ## Evidence From the WordPress Accessibility Day 2025 Accessibility Lab session with Joe Dolson and Anne McCarthy: naming is raised as a distinct problem from implementation for accessibility feature plugins. ## Links - [[A Feature Plugin Can Carry Migration Risk a Core Release Cannot]] — the benefit side of the same mechanism — plugin-space shipping contains risk but creates this expectations problem - [[Being Anticipated Beats Being Tolerated - Visible Inclusion Shifts the Burden]] — why the credibility cost lands hardest on disabled users: a name promising a fix and not delivering is another round of being accommodated rather than expected - [[3. Resources/MOCs/Accessibility & Disability Inclusion MOC]] — the trust-and-credibility side of accessibility work, where the cost of overpromising lands.