You submit a form. An error flashes: “Invalid.” That’s it.
Invalid what? Invalid how? Invalid because you used the wrong format, or invalid because the email is already taken, or invalid because the server had a seizure and forgot what an email even is?
For all the user knows, the system is lying. The form is broken. They’re blocked, with nowhere to go.
That’s where WCAG 3.3.3: Error Suggestion comes in. And its message is simple: tell people how to fix it.
Comments closedBefore I Can Fill It, I Need to Know What You’re Asking
There’s a form I encountered recently that had twelve fields. No labels. Just placeholder text inside each input that disappeared the moment you started typing. If you forgot what a field was asking for, you had to delete everything you’d entered just to see the hint again.
Twelve fields. Zero labels. Infinite frustration.
That’s not a design choice. That’s a barrier. And it’s exactly the kind of thing WCAG 3.3.2: Labels or Instructions exists to dismantle.
Comments closedImagine walking into your favorite library. You know exactly where the fiction section is. It’s always on the second floor, to the left of the stairs. The librarian knows where you go. Your feet know the way. It’s muscle memory.
It is a week later when you walk in, and suddenly fiction is in the basement, behind the coffee shop, accessible only through a secret door behind the periodicals. The stairs are now an elevator, but it’s on the other side of the building. The librarian has vanished.
You’d feel disoriented. Frustrated. Maybe even a little unsafe. You’re just trying to find a book, not solve a puzzle.
Comments closedIf I had a podcast, I would tell you to close your eyes and imagine the following. But this is a blog post…
You’re walking down a hallway, hand out, ready to turn a doorknob. Your hand lands on the knob… and suddenly the door slides open before you touch it. Or worse, the room you thought you were entering is actually a closet full of vacuum cleaners. Disorienting, right? Jarring? A little bit scary?
That’s how a user feels when they tab through a webpage and a piece of content jumps, moves, or redirects them without asking for permission first.
Comments closedLast year, just after the EAA deadline, I made a quick and short post called Don’t Stop. Just because the deadline hit and you aren’t accessible, you still need to keep working on it. Well today I have another one for you.
In the United States of America there was to be a final ruling going to effect on April 24th, 2026 that was going to make WCAG 2.1 A and AA the standard under ADA Title II. As of the morning of April 17th, this has now changed.
The DOJ has released a note that an interim final rule will delay this by a year until April 24, 2027 for populations over 50,000. This rule takes effect Monday April 20th, 2026.
You have been busting your asses to meet this deadline. This update means you can take the weekend off. But on Monday, it’s back to fixing issues and remediating PDFs. But there’s one more thing this affords you, time to work with a consultant to develop a plan so the next time rules change you don’t have to wish for a last minute reprieve.
Oh, and now there is no excuse for not fixing those PDFs…
Comments closedPicture 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.
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.
Dragging movements assume a level of motor control that not everyone has:
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.
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.
I’ve seen this fail in a few classic ways during audits:
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 closedThe <abbr> element stands for abbreviation. The idea behind this is you provide the abbreviation of the word or phrase, then use the title attribute to display the whole name or phrase.
<p>You need to pay your taxes to the <abbr title="Internal Revenue Service">IRS</abbr> for many years.</p>The problem with this is that the <abbr> is not an interactive element. You cannot tab to it. It will be read just like any other word in the sentence. If you mouse over the element, you see the title. But if you use keyboard there is no way to expose it.
Then there are screen readers. Most screen readers will not announce this title.
It’s better to fall back to the old newspaper styling where you say the whole phrase the first time followed by the abbreviation in parenthesis. From there forward, you can use the abbreviation.
Take a look at the testing Adrian Roselli has done on this.
Comments closedThe specifications for dialogs and modals recommend placing focus on the first focusable item in the dialog. The vast majority of the time this is a close button. this means that a screen reader user will hear something similar to “Dialog, Shopping Cart, Close, button.”
As a user this is confusing. I just added something to my cart, or I just opened it to checkout. And now your site is telling me that while I’m in the cart I should close it.
I strongly recommend that this is not the best practice we should be following. We should be providing the user with information they need in a way that encourages them to explore. To accomplish this, I recommend placing the focus on the heading of the dialog. We do this by providing a proper ID and tabindex="-1". Now when the user opens the cart dialog they would hear something like “Dialog, Shopping Cart.” This tells me my focus has shifted due to my actions, where the focus went by identifying, and I’m not hit with the confusing close button.
This is my opinion, it differs from many, but it fills the gap between accessibility and user experience to create a better flow for everyone. But I’m not alone in this opinion.
Comments closedLast 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.
Comments closedIf you’ve been following my work or this blog for a while, you’ll know I’m always referencing that authors need to support both mouse users as well as keyboard users. What I haven’t mentioned much of is touch. Touch devices have given us a number of different modalities to interact with applications and the web. The problem arises when users don’t have the ability to touch the screen, or only have a single pointer when multiple are needed. Or perhaps they can’t perform the gesture. This is the point of this success criteria, providing an alternative for those users. Let’s check out how we do this.
Comments closed
