2 minute read

WCAG 4.1: Compatible

Break barriers, not compatibility.

Big text that reads "Video coming soon!" over a cloudy blue sky. There are retro televisions floating around, with a multi-colored "Please stand by" static image on screen. Taffy the Siamese cat is looking up from the bottom of the image.

Script preview

When you click a button or select an option, you expect it to just work, right? But behind the scenes, there’s a layer of code making it all happen. For users relying on assistive technologies, like screen readers or voice commands, that code isn’t just important—it’s everything. 

Welcome to What in the World is WCAG? 4.1 Compatible.

Parsing (Obsolete and removed)

Let’s bid a fond farewell to Parsing, one of the original WCAG criteria that’s now officially retired. Parsing was designed to ensure that code was error-free enough for user agents—like browsers and assistive technologies—to process it without breaking. Essentially, it was all about clean, consistent HTML.

Let the happy feelings wash over you. 

Anyway, in WCAG 2.2, Parsing was retroactively set to “always passes” under WCAG 2.1 and completely removed in 2.2. Why? Modern browsers and tools have become much better at handling messy or imperfect code, making this criterion less relevant for today’s web.  Hey, it’s that ROBUST principle in action!

Name, Role, Value

Let’s talk about screen readers and how they make sense of a website. Every interactive element—like buttons, checkboxes, or menus—needs to provide three key pieces of information:

  1. Its name—what it is,
  2. Its role—what it does, and
  3. Its value—its current state.

Here’s a dropdown menu. A screen reader should announce: “Menu collapsed” when it’s closed, and “Menu expanded” when it’s open. Make sense?  Links do the same thing.  “Read more about Taffy, link, unvisited.”

This success criterion ensures that interactive elements are coded clearly and consistently, so assistive tech knows exactly what to do. And what’s that old saying? If it ain’t broke, don’t fix it. This one’s mostly for people coding their own components—if you’re using HTML and ARIA appropriately, you’re probably already covered.

Status Messages

There’s lots of little visual cues you probably rely on without noticing. Whether it’s a number change on a shopping cart icon when you add an item, or a progress bar slowly ticking along, these status messages need to be available to people who can’t perceive them visually, too.

Important updates like “5 search results” or “upload complete” need to be coded so that assistive technologies can announce them properly. This is all about keeping everyone informed, no matter how they interact with your website.

Compatible: Break barriers, not compatibility.

Previous articleNext article
Back to top