As a developer, I love solving problems. But when I leaned into accessibility, I discovered a new appreciation for the elegance of HTML.

All the layers of backend and frontend engineering are invisible to screen readers. What remains is structure and semantics—HTML and the DOM. Marshall McLuhan was right: the medium is the message.

If a person’s access is mediated by a small set of tools—screen readers, braille displays, voice interfaces—the message may not get through at all.

That’s what draws me to accessibility engineering: when the medium finally speaks clearly, it’s an honour to have helped shape that moment.

But sometimes, the code meant to help becomes a burden.

Like the time I made my main menu keyboard-navigable using arrow keys, submenu toggles and clear focus indicators. But my changes caused the NVDA screen reader to announce: “Menu of 8 items. 2 of 8.” Then again. And again. Every time focus changed.

I had outsmarted myself.

Yes, the menu was technically accessible—but it was also noisy, repetitive, and frustrating. I was shouting at the screen reader with JavaScript when all it really needed was clean, semantic HTML.

The truth is, I couldn’t get away from JavaScript entirely. The flyout menu that shipped with the theme already needed a script to function with a mouse. So I wrote loops, conditionals, and focus traps to make it work for arrow keys, screen readers, and people tabbing around. It did the job, but it did too much — repeating announcements, layering ARIA attributes that clashed with each other, and adding friction where there should’ve been none.

It taught me that when you can’t avoid complexity, you have to manage it carefully. Accessibility work keeps reminding me that elegance isn’t always in doing more—it’s in doing just enough to send the message. Extra logic should support the native HTML, not override it. Most of my career has been in full-stack and frontend engineering, solving structural problems. But in accessibility, I’m still unlearning old habits—replacing cleverness with clarity.

The first time I found the W3C Validator, I fell in love with standards. From CSS to WCAG, from Typo3 to Drupal, I’ve chased that promise: that well-structured code can scale meaningfully. Today, I write that code with a different intention—not just to build, but to make the web speak clearly to everyone.