Advent 2025 - 24 days of accessibility

We've spent the past two weeks discussing accessibility standards - what they mean, why they matter, and how to implement them. But there's a gap between knowing what to do and actually doing it consistently. Content editors add images without alt text. Headings get used for styling instead of structure. Links say "click here" instead of describing their destination.

You can make text look like a heading with CSS - increase the font size, make it bold, add some spacing. Visually, it looks perfect. But to a screen reader, it's just regular text. The structure and meaning that's obvious to sighted users is completely lost.

This is the essence of WCAG 1.3.1: information, structure, and relationships that are conveyed through visual presentation must also be available programmatically - in the code itself.

You've probably seen them: that little circular icon in the bottom corner of a website that opens a menu promising to make the site accessible. Install one line of JavaScript, and your site becomes "100% ADA compliant" and "protected from lawsuits." It sounds too good to be true.

That's because it is.

I'll be honest: before researching this post, audio description was the accessibility standard I knew the least about. I understood captions for deaf users - that's straightforward. But audio description? I knew it existed, but had never actually implemented it or really understood when it was necessary.

Picture someone with a tablet mounted on their wheelchair in landscape orientation. They navigate to your site, but it forces portrait mode, making it impossible to use without physically rotating their mounted device - something they can't easily do. Or imagine someone with low vision zooming their browser to 400%, only to find they now have to scroll horizontally to read every single line of text.

If you know anything about web accessibility, you probably know about alt text. It's the most widely recognized accessibility technique - that little text description you add to images so screen readers can announce what the image shows. But there's more to non-text content accessibility than just slapping some alt text on every image and calling it done.

Let's dig into what you might not know about making images, icons, charts, and other non-text content accessible.

You hover over an icon to see what it does, and a helpful tooltip appears. But before you finish reading it, you accidentally move your mouse slightly and the tooltip vanishes. Or you're using a screen magnifier and the tooltip appears, but it's positioned right under your mouse pointer, making it impossible to read the magnified version. Or you're navigating with a keyboard, the tooltip appears when you tab to a button, but you can't move your mouse over the tooltip text to select and copy it.

Imagine clicking "Submit" on a legal contract, only to realize you meant to click "Save Draft." Or transferring $1,000 to the wrong account with no confirmation step. Or deleting your entire photo library with a single misclick. These aren't hypothetical scenarios - they happen every day when websites don't implement proper error prevention.

You've probably encountered this scenario: you land on a form with a single text box. No label, just a placeholder that says "Search..." which disappears the moment you click. Or maybe you've seen a password field that rejected your entry, only to discover afterward that it required at least 12 characters, one uppercase letter, one number, and a special symbol - requirements that were mentioned nowhere near the field itself.

These frustrating experiences aren't just bad design - they're accessibility barriers. And they affect everyone, not just people using assistive technology.

You click "Add to Cart" and a little notification pops up: "Item added!" You submit a form and see "Thank you, your message has been sent." You start typing in a search box and results appear below as you type. These instant feedback messages are everywhere on modern websites - but are they accessible to everyone?

For sighted users, these visual cues are obvious. But for someone using a screen reader, these dynamic updates can be completely invisible unless they're coded properly. The page content changed, but their screen reader said nothing about it.

Picture this: you're reading an article on your phone, or maybe you're at your desktop after a long day of staring at screens. The text is just a bit too small, making your eyes work harder than they should. You zoom in... and suddenly half the content disappears off the side of the screen, or worse - text overlaps and becomes completely unreadable.

Have you ever tried to fill out a form on a website using only your keyboard? Maybe your mouse died, or you're working on a laptop with a finicky trackpad. You hit Tab to move from field to field, and suddenly you're jumping all over the page, or worse - you have no idea which field you're actually in.

This is the daily reality for many keyboard-only users, including people who use screen readers, people with motor disabilities who rely on keyboard navigation, and power users who simply prefer keyboard shortcuts for efficiency.