Accessible by Default is the practice of building accessibility into the system, design tokens, shared components, linters, and continuous integration, so that every screen inherits it automatically, rather than retrofitting it through audits at the end of the cycle. The shorthand is "shift left": move accessibility work to the earliest possible phase, where it is cheapest to do and hardest to undo. When the design system's button is built once with correct focus, contrast, labels, and semantics, every button across the product is accessible without anyone thinking about it.
The mistake is to treat accessibility as a QA gate or a pre-launch audit. By then the defects are baked into hundreds of screens, retrofitting semantic structure is expensive, and the same issues reappear in the next release because nothing upstream changed. Audit-and-remediate is a treadmill. The way off it is to make the accessible path the default path: accessible primitives, accessible defaults in tokens, lint rules that flag issues while you type, and a CI check that blocks new violations before they merge.
This is not only ethical, it is economic. Deque's analysis of thousands of implementations found that shifting accessibility into development reduces remediation cost by roughly 75 percent and speeds fixes about threefold, because a defect caught in development costs far less than the same defect found in production.
The principle: bake accessibility into tokens, components, linting, and CI so every instance inherits it. Catch issues at design and code time, not in an end-of-cycle audit.
Accessible by Default rests on a cost curve, a systems insight, and a tooling layer that matured recently.
The cost curve is the oldest argument. The classic 1-10-100 rule of quality holds that a defect costs about $1 to prevent in design, $10 to fix in development, and $100 to fix after release, and accessibility sits at the steep end because retrofitting semantic structure and litigating live defects is expensive. Deque's Doing the Numbers analysis puts concrete figures on it: a defect fixed in development costs around $350 less than in QA, and one that reaches production can cost $800 or more, so shifting accessibility testing into development cut total accessibility investment from roughly 15 percent of a project to 5 percent or less in their data, a remediation-cost reduction near 75 percent.
The systems insight is leverage. The W3C WAI guidance Planning and Managing Web Accessibility frames accessibility as something integrated across the whole lifecycle (initiate, plan, implement, sustain), not a one-time check, and repeated over time. The highest-leverage place to apply that is the design system: build an accessible component once and every instance inherits it. This is the "write once, fix everywhere" property, and it is why accessible-by-default and a coherent design system are the same effort pointed at the same goal.
The tooling layer made shifting left practical. Accessibility linters such as Deque's axe DevTools Linter act "like a spellchecker for accessibility," flagging issues in React, Vue, Angular, and HTML while you code, and the same checks run in CI to "block obvious accessibility defects from being merged." Mature design systems now ship accessibility as a baseline: Microsoft's Fluent 2 states its "components meet or surpass WCAG 2.1 AA standards to ensure an accessible foundation," and Shopify Polaris and GitHub Primer document accessibility as a built-in property tested with real assistive-technology users.
One honest caveat the research is clear about: automated checks catch only a portion of WCAG. Linting and CI prevent regressions and obvious defects, but human and assistive-technology testing remains necessary. Accessible by default reduces the manual burden; it does not erase it.
For Users: When accessibility is the default, every screen works the first time, not just the ones that happened to get audited. Consistency across the product is itself an accessibility win.
For Designers: Accessible tokens and components make the accessible choice the easy choice. Bake contrast, focus, target size, and semantics into the system and designers inherit them instead of relitigating them per screen.
For Developers: Lint at edit time and gate at the pull request. An accessibility linter catches issues as you type, and a CI check blocks new violations from merging, so accessibility stops being an end-of-cycle scramble and becomes part of normal code quality.
For Product Managers: This is an upstream investment, not a cost center. Shifting left cuts remediation roughly 75 percent and speeds fixes about 3x, while leaving far less legal exposure than discovering defects in production.
Accessible by Default comes down to defaults, components, automation, and honest limits.
Bake accessibility into tokens and defaults. Contrast-safe color pairs, visible focus styles, and minimum target sizes should be the default values, so a team cannot easily build an inaccessible surface from the system.
Make accessible components the only components. Build shared primitives (button, input, modal, menu) once with correct semantics, labels, focus management, and keyboard support. Every instance inherits it. This is the highest-leverage fix available.
Lint at edit time. Use an accessibility linter so developers see issues while coding, in the frameworks they use, before anything is committed.
Gate in CI. Run automated accessibility checks on every pull request and block obvious new violations from merging, the way you would block a failing test or a type error.
Keep human and AT testing in the loop. Automation catches only part of WCAG. Pair it with keyboard and screen-reader testing and, ideally, testing with disabled users, for the judgment automation cannot make.