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

Earlier this year, I was working with a client on an interactive ticketing site. We were troubleshooting an issue related to the pan and zoom controls, which were designed to help users select their seats on a seating map. Above 200% browser zoom, the pan controls disappeared entirely. The obvious fix seemed to be keeping the controls visible at all zoom levels. However, at high zoom levels, the map itself takes up most of the viewport. Persistent controls would block the very interface users were trying to navigate.

No WCAG pattern addressed this use case. No established solution existed.

This is a testing gap that no one seems to talk about. WCAG is comprehensive, but it wasn’t written for every interface being built today. Novel interactions, complex components, and edge cases fall outside what the guidelines directly address. And when teams hit this wall, they react in one of two ways: they freeze, or they declare that WCAG compliance simply doesn’t apply to their unique circumstances. Neither reaction helps to get a solution shipped so users can complete the task.

The solution is first principles reasoning. Instead of asking “what pattern applies here?” ask “what does the user actually need to accomplish?” That question cuts through the complexity and gives you a starting point.

I call this framing the problem. It’s the first phase of working through novel accessibility challenges, and it has three steps.

Step 1: Confirm you’re in uncharted territory.
Check the W3C Pattern Library. Search the web for established patterns. If nothing directly applies, you’re working from first principles.

Step 2: Define the core user need.
Strip away the interface. For the seating map, the user needs to select a seat. Pan and zoom are tools to help them do that, not the goal itself. Start there.

Step 3: Identify non-negotiable accessibility constraints.
Even without a pattern, some things always apply. Keyboard access. Screen reader announcements. Focus management. These are your guardrails regardless of how novel the solution ends up being.

Now, framing the problem doesn’t solve it, but it does give you something concrete to work with instead of staying stuck.

Next week (in part two), we’ll talk about how to build and validate a solution when no pattern exists.