Accessibility used to come up in our projects mostly as a client afterthought — a request to “make sure it's accessible” added near the end of a project, usually meaning nobody had thought about it seriously until then. We've changed how we approach this, partly because retrofitting accessibility into a finished design is genuinely harder and more expensive than building it in from the start, and partly because it's simply the right thing to get right the first time.
The basics that catch the most real issues
Color contrast is the most common failure we find in existing designs, and it's one of the easiest to prevent — text on a background needs enough contrast to be readable by users with low vision, and a lot of trendy light-gray-on-white or pastel-on-pastel design choices fail this outright. We check contrast ratios against WCAG guidelines as a standard part of design review now, not as a separate accessibility pass at the end.
Keyboard navigation is the other big one, and it's the fastest way to find real problems: try to use the entire site or app without touching a mouse or trackpad. Interactive elements that can't be reached or activated by keyboard alone are invisible to anyone using assistive technology, and they're also invisible to a sighted developer testing normally with a mouse, which is exactly why this needs a deliberate, separate check rather than relying on normal QA to catch it.
What gets missed even by teams trying to do the right thing
Alt text on images is widely known as an accessibility basic, but it's often done poorly even when it's present — generic alt text like “image” or a filename tells a screen reader user nothing useful about what's actually being shown. We write alt text that describes what the image is actually communicating in context, the same discipline we'd expect from real image captions, not just a technical checkbox to satisfy an automated audit tool.
Form errors are another common gap — a form that shows a red border around an invalid field but no text explanation of what's wrong communicates nothing to a screen reader user, and often not much to a sighted user either. Every form we build now pairs a visual error indicator with a clear, specific text message, associated with the field programmatically, not just placed nearby on the page.
Why we build this in from the start now
Beyond it being the right thing to do, there's a practical business case too — accessibility lawsuits against businesses with inaccessible websites have become increasingly common, and a site built with these basics in mind from the start is far cheaper to defend or fix than one retrofitted after a complaint. We treat this checklist as a standard part of every project now, the same way we treat mobile responsiveness — not an optional add-on, but a baseline requirement for calling a project done.
Testing with an actual screen reader, not just a checker tool
Automated accessibility checkers catch maybe a third of real issues — they're good at flagging missing alt text or insufficient contrast ratios, but they can't tell you whether a screen reader user can actually complete a checkout flow without getting lost, or whether a custom dropdown component that looks fine visually is announced coherently to assistive technology. We now do a manual pass with a real screen reader — VoiceOver on Mac, NVDA on Windows — on every project's core user flows before calling accessibility work done, specifically because this is where the automated tools' blind spots consistently show up.
This manual pass routinely finds issues an automated scan gives a clean pass on: a modal that traps keyboard focus correctly but never announces itself as a modal when it opens, an icon-only button with no accessible label because a developer assumed the icon was self-explanatory, a form that submits successfully but never confirms that success to a screen reader user in a way they can perceive. None of these fail an automated checker's rules, and all of them make the product genuinely unusable for someone relying on assistive technology.
Making accessibility a design-review checkpoint, not an afterthought
The projects where accessibility ends up genuinely solid are the ones where it's checked at the design stage, before a single line of code is written — reviewing color contrast in the mockups, confirming a logical reading and tab order is possible given the proposed layout, checking that interactive elements are large enough for reliable touch targets. Catching a contrast issue in a Figma file costs a five-minute palette adjustment. Catching the same issue after development, once colors are hard-coded across dozens of components, costs considerably more. We added an accessibility checklist to our design review template specifically to move this cost to the cheapest point in the process, rather than the most expensive one.
None of this requires a specialist accessibility consultant for most projects — it requires building the checks into the process everyone already follows, at the point where they're cheapest to act on. The teams that treat it this way rarely think of accessibility as extra work at all; it's just part of what “done” means.
We also push back gently when a client's brand guidelines conflict directly with accessibility basics — a brand palette with insufficient contrast, for instance. The right move is usually a slightly adjusted shade that still reads as on-brand rather than accepting a contrast failure outright, and most clients are receptive to this framing once it's explained as a usability issue for real visitors rather than an abstract compliance checkbox.
