Skip to content

Category: Testing

A11y 101 – 4.1.3 Status Messagesa cute dog wearing plaid cap

A11y 101 – 4.1.3 Status Messages

Published on August 31, 2026

In the Sherlock Holmes story “Silver Blaze,” the key clue is that a dog did nothing. The dog didn’t bark when an intruder entered. That silence was the evidence.

Your website has the same problem.

A user submits a form. The page doesn’t reload. A loading spinner appears. It vanishes. Something happened—maybe success, maybe failure, maybe the system just gave up. But nothing spoke. Nothing announced. The status message was painted on the screen for sighted users and completely invisible to anyone who couldn’t see it.

Continue readingA11y 101 – 4.1.3 Status Messages
Comments closed
A11y 101 – 4.1.2 Name, Role, Valuewooden blocks displaying hello world

A11y 101 – 4.1.2 Name, Role, Value

Published on August 24, 2026

Here’s the thing about screen readers that most developers never learn until it’s too late: they don’t see what you see. They don’t render pixels. They don’t read CSS. They read the accessibility tree.

And if your HTML is a <div> with a click handler and no label, the accessibility tree has nothing to say. To a screen reader, that <div> doesn’t exist.

That’s the core problem WCAG 4.1.2: Name, Role, Value addresses. And honestly, it’s the single most important criterion for making your interface visible to assistive technology.

Continue readingA11y 101 – 4.1.2 Name, Role, Value
Comments closed
A11y 101 – 3.3.7 Redundant Entrysymmetrical industrial control panel in tbilisi

A11y 101 – 3.3.7 Redundant Entry

Published on August 10, 2026

You’re shopping online at your favorite store. You set up an account for future visits. You fill out your name, email, shipping address, billing info, card details. You save the info.

You start shopping and add some items to the cart. The checkout form asks for all that information again. Name, email, address, card. All of it. Fresh blanks.

You stare at the screen. “Didn’t you already know this?”

Continue readingA11y 101 – 3.3.7 Redundant Entry
Comments closed
A11y 101: 3.1.1 Language of Pagesign on the embassy of japan in different languages
A11y 101: 2.5.8 Target Sizered and brass dart pin on dartboard
A11y 101: 2.5.7 Dragging Movementsdragon statue on buddhist temple rooftop

A11y 101: 2.5.7 Dragging Movements

Published on March 30, 2026

Picture this: You’re trying to reorder items in a list. The interface wants you to click, hold, drag the item to a new position, and release. Seems intuitive, right? Now imagine you have a tremor in your hand, or you’re using a trackpad with limited precision, or you’re navigating with a single switch device. Suddenly, that “simple” drag-and-drop becomes an exercise in frustration.

This is exactly what WCAG 2.5.7: Dragging Movements is trying to fix.

Dragging Isn’t Universal

The rule says:

Any functionality that requires dragging movements (click-and-hold, drag-to-reorder, swipe-to-delete, etc.) must also be operable with a single pointer action without dragging.

In plain English: If you can do it by dragging, you should also be able to do it by clicking, tapping, or using buttons.

Precision Isn’t Everyone’s Friend

Dragging movements assume a level of motor control that not everyone has:

  • Fine Motor Impairments: Users with conditions like Parkinson’s, cerebral palsy, or arthritis may struggle with the sustained pressure and precise movement dragging requires.
  • Assistive Technology Users: Switch devices, eye-tracking systems, and head pointers often can’t perform traditional drag operations.
  • Temporary Disabilities: A broken wrist or sprained finger can turn a simple drag into an impossible task.

The goal of 2.5.7 isn’t to eliminate drag-and-drop. We’re trying to ensure that everyone has a way to accomplish the task, regardless of their physical abilities.

Focus on User Needs

When you design a feature that only works with dragging, you’re implicitly saying: “If you can’t drag, you can’t use this.” That’s not a UX decision. It’s a decision to exclude users.

Ask yourself: If I were navigating this site with a single switch, would I be able to reorder this list? If the answer is “no,” you aren’t just failing a criterion; you’re failing the person who needs the feature the most.

Common Pitfalls (And How to Fix Them)

I’ve seen this fail in a few classic ways during audits:

  1. The Drag-n-Drop List:
  2. The Swipe-to-Delete:
    • Offer up a checkbox and delete button.
  3. The Canvas Drawing Tool:
    • This is difficult and relies on implementing a grid system for navigation. I detail this more in 2.5.1 Pointer Gestures.

Conclusion

2.5.7 is a reminder that convenience shouldn’t come at the cost of access. Drag-and-drop can be a great feature, but it should never be the only way to accomplish a task.

Comments closed
A11y 101: 2.5.4 Motion Actuationclose up of dog shaking water

A11y 101: 2.5.4 Motion Actuation

Published on March 23, 2026

Imagine you’re holding your phone, walking down the street, and you accidentally bump it against your leg. Suddenly, your app thinks you’ve shaken it into submission and deletes your entire shopping cart. Or maybe you’re trying to scroll, but the device interprets your hand tremor as a “shake to undo” command.

This isn’t just a quirky feature gone wrong; it’s a potential accessibility nightmare. Enter WCAG 2.5.4: Motion Actuation.

Continue readingA11y 101: 2.5.4 Motion Actuation
Comments closed
A11y 101: 2.5.2 Pointer Cancellationan animation of pointing finger on a black background

A11y 101: 2.5.2 Pointer Cancellation

Published on March 2, 2026

Last week I wrote about gestures and pointers. This week we look at the next criteria, Pointer Cancellation. I mentioned that we wanted events to fire on the “Up” or “release” action. And that’s what this criteria is all about. We need to make sure that if a user creates a down event on a control, we need to allow them to cancel. Let’s look at the methods used.

Continue readingA11y 101: 2.5.2 Pointer Cancellation
Comments closed
A11y 101: 2.4.11 Focus Not Obscured (Minimum)man sitting on a wheelchair
A11y 101: 2.4.7 Focus Visibleround mirror

A11y 101: 2.4.7 Focus Visible

Published on November 17, 2025

Disabilities come in all sorts. So do users. Some users can manipulate a mouse. Some rely on keyboard alone. Others have assistive technology. When you use a mouse, where your mouse is located is visible. This lets the sighted mouse user know what they are clicking on and where the focus is. Keyboard only users need something else. Let’s get into the details of what is needed.

Continue readingA11y 101: 2.4.7 Focus Visible
Comments closed