Web accessibility means building a site so people with a wide range of abilities can use it: read the text, understand the layout, navigate the menu, and complete a form, regardless of eyesight, hearing, motor control, or how they process information. It matters for a straightforward reason: the people trying to use a site vary widely. They arrive with different bodies, different tools, and different circumstances, and a site built for only one version of “normal” quietly shuts a real portion of them out. That shows up in lost revenue, in search rankings that favour well-structured, readable pages, and in legal exposure under standards like the ADA and AODA. It also shows up in something simpler: whether the work a design team put months into ever reaches the people it was meant for.
The number people skip past
More than one billion people worldwide live with some form of disability, and that figure only grows as the population ages. Reduced eyesight, color blindness, motor impairments, hearing loss, cognitive differences, temporary injuries, a broken arm, a bright afternoon glare on a phone screen, a toddler asleep on one arm while someone tries to scroll one-handed. Accessibility gets filed under “nice to have” or “compliance issue” so often that people forget how wide the range of human bodies and situations really is. Every one of those situations touches how someone reads, clicks, scrolls, or fills out a form.
Designing for that range is a way of meeting the actual conditions people live and browse in, rather than a favor to a minority of users.
The business case, stated plainly
An inaccessible site loses revenue, quietly, every day, with no error message telling anyone why.
A shopper who is unable to complete checkout with a keyboard leaves and buys somewhere else. A reader who struggles to parse a wall of low-contrast gray text on white gives up halfway through a page that took hours to write. A customer with a screen reader who hits an unlabeled “submit” button seventeen times in a row rarely calls to complain. They close the tab instead.
None of this shows up as a bug report. It shows up as a slow leak in conversion rates that a team spends months trying to explain with A/B tests, when the real answer was sitting in the markup the whole time.
There is also a legal dimension worth naming honestly. Lawsuits over web accessibility under the ADA or AODA have climbed for years, and small and mid-sized businesses are increasingly named alongside large enterprises. Accessibility work done early is design work. Accessibility work done after a demand letter arrives is expensive, rushed, and adversarial.
What accessibility covers, specifically
Accessibility spans several distinct areas, and most sites fall short in more than one at once:
- Visual: color contrast between text and background, font size and spacing, content that reads clearly when zoomed to 200%, and design that never relies on color alone to convey meaning (a red border on an error field, with no text label, fails for anyone with color blindness).
- Motor: buttons and links large enough and spaced far enough apart for a hand with limited fine motor control, full functionality available through a keyboard alone, and no interactions that demand a precisely timed click or drag.
- Auditory: captions on every video, transcripts for audio content, and visual alternatives to any sound-based alert or notification.
- Cognitive: plain language over jargon, a consistent layout from page to page, and forms that explain errors in plain terms rather than a vague red highlight.
- Screen reader/assistive tech: meaningful alt text on images, a logical heading structure, labeled form fields, and a tab order that follows the visual flow of the page.
- Legal/standards: alignment with the Web Content Accessibility Guidelines (WCAG), the technical standard referenced by the ADA and most accessibility litigation.
Each of these areas gets tested differently, and a site can pass one while failing several others. A page can hit strong contrast ratios and still be unusable with a keyboard alone. Real accessibility work checks all of them, together, rather than treating any single area as the whole picture.
What good accessibility work looks like
Good accessibility shows up as:
- Text that holds enough contrast against its background to read in direct sunlight and on an old monitor alike.
- Buttons and links large enough and far enough apart that a hand with limited motor control can tap the right one on the first try.
- Forms that speak their errors out loud to a screen reader instead of relying on a red outline nobody using that tool will ever see.
- Video with captions built in from the start, rather than bolted on as an afterthought.
- Headings that follow a real hierarchy, so someone navigating by heading alone can find the section they need in three keystrokes instead of scrolling through everything.
None of this is exotic. Most of it is the kind of front-end discipline that also happens to make a site faster, cleaner in its code, and easier to maintain a year later. Accessible sites and well-built sites overlap so heavily that fixing one usually improves the other.
Where AI tools help, and where the trained eye still has to step in
Design and development tools are getting faster at flagging accessibility problems. Automated contrast checkers, alt-text generators, and linting tools catch a meaningful share of issues before a human ever looks at the page. That is real progress, and we use those tools daily.
But automated checks catch what can be measured. They cannot tell you if an alt-text description is genuinely useful to someone who has never seen the image, or if a form’s tab order matches how a real person would move through the page in practice, or if a “skip to content” link lands somewhere that makes sense. The tool flags the technical failure. The person using the tool has to understand what the experience feels like from the other side of the screen. The eye trained on real users, alongside real code, is what turns a passing audit into a site that people can genuinely use.
The short version
Accessibility works best as an ongoing lens, rather than a checklist to run through once before launch. It is a lens a design team keeps on through every decision: the font, the color, the button size, the form, the video. Build with that lens on from the start, and the site works for more people, ranks better, converts better, and holds up better under legal scrutiny, all from the same set of decisions.
That is the kind of work we build into every project at jamn, as a starting principle rather than an add-on, part of how a site gets designed in the first place.
