Ask Your Dev Team about accessibility

If your product has a website or app that people use, accessibility should be part of the conversation. For some businesses, it’s not optional. It’s a legal requirement.

What is web accessibility?

Web accessibility means building your product so that people with disabilities can use it. That includes people who are blind or have low vision, people who are deaf or hard of hearing, people with motor impairments, and people with cognitive disabilities.

In practice, this means things like:

• Screen reader support: Blind users rely on software that reads the content of a page aloud. Your application needs to be structured so that software can interpret it correctly.
• Keyboard navigation: Not everyone uses a mouse. Some users navigate entirely with a keyboard. Every interactive element, buttons, forms, menus, should be reachable and usable without a mouse.
• Color contrast: Text needs to have enough contrast against its background to be readable by people with low vision or color blindness. If your call-to-action button is light gray text on a white background, that’s a problem.
• Captions and alt text: Videos need captions. Images need descriptive text. These aren’t extras. They’re how entire groups of users experience your content.

It’s not optional for everyone

The Web Content Accessibility Guidelines (WCAG) are the industry standard for measuring accessibility. In the United States, the Americans with Disabilities Act (ADA) has been interpreted by courts to apply to websites and digital products. That means businesses can and do face lawsuits over inaccessible websites.

If you’re in healthcare, education, government, financial services, or any industry that serves the public, accessibility compliance is likely a requirement. Your developer should know whether this applies to you. If they don’t bring it up and your product is public-facing, ask.

”It looked right to me” isn’t good enough

Here’s the problem with accessibility: a website can look perfectly fine to someone with full vision sitting at a desk with a mouse and still be completely unusable for someone navigating with a keyboard and a screen reader.

Accessibility issues are invisible to developers who aren’t testing for them. And “we looked at it” is not the same as “we tested it.” A developer who tells you the site is accessible because it looks fine has not actually verified anything.

Ask your developer: “How do you test for accessibility?”

You’re looking for a combination of:

• Automated tools: There are scanners that check for common accessibility issues like missing alt text, insufficient color contrast, and improper heading structure. These catch the obvious problems quickly.
• Manual testing: Automated tools can’t catch everything. A developer should also be testing with a keyboard, checking that focus states work correctly, and verifying that screen readers can navigate the page in a logical order.
• Real user testing: The gold standard. Some teams include users with disabilities in their testing process. This isn’t always feasible, but it’s the most reliable way to know if your product is actually usable.

If they’re doing none of the above, you’re exposed. If they’re running automated scans but never touching a keyboard, they’re catching maybe half the issues.

What to expect

A developer who takes accessibility seriously will:

• Raise it early in the project, especially if your industry has compliance requirements
• Build accessible components from the start, not retrofit them later
• Include accessibility checks in their regular testing process
• Be able to point to a specific standard they’re building against, usually WCAG 2.1 AA

Retrofitting accessibility after launch is expensive and painful. Getting it right from the beginning is significantly cheaper and protects you from both legal risk and reputational damage.

---

Expect better. Build better.