Drupal Planet

You're filling out a multi-page application form - carefully reviewing each section, gathering documents, double-checking information. Suddenly, a popup appears: "Your session has expired. Please log in again." All your work is gone. You have to start over.

Or you're reading an important article when an auto-playing carousel sweeps the content away before you finish reading it. You try to find the pause button, but there isn't one - the carousel just keeps cycling, forcing you to time your reading to match its pace.

You're checking out on an e-commerce site. You click Submit, and the page reloads with an error message at the top: "There were errors in your submission." That's it. No indication of which fields have problems. No explanation of what's wrong. You start hunting through the form, checking each field, trying to figure out what went wrong.

This frustrating experience is unfortunately common, especially on e-commerce sites, membership portals, and complex forms. But it's also completely avoidable - and fixing it makes your site accessible and more usable for everyone.

Last week, the Trump administration argued in court that providing ASL interpretation at White House briefings "would severely intrude on the President's prerogative to control the image he presents to the public." The National Association for the Deaf has sued to restore real-time ASL interpretation.

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 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.