What to do when WCAG doesn’t have an answer (Part 2)

Last week, I introduced first principles reasoning as a way to tackle accessibility problems where no WCAG pattern exists. We covered the first phase, framing the problem, which provides a foundation to work from (steps 1-3). This week, we are going to look at how to actually build and validate a solution (steps 4-6).

Step 4: Look for analogous patterns.
You may not find an exact match, but something similar probably exists. For the seating map, the challenge was keeping pan controls accessible without blocking the map at high zoom levels. Google Maps solves a similar problem with a compact controls button that reveals a full panel as an overlay when tapped. We borrowed that approach and adapted it for the seating map context.

Step 5: Test with actual users.
An unconventional solution needs validation. We prototyped the compact controls overlay and tested it with real users, including people who rely on browser zoom. The goal wasn’t to confirm we were right. It was to find out where the solution broke down before shipping it.

User testing is what separates a reasonable guess from a validated solution. Without it, you’re essentially still guessing. Feedback and refinement are essential.

Step 6: Document and share what you learned.
New solutions become established patterns when people write them down. If you solve a problem in a new way, document your reasoning, your prototypes, and your test findings. Publish it. Share it with the community.

The UX patterns we rely on today exist because someone solved a novel problem and wrote about it. Your solution might be someone else’s starting point.

When WCAG doesn’t have the answer, first principles give you a path forward. Frame the problem, solve it, and share what you learned. It feels great to solve real-world problems and pass on your understanding to others.