Skip to content
Site & Rise
All insights
Accessibility4 min read

Accessibility is not a checklist item

The overlap between building for screen readers and building a site that converts is larger than most teams expect.

Accessibility usually enters a project as a line near the bottom of a scope document, right before hosting. It gets treated as compliance — something to satisfy rather than something to build with. That framing is why so many sites pass an automated scan and remain miserable to actually use.

Automated tools catch about a third of it

Scanners are good at what they can see in the markup: missing alt text, low contrast, unlabelled inputs, bad heading order. That's genuinely valuable, and it's roughly a third of the real problem.

The other two-thirds only show up when a person tries: whether focus lands somewhere sensible after a modal closes, whether the error message is announced or just turns red, whether the carousel can be paused, whether the form can be completed without a mouse at all.

The same fixes improve conversion

Every accessibility improvement worth making is also a usability improvement. Larger touch targets help people with tremors and people on a bus. Clear error messages help screen-reader users and everyone who mistyped an email. Real contrast helps low-vision users and anyone outdoors.

Nobody has ever abandoned a form because the labels were too clear or the buttons too easy to hit.

What we do on every build

  • Semantic HTML first: real buttons, real headings, real landmarks, ARIA only where the platform genuinely falls short.
  • Every interactive element reachable and operable by keyboard, with a focus state you can actually see.
  • Color contrast checked in both light and dark themes, not just the one in the mockup.
  • Form errors tied to their inputs and announced to assistive tech, not signalled by color alone.
  • Motion behind prefers-reduced-motion, so the animation is a bonus rather than a barrier.
  • A keyboard-and-screen-reader pass on the critical paths before launch — the part tooling can't do for you.

It adds a little time per page and roughly nothing to the total when it's designed in from the start. Retrofitting it later costs several times more, which is the real argument for not treating it as a checklist item.

Want this applied to your site rather than explained?

Start a Project

Ready to build something that earns its keep?

Tell us about the project. You'll get a straight answer on scope, timeline, and price — usually within one business day, and always before you're asked for anything.

Prefer email? siteandriseweb@gmail.com