Drupal

You're checking out on an e-commerce site for the tenth time this month. You start typing your shipping address... and your browser suggests the wrong address. You're trying to enter your work email, and it keeps suggesting your personal email. You give up and type everything manually, again.

Or maybe you're someone with a cognitive disability who struggles to remember your address. Your browser could help you fill in forms automatically - but only if the website tells the browser what kind of information each field expects.

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.

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.