Building an Accessibility-First Design System on a Budget

Small teams tend to assume accessibility is something they’ll afford later, the way startups defer hiring a lawyer. Big companies have accessibility teams, audits, training budgets. A three-person company has a backlog. So accessibility gets classed as a luxury, something you buy when you’re rich. I think this gets the economics exactly backwards. Accessibility is expensive when you buy it retail, page by page, after the fact. It’s cheap when you buy it wholesale, component by component, up front. And buying wholesale is precisely what a design system is.

The arithmetic is simple. A typical site is a few dozen page templates assembled from maybe fifteen or twenty recurring pieces: a button, a link, a text input, a select, a modal, a nav menu, a card, a table, an image, a heading scale. If you audit pages, you pay for every page, and you pay again every time a page changes. If instead you make each of the twenty pieces accessible once, every page assembled from them inherits the work for free, including pages that don’t exist yet. Fix a button in one place and you’ve fixed a thousand buttons. This is the same argument that justifies design systems in general, which is convenient: you don’t need to sell anyone on a separate accessibility initiative. You fold it into a thing small teams already want for consistency and speed.

The other reason this works for small teams is that most accessibility problems are not exotic. They are the same handful of mistakes repeated everywhere: buttons that are really divs with click handlers, so the keyboard can’t reach them; inputs whose label is a placeholder that vanishes when you type; icon buttons with no accessible name, so a screen reader announces “button” and nothing else; focus outlines removed because a designer found them ugly; text over images with whatever contrast the photo happens to provide. Every one of these is a component-level decision. Which means every one of them can be made correctly exactly once.

So here is what building the system actually looks like when the budget is zero. Start with real HTML elements, because the browser has already done most of the work for you. A native button element is keyboard-operable, focusable, and announced correctly without a single attribute added. A native select, a native checkbox, a real label wired to its input: all of this behavior comes free, built and tested by browser vendors over decades. The expensive accessibility failures almost always come from rebuilding these elements out of styled divs to gain some visual flexibility, then failing to rebuild the invisible behavior that came with the originals. The cheapest accessibility strategy in existence is to not throw away what the browser gives you.

Then encode the decisions that recur. Pick your text and background color pairs once, check the contrast once, and make those pairs the only colors the components offer, so nobody can create a low-contrast combination without leaving the system. Design a focus style you actually like, one visibly distinct ring that fits your brand, and apply it globally, so nobody is tempted to remove it locally. Set a minimum size for anything tappable. Make the image component require a decision about alt text, either a description or an explicit marking as decorative, so the question gets asked at the moment someone has the answer. None of this requires an expert. It requires making each choice deliberately one time instead of accidentally two hundred times.

There will be a few genuinely hard components, and the honest advice is to build as few of them as possible. Modals, custom dropdowns, autocompletes, and date pickers are hard because they must manage focus and announce themselves correctly, and the failure modes are subtle. For these, either lean on a well-maintained headless library that has done the work, or ask whether you need the component at all. A page that links to a separate screen is often better than a modal. A native select is often better than a custom one. Every fancy widget you decline to build is accessibility work you never have to do and never have to maintain. On a budget, the best component is frequently the one you didn’t make.

The last piece is keeping the system honest, because components rot when people bypass them. This is where a little automation pays off. Automated checks catch exactly the kind of mechanical regressions that creep in, a raw div where a button belongs, an image that slipped past the alt-text decision, a one-off color that fails contrast. I built GazeSite around this idea of continuous checking rather than annual audits, and the pattern I see in scan results supports the whole thesis of this essay: on sites with a real component system, accessibility findings cluster in the escape hatches, the hand-rolled one-off sections where someone stepped outside the system. The system itself, once right, stays right.

What you end up with is accessibility as a property of your materials rather than a task on your calendar. Nobody on the team needs to remember it, because the path of least resistance produces it. That’s the only kind of quality a small team can sustain: the kind that doesn’t depend on anyone having spare attention. You can’t afford an accessibility team. You can afford twenty good components. They’re mostly the same purchase, and the second one is on sale.