Skip to content
Back to blog Design

A practical accessibility checklist for small studios

M Mocoda Studio May 1, 2026 8 min read

Accessibility has a reputation problem. To a lot of small teams it sounds like a compliance burden — a checklist handed down by lawyers, full of acronyms, that slows everything down. In practice, the basics are neither hard nor expensive, and they make a site better for everyone, not just people using assistive technology. Here’s the short list we run before anything we build goes live.

Colour contrast that actually passes

The single most common failure we see is low-contrast text — pale grey on white because it looked “elegant” in the mockup. The standard is concrete: at least 4.5:1 for normal body text, and 3:1 for large text and meaningful UI elements like icons and form borders. Check it with a contrast tool, not your eyes — your eyes are on a calibrated screen in good light, and your visitor’s aren’t. This one fix quietly helps everyone reading on a phone in sunlight.

Visible focus states — never remove the outline

Somewhere along the way, outline: none became a reflex because the default focus ring is “ugly.” Removing it without a replacement is one of the most hostile things you can do to a keyboard user — it makes the page impossible to navigate, because they can’t see where they are. Keep a focus style. Style it to match your brand if you like, but it must be clearly visible — a 2–3px ring with good contrast. If you can tab through your site and always see where you are, you’ve passed.

Everything works from the keyboard

Plenty of people never touch a mouse — by preference, injury, or assistive setup. So the test is simple: put the mouse away and try to use the whole site. Every link, button, menu, and form control should be reachable with Tab and operable with Enter or Space. Custom dropdowns and modals are where this usually breaks; if you build one, you own its keyboard behaviour, including being able to close it with Escape and not getting trapped inside it.

Real labels on every form field

A placeholder is not a label. It vanishes the moment someone starts typing, it often fails contrast, and screen readers treat it inconsistently. Every input needs a real, programmatically associated <label>. It’s also just better UX — visible labels mean a half-filled form is never a mystery. While you’re there: use the right input types (email, tel) so mobile keyboards adapt, and put error messages next to the field they refer to, in words that say how to fix the problem.

Alt text that carries the meaning

The question for any image isn’t “what is this a picture of” but “what does this image communicate here?” A photo of a happy customer next to a testimonial might warrant a short description; a purely decorative flourish should have an empty alt="" so screen readers skip it rather than announcing “image, image, image.” Meaningful icons that act as buttons need a label too. Good alt text is editing, not transcription.

Respect reduced motion

Big parallax effects and aggressive animations can be genuinely nauseating for people with vestibular disorders. The fix is one media query — prefers-reduced-motion — and a habit of honouring it. When a visitor has asked their system to reduce motion, dial your animations down or off. We build it into our base styles so it’s handled once, globally, rather than remembered per component.

Semantic structure and a sane heading order

Screen-reader users navigate by landmarks and headings the way sighted users skim with their eyes. That only works if the structure is real: one <h1>, headings that descend in order without skipping levels, actual <button> and <nav> and <main> elements instead of <div>s pretending to be them. Semantic HTML is the cheapest accessibility win there is — it’s mostly just not reaching for a <div> when a real element exists.

It’s discipline, not budget

None of this requires a specialist or a separate phase. It’s a handful of habits — check contrast, keep focus rings, test with the keyboard, label your inputs — that take minutes when they’re part of how you build and hours when they’re bolted on at the end. We treat them as part of “done,” the same as the site being responsive or the links working. The payoff is a site more people can actually use, which is the entire reason the site exists.