You’re rebuilding the site, everyone wants it “accessible by default,” and now you’re being asked which design system to use—as if you’re picking a color palette instead of setting the rules that will govern every campaign for years.
Choose the design system path that makes accessibility a reusable decision once, not a fresh argument on every new page or campaign.
This isn’t really a tooling question. It’s a governance question:
- Who owns the patterns that make your site accessible?
- Who is allowed to break them, and how is that reviewed?
- How do you stop “just this one landing page” from becoming a second, rogue design system six months after launch?
Put differently: a design system only helps accessibility if it gives you one place to make hard decisions—and the power to stop everyone else from quietly undoing them.
In this article, we’ll compare three paths for your rebuild:
- Adopt an existing accessible design system
- Customize a component library into your own patterns
- Create a fully bespoke, accessibility-first design system
We’ll look at each through an accessibility-governance lens: ownership, documentation, testing, and exception handling.
1. The real decision behind “Which design system should we use?”
On most rebuilds, the design-system conversation starts in Figma: component kits, tokens, and shiny UI examples.
But in practice, the real decision is this:
Are we creating a single, enforceable source of truth for how accessibility shows up on every template, or are we just upgrading our widgets?
The visible choice—Material vs. Bootstrap vs. “our own system”—is downstream from a less visible one:
- Is accessibility owned or crowd-sourced? If every new landing page involves re-arguing color contrast and heading structure, you don’t have a design system; you have a collection of opinions.
- Are exceptions governed or improvised? If urgent campaigns regularly ship with “temporary” components that never get formalized, you’re quietly running two design systems.
- Is testing systematic or heroic? If accessibility quality depends on one conscientious developer or QA lead, you don’t have a system; you have a bottleneck.
From Best Website’s perspective, the biggest failure pattern we see isn’t “we picked the wrong library.” It’s “we made no decision about who can change patterns after launch.”
Your design-system choice is your chance to fix that.
2. Confirm you actually need a design-system-level decision
Not every accessibility push justifies a full design-system decision.
You’re likely in design-system territory if:
- You’re already planning a template-level rebuild, not just updating colors and fonts.
- Multiple teams (marketing, product, support, IT) depend on shared components.
- You’re expecting frequent new pages and campaigns after launch.
- You’ve had repeated accessibility bugs in different places that look suspiciously like the same pattern problem.
If you’re not sure whether you’re doing a light refresh or a full UX rethink, pause here. The post on how to decide if your next accessibility push is a design refresh or a full UX rethink is useful prerequisite context to calibrate the scope of change before you lock in a design-system path.
If you confirm that you are, in fact, rebuilding templates and flows, then you’re also deciding:
- Where accessibility rules live
- Who can change them
- How you align design, content, and development around those rules
That’s what a design-system decision really is.
3. The Accessibility Design System Triangle: Adopt, Customize, or Create
To keep this decision sane, use what we’ll call the Accessibility Design System Triangle.
You have three options:
- Adopt – Use an existing, accessibility-focused design system with minimal visual changes.
- Customize – Start from a solid component library, then adapt it to your brand and IA.
- Create – Design and build a bespoke, accessibility-first system from scratch.
Each option trades off:
- Ownership – Who truly owns patterns and accessibility rules?
- Documentation – How complete and understandable are the rules?
- Testing – How much do you inherit vs. have to build and run yourself?
- Exception handling – How easy is it for the organization to “go off road” safely—or dangerously?
A quick rule of thumb most leadership teams find helpful:
- Adopt when your priority is speed, you can live with familiar patterns, and you don’t have edge-case complexity.
- Customize when you need a distinct brand and IA but don’t want to reinvent accessibility patterns from first principles.
- Create only when your regulatory, product, or interaction complexity is so specific that existing systems can’t cope—and you’re ready to invest in serious governance.
We’ll unpack each.
4. Option 1 – Adopting an existing accessible design system
What “adopt” really looks like
This is the “don’t be clever” option. You:
- Choose a mature, accessibility-conscious design system or UI library.
- Accept most core interaction patterns as-is (buttons, forms, nav, modals).
- Apply your brand via tokens (color, typography, spacing) with light tweaks.
The promise: years of accumulated accessibility thinking bundled into components you don’t have to invent.
Where accessibility is usually strong
- Baseline semantics: Landmarks, ARIA attributes, and keyboard handling are often built in.
- Common patterns: Forms, buttons, alerts, dialogs, and tooltips are usually well-tested.
- Community scrutiny: Popular systems tend to be poked at by many teams and assistive-technology users.
Where adoption fails in the real world
Straight adoption fails not because the library is bad, but because governance around it is weak. Common failure modes:
- Component overrides: Marketing “just needs” a tweaked hero, so a developer copies the base component, rips out some attributes, and now you have an inaccessible clone with no documentation.
- Ad-hoc layouts: Teams assemble pages with raw grid and typography utilities instead of pre-defined templates, so heading levels and reading order drift over time.
- Third-party embeds: Checkout, forms, or search move into a third-party widget with totally different accessibility behavior and no shared rules.
Notice the pattern: the library wasn’t the issue; exceptions were.
Governance commitments you still need
Adoption is not a free pass. You still need:
- A pattern owner – Usually product, UX, or a cross-functional “design system council” that decides which library components are allowed and how they’re configured.
- A change gate – A lightweight process for approving new variants so you don’t get a second, unofficial system from duplicated code.
- A page-assembly rulebook – Clear guidance for editors on which blocks can go where, and what can never be free-styled.
If you’re not willing to enforce those, adopting a great accessible system will still result in an inaccessible site.
5. Option 2 – Customizing a component library for your patterns
This is the middle path most mid-sized organizations should seriously consider.
You start from an existing, accessible component library, but you:
- Re-map components to your site’s IA (e.g., specific card patterns for solutions, resources, and case stories).
- Codify your brand via tokens and standardized variations.
- Design a set of governed page templates and content modules that reflect how your marketing and product teams actually work.
Why this path is attractive
- You don’t reinvent accessibility primitives. You inherit alt-text patterns, focus states, landmarks, and ARIA roles from the base library.
- You get brand coherence. Instead of “whatever the library ships,” you define how patterns express your identity.
- You can align with your workflows. You can design modules specifically for your campaign types, resource hub, or pricing pages, built on accessible foundations.
This is where the distinction between a component library and a governed design system really matters. A library is just a box of Lego bricks; a system tells people which sets they’re allowed to build, and who approves new ones.
Governance and documentation needs go up
Once you customize, you own more of the stack. That means:
- Design documentation: You need clear, non-technical docs that say “This pattern exists, here’s when you use it, here’s when you don’t.”
- Content guidance: Editors need examples of accessible copy length, heading usage, link text, and media placement for each component.
- Engineering standards: Developers need rules about how to extend components without breaking accessibility (e.g., no new interactive element without keyboard and screen reader consideration).
Without this, a customized library becomes just as fragile as a bespoke one—only with more assumptions hidden inside.
When customization is worth the cost
Choose this path when:
- You have a recognizable brand and can’t look like every generic SaaS landing page.
- You run many campaigns and need repeatable, governable modules instead of constant one-offs.
- You don’t have the appetite (or budget) to build every primitive, but you can invest in documentation and review processes.
For many organizations in this situation, a strong, customized library with good governance is a sweet spot: high reuse, good accessibility inheritance, and patterns that actually fit how the business markets and sells.
6. Option 3 – Creating your own accessibility-first design system
This is the option most agencies pitch fastest and most leadership teams underestimate.
What “build your own” really entails
- Defining every primitive: buttons, links, inputs, modals, tooltips, tables, navigation, and more.
- Designing and validating interaction patterns for edge cases, complex flows, and assistive-technology behavior.
- Documenting usage, anti-patterns, and examples for designers, developers, and editors.
- Setting up an ongoing pipeline for accessibility testing, regression checks, and versioning.
If you operate in complex, regulated, or multi-product environments, this can be justified: think intricate dashboards, role-based experiences, or highly specialized workflows where off-the-shelf patterns break down.
But without strong governance, this path is a governance mistake.
The governance bar is much higher here
Because all rules are “homegrown,” you must decide:
- Who is the permanent design-system owner? Not just during the rebuild, but years after launch.
- What is the review cadence? How often do you revisit patterns as browsers, assistive tech, and your own content evolve?
- How are exceptions handled? Is there a formal request-and-approval path for new patterns, or do teams invent them in code and hope for the best?
- How do you deprecate unsafe components? Once you discover an accessibility problem in a widely used pattern, how do you roll out changes across the site without chaos?
Teams often underestimate not the build, but the care and feeding of a bespoke system. The first year may go well because everyone is paying attention. Years two and three are where drift, regressions, and “shadow components” explode.
If you can’t point to a durable governance structure that will survive personnel changes and reorgs, creating your own system will likely produce worse accessibility outcomes than adopting or customizing a good one.
7. The Accessibility Governance Scorecard for design-system choices
To make this decision concrete, use a simple Accessibility Governance Scorecard.
Rate each option (Adopt, Customize, Create) against these factors for your organization.
1. Decision rights
- Who decides what a “standard component” is?
- Who can approve new patterns or major variations?
Signals you’re in trouble: Nobody can answer “Who gets to say no?” about a new component.
2. Documentation quality
- Do designers, developers, and editors have a shared, understandable reference?
- Are accessibility rules written in human language, not just code comments?
Signals you’re in trouble: Editors keep asking, “Can I do this?” and getting different answers from different people.
3. Exception handling and drift
- Is there a formal process to request an exception—and a place to record the decision?
- Do exceptions get revisited and, if needed, promoted into the system or retired?
This is where hidden costs live. Repeated “just this once” decisions are how you accidentally build a second design system.
For more detail on this specific drift pattern, the post on how to tell when repeated design exceptions are becoming a second design system is a useful operationalization of what can go wrong after launch.
4. Ongoing accessibility testing
- What automated checks are part of your CI/CD pipeline?
- Who is responsible for manual testing of critical flows, and how often?
- Does your design system include guidance on test cases (e.g., keyboard-only flows, screen reader scenarios)?
Signals you’re in trouble: Accessibility bugs appear only as scattered support tickets, not as part of a structured testing cycle.
5. Support and staffing fit
- Do you have (or plan to have) people with the right skills to own this system: design, UX writing, frontend, QA, and content ops?
- If a key person leaves, does governance survive?
Signals you’re in trouble: Your entire accessibility strategy is “our lead dev is passionate about this.”
How the three options typically score
This isn’t a numeric rubric, but some patterns show up over and over:
- Adopt: Strong baseline accessibility, lighter documentation burden, high risk of exception drift if governance is weak.
- Customize: Good accessibility inheritance, higher documentation and ownership needs, strong payoff when you have recurring page types.
- Create: Potentially the best fit for complex scenarios, but only if you’re ready to behave like a product organization around your own design system.
If you want one more rule of thumb:
If you can’t clearly name the ongoing owner of your design system, you are not ready to create your own.
In that case, adopt or customize.
8. Sequencing design-system decisions inside your rebuild project
Even if you pick the right option, bad timing can sabotage accessibility.
A practical sequencing model:
- Scope the level of change. Confirm whether you’re doing a refresh or a rebuild. (Again, the refresh-vs-rethink article is your prerequisite here.)
- Lock your design-system path early. Decide adopt vs. customize vs. create before detailed page designs begin. Otherwise, you’ll end up designing unattainable components that don’t map cleanly to your system.
- Define your “accessibility by default” rules. Before anyone pushes pixels, decide: minimum tap targets, color contrast constraints, focus behavior, error messaging patterns, heading hierarchy, and landmark structure.
- Design templates and core components together. Page layouts and components should be designed as a set. If you want a deeper layout-specific lens, the article on designing accessible page layouts before you touch color or typography is a good expansion on the structure-first approach.
- Wire in testing while building. Don’t wait until “accessibility QA” at the end. Integrate automated checks and manual spot-testing while components are being built.
- Pilot with real content and campaigns. Before launch, run a realistic campaign through your new components and templates. Watch where editors or marketers try to improvise; those are governance weak points.
A common pattern: marketing asks for a one-off campaign module late in the rebuild. Under pressure, the team builds it outside the design system “just this once.” That component then becomes a favorite, copied by others. Six months later, your support queue is full of accessibility bugs tied to that unofficial pattern.
Sequencing decisions thoughtfully is how you avoid planting those time bombs.
9. How this fits your Buyer Maturity Path
Design-system choices sit in the middle of what we call your Buyer Maturity Path:
- Problem recognition: “We keep running into accessibility issues and complaints.”
- Operational insight: “These aren’t isolated bugs; our templates and patterns are the problem.”
- Governance realization: “We need shared rules and ownership, not just more tickets.”
- Design-system decision (you are here): “We’re rebuilding; which design-system path lets us make accessibility decisions once and reuse them safely?”
- Ongoing ownership: “We run a governed design system with clear decision rights, review cadence, and testing.”
This article lives at step 4. Other posts in our archive emphasize steps 2 and 3—for example, what a design team should commit to before accessibility becomes a launch-blocking risk offers a useful contrast by focusing on design-team responsibilities even before you talk about components.
As your maturity grows, your website—and the content around it—form a kind of Content Neural Network: service pages, topic hubs, and governed templates all reinforcing one another so accessibility expertise compounds instead of scattering across siloed exceptions.
Your design system is one of the main “synapses” in that network. It decides whether new pages strengthen your accessibility posture or quietly weaken it.
10. When to bring in a partner for accessibility-first design system work
Some teams can realistically own this themselves. Many can’t—at least not at the level of discipline a serious, revenue-supporting site deserves.
Signals you should consider outside help:
- Your internal teams disagree on whether adopt, customize, or create is appropriate.
- You don’t have a named owner who can dedicate time to design-system governance.
- Past redesigns have “launched fine,” then drifted into accessibility regression within a year.
- You’re facing audits, legal risk, or brand exposure if accessibility doesn’t improve.
In those situations, it’s worth having a partner help you:
- Choose the right level of system for your complexity and staffing.
- Define governance structures and decision rights around accessibility.
- Design, document, and implement accessible templates and components.
- Establish a realistic review cadence and testing workflow that your team can sustain.
If you need that level of structured help, our Web Design & Development work is built to operationalize an accessibility-first design system rather than handing you a static library and walking away.
If you’re earlier in your maturity path and still building your internal understanding of accessibility governance, spend time with our Accessibility articles hub as an expansion step. It connects related posts on proposals, layouts, exceptions, and ownership so you can see how design-system choices fit into the larger operational picture.
And when you’re ready to pressure-test your rebuild plan—or you want to talk through the tradeoffs between adopting, customizing, or creating a design system for your next launch—you can always get in touch via our contact channel at contact page.