Accessibility is a sales issue, not a checkbox

Accessibility often gets filed under compliance. Something legal asks about, something to fix later, something a plugin claims to handle. I think that framing undersells it.

When a visitor cannot read your text, cannot reach your menu with a keyboard, or cannot tell which form field is which, they do not file a complaint. They leave. That is a lost lead, not a technicality.

Who this actually affects

Disability is common, and much of it is not visible. People with low vision, color blindness, tremors, dyslexia, hearing loss, or cognitive fatigue use the web every day. So do people with temporary injuries, older customers whose eyesight has changed, and anyone using a phone in bright sunlight.

Many of the decision-makers you are trying to reach fall into these groups at some point. Designing for them is not designing for a niche. It is designing for a large, ordinary slice of your market.

What WCAG 2.2 AA means in practice

WCAG, the Web Content Accessibility Guidelines, is the widely used standard for web accessibility. Version 2.2 is the current release, and level AA is the target most organizations and policies refer to.

The guidelines are long, but most of what they ask for comes down to a handful of practical habits:

• Contrast. Text needs enough contrast against its background to be readable. Pale grey on white is the most common failure I see.
• Keyboard access. Everything you can do with a mouse should be possible with a keyboard alone: menus, forms, sliders, popups, and checkout.
• Visible focus. When someone tabs through the page, they need to see where they are. Removing the focus outline for looks breaks this.
• Labels. Every form field needs a real label that stays visible, and error messages should explain what went wrong and how to fix it.
• Captions and transcripts. Video needs captions; audio needs a transcript.
• Reduced motion. Animations should respect the system setting that asks for less motion, because large movement can cause real discomfort.
• Target size. Buttons and links need to be large enough to tap without precision. WCAG 2.2 added a specific minimum for this.
• Structure. Headings, landmarks, and link text should make sense to someone using a screen reader, so "click here" is not the only clue.

None of this requires an unattractive site. Good accessibility mostly looks like good design: clear type, clear hierarchy, clear actions.

Why buyers care

For companies that sell to larger organizations, accessibility increasingly shows up in procurement. Public sector bodies, universities, and many enterprises ask vendors about accessibility as part of their review. Some request a conformance report or ask which WCAG level you meet.

If your marketing site fails basic checks, it raises an uncomfortable question about your product and your attention to detail. If it passes, that is one fewer objection in a long buying process.

Buyers notice when a company has done the work. It signals care in the same way a clear contract or a fast reply does.

The legal side

In the United States, lawsuits and demand letters over website accessibility under the Americans with Disabilities Act are common, and they are not limited to large companies. Other regions have their own requirements, and the rules continue to develop. I am not a lawyer and this is not legal advice, but the practical point is clear: fixing accessibility early is far cheaper and calmer than fixing it under pressure.

One caution. Overlay widgets that promise one-line compliance do not fix underlying problems in your code, and they can get in the way of people who rely on their own assistive tools. Real accessibility is built into the templates.

A quick self-check

You can learn a lot in half an hour without any special software. Try this on your homepage, a key service page, and your contact form.

1. Put your mouse away and press Tab from the top of the page. Can you reach every link and button, and can you always see where you are?
2. Open the main menu and any popups using only the keyboard. Can you close them again with Escape?
3. Fill in your contact form by keyboard. Does every field have a visible label? Submit it with an error. Is the message clear?
4. Zoom the browser to 200 percent. Does the content still fit and read properly without horizontal scrolling?
5. Look for light grey text, text over busy images, and buttons distinguished by color alone.
6. Play any video with the sound off. Are there captions?
7. Turn on your device's reduce-motion setting and reload. Do large animations stop?
8. Read just your link text out of context. Does each one make sense on its own?

If several of these fail, you have a clear starting list. A proper audit with screen reader testing will find more, but these checks catch many of the issues that most often stop real visitors.

Making it stick

Accessibility is easiest when it is part of the build rather than a pass at the end. That means accessible components, a color palette tested for contrast, form patterns that handle errors well, and a content process that includes alt text and captions as standard. It also means checking again whenever new templates or features are added.

The takeaway: treat accessibility as part of how your site sells. Run the self-check, fix what fails, and build the standard into your templates so it stays fixed. To see how WCAG 2.2 AA is handled on a build, read about accessibility.