- Web Design
- Strategy
The projects where accessibility actually sticks are the ones where it was never treated as a separate phase. Bolt it on at the end and it becomes a checklist to satisfy; build it in from the first component and it just becomes how the site works.
Start with real elements
Most accessibility problems disappear before they exist if you reach for the native HTML element first, and only replace it with something custom when there's a genuine reason to.
<button type="button" aria-expanded="false" aria-controls="menu-panel">
Open menu
</button>A real <button> gets keyboard support, focus styles, and screen-reader semantics for free — no ARIA required to make it merely work. ARIA earns its place once you're doing something the native element genuinely can't.
Focus is a first-class design decision
Where focus goes when a panel opens, what happens when it closes, whether Escape does anything sensible — these aren't edge cases to patch in later, they're part of the interaction design from the first sketch.
A short list we check on every interactive component
- Can it be operated with a keyboard alone, start to finish?
- Is there always a visible focus state?
- Does closing something return focus somewhere sensible?
The payoff isn't just compliance
Sites built this way tend to be faster and simpler too — native elements are lighter than their custom replacements, and a codebase with fewer special cases is easier for the next developer to reason about, accessibility need aside.
If accessibility has been an afterthought on your current site, we can help make it a default instead. Get in touch.