The three-legged stool of web accessibility

Words do more than inform, they orient the user. Screen reader users often navigate a page by heading structure alone, so a page that looks visually organized but uses headings as styling cues (instead of semantic landmarks) is a maze with no map.

Content creators own:

• Heading hierarchy — does the structure make sense when the visuals are stripped away?
• Link text — “click here” tells users nothing; “download the accessibility checklist” tells users what they need to do
• Alt text — not just “image of X,” but what the image means in context
• Plain language — clear writing helps everyone, especially people with cognitive disabilities

Accessibility-aware content isn’t harder to write. It’s just intentional.

Design is where accessibility tension shows up most, not because designers don’t care, but because time is often split between exploring new ideas and refining one strong set of comps. When that happens, accessibility can slip into a checklist run before developer handoff instead of a constraint built in from day one.

Designers own:

• Color contrast — text that’s hard to read for some users is a design problem
• Focus indicators — keyboard users need to see where they are on the page; that visual treatment is a design decision
• Touch targets — buttons and links need to be large enough for everyone to tap accurately, with enough breathing room between them
• Motion and animation — some users experience nausea or seizures from animation; designing a reduced-motion version is part of the spec, not an edge case
• Color alone isn’t enough — if your form validation only uses red to signal an error, colorblind users are left guessing

When accessibility lives in the design system, it scales for free.

Developers are often the last line of defense, which means they often get blamed for accessibility failures that originated upstream. When content is poorly structured and designs don’t account for keyboard navigation, no amount of ARIA attributes can make up for it.

That said, developers own real responsibilities:

• Semantic HTML — a button is not a div with a click handler; use the element that comes with the right behavior built in
• Keyboard navigation — can every interaction be completed without a mouse?
• ARIA, used sparingly — ARIA enhances semantics; it doesn’t replace them. The first rule of ARIA is: Don’t use ARIA if you can use native HTML instead.
• Dynamic content — when content updates (modals, alerts, live regions), screen readers need to know
• Testing — automated tools catch ~30% of issues; real assistive technology testing catches the rest

When accessibility is built into your design system, it scales across every component automatically — one fix propagates everywhere, and new components start from an accessible foundation rather than a blank slate. Accessibility stops being a per-ticket tax and becomes a structural guarantee. That’s the idea behind Emulsify, our open-source design system: As developers build or edit components, there’s also a command-line tool for running targeted WCAG-level checks, so every change gets checked against a solid automated baseline before it merges.

It doesn’t replace manual testing with real assistive technology. But it makes the development leg a lot sturdier.

At Four Kitchens, we treat accessibility as a shared discipline built into our process. It’s not a phase, not a plugin, not a last-mile problem. That means content strategy, design systems, and engineering standards all have to carry their own weight.

When all three legs are doing their job, accessibility isn’t remediation. It’s just how we build. Not sure which leg of your stool needs the most attention? Our accessibility audits are a good place to find out.