Why meaningful accessibility starts with empathy, not compliance
A developer on one of our projects recently proposed a change to how keyboard navigation worked in a complex interactive component — a timeline viewer with multiple navigable sections. The original implementation let users tab between major sections and use arrow keys within them. Standard stuff. Meets WCAG criteria. Check the box.
But there was a wrinkle. When a user was deep inside one section — navigating between decade markers in the timeline, say — and hit shift-tab, the focus jumped all the way back to the slides at the top. Technically correct behavior. The browser’s tab order was being respected. But experientially? Jarring. You’re focused on exploring one part of the interface, and suddenly you’re somewhere else entirely.
The developer’s proposal was to keep the user in the section they were already navigating. If you’re tabbing through decade markers, shift-tab takes you to the previous decade marker — not back to a completely different part of the component. The focus stays within the user’s current context.
I approved it immediately, and here’s why: that proposal respected where the user already was.
This is what I mean when I talk about Empathy as a guiding principle at Johns & Taylor. Empathy in digital experience work isn’t an abstract sentiment. It’s a design discipline. It means imagining yourself into someone else’s interaction — someone who’s navigating with a keyboard because they can’t use a mouse, someone using a screen reader on a 13-inch laptop, someone who’s on their fourth hour of content management and their attention is fraying. And then asking: does this interface respect their context, or does it impose ours?
WCAG compliance is necessary. I’d never argue otherwise. But compliance is a floor, not a ceiling. Meeting the minimum standard means your interface is technically accessible. It doesn’t mean it’s usable. It doesn’t mean it respects the cognitive load your users are carrying. It doesn’t mean it works the way a human would expect it to work.
The distinction between compliance and empathy shows up in how you frame the question. Compliance asks: “Does this meet the standard?” Empathy asks: “Does this reduce the cognitive load of unexpected behavior?” One is a checklist. The other is a perspective.
We’ve started applying this perspective across everything we build for our enterprise clients. When we’re designing keyboard navigation, we don’t just map the tab order and call it done. We walk through the component as a keyboard user and ask: at each point in this interaction, where would I expect focus to go next? If the answer is different from where focus actually goes, we have a problem — even if we technically pass an automated accessibility audit.
This extends beyond keyboard navigation. When we were analyzing viewport data for a responsive design decision, one of the factors that influenced our recommendation was discoverability. At certain viewport widths, content that was clearly visible on a wider screen became accessible only by scrolling. Technically still there. Technically still reachable. But a user who doesn’t know it exists won’t scroll to find it. That’s an accessibility gap that no automated tool will catch, because the content is present in the DOM. It’s just invisible to the person who needs it.
The hardest part about building for empathy is that it requires judgment. You can’t reduce it to a checklist or automate it with a linting rule. It requires someone on the team to pause and think: what is this person’s mental model right now? What do they expect to happen? And does our implementation honor that expectation or violate it?
I think this is why accessibility work sometimes gets treated as a specialist concern — something you hand off to the person with the WCAG certification and hope they catch everything. But the most accessible products I’ve worked on were built by teams where everyone thought about cognitive load, not just the accessibility lead. The developer who proposed the keyboard navigation change wasn’t an accessibility specialist. He was a developer who thought about what would feel right to a user navigating his component.
That’s empathy in practice. Not a compliance report. Not a remediation sprint. A developer asking: where is my user right now, and how do I keep them there?
Meet the standard. Then exceed it — in the direction of the human being on the other side.
