Actual things said to friends and family (and me) who asked for accommodations for their disabilities at work:
“InfoSec locked down the screen resolution on the monitors. Can’t you just sit closer?” said to someone with moderate low vision who was struggling to read their screen.
“If we give you a special chair we’d have to give everyone a special chair”, said to someone with two slipped disks in their back holding a doctor’s note. “Chairs are expensive.”
“Why should you get a different lamp than everyone else?” said to someone experiencing migraines from the fluorescent lamp over their desk who asked to have it shut off and replaced with a desk lamp.
“I can hear the voice track just fine” said to someone with a hearing disability who asked to have an internal video captioned because they couldn’t hear the voice track over the background music.
“Nobody’s allow to bring their laptops into the meetings anymore because none of you people pay attention” said to someone with depression and brain fog who needed to write important points down to remember them.
These statements are ablest and these kinds of attitudes are a big part of the reason why the Americans with Disabilities Act and its clauses regarding employment accommodation exist.
Low vision, neurological disorders, auditory processing disorders, depression, brain fog: these are all invisible disabilities. They’re not disabilities because there’s something “wrong” with the people. Everyone is different. Sometimes bodies don’t behave according to spec. These are disabilities because the environment — physical or cultural — stops the people with these conditions from doing the same things that people without these conditions can do.
An accommodation doesn’t always look like a wheelchair ramp or an ASL interpreter (though those are important accommodations!) Sometimes they look like booking the off-site at a place that doesn’t require everyone to go up a flight of steps. Sometimes they look like getting someone’s celiac-friendly lunch order right so they can eat with the team. Sometimes they look like turning down the office radio or giving everyone permission to use headphones. Sometimes they look like a corporate drug policy that allows medical marijuana so someone’s not in pain all day.
Mostly, they look like listening to each other and going, “That situation sucks for you, so how can we fix it?”
For National Disability Employment Awareness Month, look at your office or workplace and ask yourself, “If I interviewed the most brilliant and amazing person for a job here today, a total slam-dunk hire, but they needed an accommodation to work here, would I feel confident I could hire them?” And if the answer is no, fix that.
WCAG 3.3.1 Error Identification is a Level A guideline that requires us to provide error messages when an input error is detected. Which, I mean, the fact that this had to be written down is kind of sad — and yet I have run into more than a few forms that just didn’t tell you anything at all when something was wrong.
So we have to provide error messages. And writing error messages is hard. If you write an error message that doesn’t actually tell the user how to fix the problem (or that they cannot fix the problem), then you’ve still failed WCAG 3.3.1 because “crap” is the next door neighbor to “nothing”.
Too little information
To get an error message right, we need to write something useful.
This error message isn’t useful.
This is a screenshot of an Individual Goal Details page from an HR app. It’s supposed to be used by employees to describe one individual goal they will accomplish over the next year. It includes a goal title field, a goal description field, a due date field, an optional goal type field, and a “goal can be seen by” field.
It also includes an error message toast that says:
Error! The goal wasn’t created
Now it’s good that the system told me — I mean, the user — that the goal wasn’t created. This is good information to have.
It’s not so good that it didn’t tell the user why the goal was created. The user in this case guessed “server problem”, reached out to IT, was punted from IT to HR, and waited a number of days to learn how to resolve the problem.
Hey, did you notice that when I listed off the field names, there was one optional field, but I hadn’t mentioned that the rest of the fields were required? Yeah, that’s because the page gives no indication of what fields are required, thus implying that all fields are required unless they’re explicitly marked optional. Great! Except the user didn’t notice that was the pattern being used and assumed that fields not marked were optional.
Yeah, I hate required/optional patterns that leave anything unmarked. “It’s too cluttered to mark everything.” Bullshit, clutter is information I don’t need. Whether a field is required or optional isn’t clutter. I want to know what the hell is expected of me. Just tell me.
Anyway, this is a great example of an error message that is too vague. If it had said “Hey dingus, you need to provide a “goal can be seen by” visibility value and we’re not saving until you fix it” I would have been offended, but at least I would’ve known what to do.
What would work better?
The goal wasn’t created because a required field is not complete. Complete the Goal Can Be Seen By field to continue.
It also would’ve allowed me — I mean the user — to complete the form a full week before they did, which would have been with HR’s deadlines.
Too much (irrelevant) information
On the other end of the scale, we have this beautiful error message from a supermarket website.
“Users like details!” someone thought, probably followed by “a detailed error message will help our customer support people and engineers know what the problem is.”
Both of these statements can be true and we can still produce a garbage error message.
First, there’s the fact that this starts with “oops!” Hey, I’m not a four-year-old that spilled the milk trying to pour for the first time with Mom’s supervision. I’m an adult who prefers to hear “An error has occurred” or something similarly adult.
Then there’s the message:
AADB2C: Customer Id 02535c4c-a7dc- 4a61-854a-b728e358948f not found in Customer Api. Correlation ID: fcdd9974-6281-4ec1-9dc9- 532a01566afc Timestamp:2023-09-15 18:15:047
This is probably incredibly helpful to either the customer service rep or the engineer that works for the supermarket. The user is neither. Notice that the message doesn’t give the user any instruction about what to do with this thing? “Back to home” isn’t so much instruction as an acknowledgement that things are screwed up and you’re not going to fix them, at least as far as you know.
This particular user just stopped using that grocery store for about eight months, which frankly cost the supermarket more money than it bothered the user. Plenty of working grocery store websites in the area. When the user did finally reach out for help, it took customer support less than 15 minutes to fix it. Had they told me that in the error message they would’ve made a lot more money from this user than they did.
Ironically, the best way to fix this one is to include even more detail.
Your account requires additional maintenance. Please contact customer service at [link or phone number] and provide them the following error message. AADB2C: Customer Id 02535c4c-a7dc- 4a61-854a-b728e358948f not found in Customer Api. Correlation ID: fcdd9974-6281-4ec1-9dc9- 532a01566afc Timestamp:2023-09-15 18:15:047 [Copy button]
In conclusion
Three things these error messages teach us about writing good error messages:
Address the end user as your audience, not customer support or the maintenance staff. (You can include information for them, but they’re not your primary audience.
Tell the user that there’s an error in adult language (assuming your audience is adults).
Most importantly, tell the user what to do about the error. What action do you expect them to take when they get this error? If there’s a resolution the end user can take themselves, what is it? Who do they call or email if there’s no end user resolution?
Remember, bad error messages cost the business money in support costs, lost sales, and disgruntled customers.
And yes, these are usability issues, but they’re also accessibility issues. If you don’t have a disability, bad error messages might wreck your day for a few minutes. But if you’ve got a significant disability that makes navigating between pages and forms take 10x longer than other people, well, what might be three minutes of annoyance could be a half hour or more without even getting into the effort of contacting support.
Repeat after me: a menu is not a dialog. Don’t stick stuff in the menu that doesn’t belong there. For example, this select menu:
Whoever designed this overthought the process.
They started with a list that arguably is too big to handle a list of elements. Select menus work best with 3-10 items, and really max out at 25 or the height of the screen.
They recognized that the list was too big, but instead of using a different pattern, they decided to put buttons inside the menu’s list layer. If they were using the native <select>, adding buttons wouldn’t be possible, but they’ve decided to roll their own component. So now they’re responsible for all the accessibility as well as the behavior.
They have fallen down on the accessibility side.
The buttons, which represent first page, back one page, forward one page, forward to the end, and refresh, are grey icons on a teal background. They don’t even remotely pass WCAG 1.4.11 Non-Text Contrast – Level AA.
The buttons and page number fields aren’t keyboard accessible. That breaks 2.1.1 Keyboard – Level A.
Now, ironically, neither of these failures actually blocks a person with disabilities from using the field because they can still just type in the state that they want and it will filter to that state.
Which raises the big question: if people restricted to have to use filtering, and filtering is the easiest way to choose a state, why bother with the pagination at all?
What they’ve really built, for a keyboard-only user, is an Autocomplete pattern where a filtered set of options displays as the user types. Which works for everyone. And this is a scenario where the user is filling out their own address, so we can be pretty confident that they know what state they are in.
Worst of all, they don’t just use this component when it’s a long list. They use it for short lists too.
The moral of the story is that it’s easier and more efficient to use either a Select menu correctly or an Autocomplete for filtering than it is to try to force a select menu to do things that they’re not designed to do.
If you’re prone to vertigo or migraines, the giant hero image full of spinning things could cause headaches or vomiting, and further down every ring spins, which can bother both the people already named and people with ADHD who may be constantly distracted by the spinning rings.
Making it accessible would have been as easy as adding a “shut off animation” switch in the top right corner of the hero image, but sigh.
WCAG 2.3.3 Animation from Interactions might be a AAA guideline, but when the consequence of not offering it is your users get a migraine, can’t concentrate, or puke on their shoes, you really should implement it.
I’m migrating content from a number of other sites to keep all my accessibility information in one place. It’s likely to be a mess for a while while I get the migration done. Then hopefully the cobbler’s kids will find some shoes.
