Use the arrow keys to navigate between menu items.

Actually accessible

2 minutes read

The Web Content Accessibility Guidelines (WCAG) give you a checklist to follow. They tell you what not to do wrong. Most people stop there.

These guidelines focus on avoiding mistakes, with the understanding that avoiding these mistakes results in an accessible product. They're not wrong. But it's an incomplete picture.

It's unfortunate it's become best practice to simply follow it and stop when you check the box.

The guidelines are about following procedures correctly. But just because your site passes a WCAG audit doesn't mean people with disabilities will be able to use it.

The bigger problem?

WCAG doesn't help your team implement these guidelines efficiently. There's no roadmap for designers and developers to follow. No clear workflow that makes accessibility part of your process rather than an afterthought. In fact, most of the time, most of the guidelines are applied at the end of the process. This defeats the purpose.

You end up with a team scrambling to fix accessibility issues right before you ship.

I started making a shift from compliance to usability. From avoiding errors to creating better experiences for everyone. Because at the end of the day, that's what really matters.

Here are five specific methods I use:

  1. Run user testing sessions with people with disabilities. Every sprint if possible. Don't just rely on automated tools. Watch real users interact with the product and identify pain points that pass WCAG but fail the real world scenario.
  2. Create accessibility personas with specific needs. Include at least the following: screen reader user, keyboard-only user, user with dyslexia. During planning, look at features from these personas' perspectives.
  3. Build an accessibility component library. Designers and developers can access approved, tested elements rather than reinventing accessible solutions for each feature.
  4. Implement paired accessibility reviews. Get devs and designers into the same room and have them check each other's work against real-world scenarios, not just technical requirements.
  5. Integrate accessibility into your definition of "done." No feature should be considered complete until you've tested it with assistive technologies like screen readers or keyboard navigation.

Did you enjoy this bite-sized message?

I send out short emails like this every day to help you gain a fresh perspective on accessibility and understand it without the jargon, so you can build more robust products that everyone can use, including people with disabilities.

You can unsubscribe in one click and I will never share your email address.