Hetal Gohil
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.
