Your Website Works. For Whom?
An appointment, a stubborn form, and something I've learned after years of designing digital experiences.
F.J. Abrahams
Founder & Principal, Internauts
Your Website Works. For Whom?
An appointment, a stubborn form, and something I've learned after years of designing digital experiences.
F.J. Abrahams
Founder & Principal, Internauts
It's Tuesday, 8:46 a.m.
I have fourteen minutes before my next meeting, and I need to book a medical appointment.
Simple enough.
I open the clinic’s website. Beautiful design. Clean interface. Nice typography. Even a friendly little message promising I can book my appointment in “three easy steps.”
I should know better than to trust those words.
Step one asks for my date of birth. I enter it.
The field turns red.
That’s it. No explanation, no useful message. Just a red border announcing that I’ve somehow disappointed the website.
I try another format. Still red.
Eventually, I get past it and reach the appointment calendar. I click to choose a date.
Nothing happens.
Now, being a designer, I have this annoying habit of testing things that most people would simply give up on.
I put the mouse aside and try using my keyboard.
Tab. Tab. Enter.
Nothing.
Three easy steps, my @ss.
Here’s the interesting part. Technically, the website hasn’t crashed. The servers are responding. The pages load. Somewhere, an analytics dashboard probably considers this another successful visit.
Meanwhile, I’m sitting here arguing with a calendar.
And that’s when I start thinking about something we designers don’t discuss nearly enough.
A website can work perfectly well and still be impossible for someone to use.
There’s a name for this. Actually, four.
If you’ve worked with digital products, you’ve probably heard of WCAG.
It stands for Web Content Accessibility Guidelines, developed by the World Wide Web Consortium, or W3C.
The current published version is WCAG 2.2. It contains thirteen guidelines organized under four principles, supported by specific, testable requirements.
Sounds technical. It can be.
But the principles themselves are almost embarrassingly reasonable.
The first is Perceivable.
Remember that red border around my date of birth?
Imagine I couldn’t distinguish that color. The website would be communicating something important in a language I couldn’t perceive.
An explanation like “Please enter your date of birth as MM/DD/YYYY” would have solved the problem.
The second is Operable.
That’s my calendar situation. If I can’t use a mouse, I still need a way to select an appointment. Keyboard access matters. So does being able to see where the keyboard focus is.
The third is Understandable.
This is a personal favorite, mostly because I’ve spent a ridiculous amount of my career watching organizations turn simple instructions into elaborate puzzles.
“Invalid input.”
Invalid what?
Give me a useful explanation. Tell me what happened and how to fix it. Don’t make me guess what the machine wants.
And the fourth is Robust.
This one sounds like an IT department’s favorite word, but it simply means that the website’s content and controls need to communicate properly with different technologies, including assistive technology.
A button can look like a button and still be meaningless to someone using a screen reader if it isn’t properly identified.
Four principles.
Perceivable. Operable. Understandable. Robust.
Or POUR, because apparently we can’t have a technology standard without an acronym.
Then I started thinking about the bigger problem
WCAG 2.2 introduced nine additional success criteria compared with 2.1.
Some address keyboard focus, dragging interactions, the size of clickable targets, repeated information, and authentication methods that can create unnecessary cognitive barriers.
Good stuff. Necessary stuff.
But here’s where my experience as a designer starts making me uncomfortable.
Imagine I finally get that appointment form working.
All the controls are accessible. Every field is labeled. The keyboard works. The error messages are clear.
And yet, I still have to go through eleven different screens, remember information from three pages ago, and repeat details I’ve already provided.
Could that website meet WCAG requirements?
Potentially, yes.
Would I consider it a good experience?
Absolutely not.
WCAG gives us an essential foundation for accessibility. It provides specific requirements we can evaluate and test. But meeting those requirements doesn’t guarantee that every interaction is understandable or free of unnecessary effort.
Even W3C provides additional guidance on cognitive accessibility that goes beyond the formal WCAG requirements.
Which brings me to something we’ve been exploring at Internauts.
What happens between the clicks?
We call our approach Neurodigital Design™.
The idea came from questioning something that traditional digital design tends to overlook.
We spend enormous amounts of time designing interfaces, measuring interactions, tracking clicks, and trying to improve conversion.
But what happens inside the experience?
How much information am I being asked to remember?
How many decisions do I need to make?
What happens if I get distracted halfway through?
What if I’m tired, anxious, in a hurry, or simply unfamiliar with the process?
And why does the website seem to expect me to understand how the organization behind it operates?
That’s a particularly strange expectation when you think about it.
I came to book a medical appointment. I didn’t come to learn the clinic’s administrative structure.
The more I think about it, the more convinced I am that much of what we call user error is actually the result of decisions made long before the user arrived.
Someone designed that form.
Someone approved those instructions.
Someone decided that eleven screens were acceptable.
And someone, somewhere, probably signed off on the whole thing because every feature worked.
The problem isn’t always the technology
I’ve spent years working with design teams and organizations, and one thing keeps coming up.
Accessibility is often treated as something developers need to fix.
But developers didn’t necessarily write those confusing instructions. They didn’t always choose that interaction. And they certainly weren’t the only people responsible for approving the experience.
Accessibility involves everyone who influences what people encounter online.
The designer. The writer. The project manager. The person publishing content. The executive signing off on the budget.
And yes, the developer.
You don’t need to know how to code to recognize when something is unnecessarily difficult.
You do need to care enough to look.
Formal accessibility evaluations require proper methods and testing, including consideration of assistive technologies. A quick personal experiment can’t establish WCAG compliance.
But it can help you discover problems worth investigating.
Five minutes later
Let’s return to my appointment.
Imagine a different version of that same website.
I enter my date of birth. The form explains the required format before I make a mistake.
I reach the calendar. It works with my keyboard.
The instructions are clear. The buttons are properly identified. If I get interrupted, I can find my place again.
At 8:51, I have my appointment.
No dramatic celebration. No confetti animation congratulating me for successfully completing a basic administrative task.
Just five minutes of my life spent doing what I came to do.
At Internauts, we call this Design with Manners.
It’s the same principle I appreciate in good hospitality. Anticipate what people might need. Make things understandable. Offer help when necessary. Don’t make people work harder because your system couldn’t be bothered.
WCAG gives us standards we can measure. Neurodigital Design helps us examine the human experience around those requirements.
Both matter.
And after years of designing digital experiences, I’ve become increasingly convinced that we’re asking the wrong question when we evaluate websites.
We keep asking whether they work.
I’ve started asking something else.
Your website works. For whom?
Sources
A quick note before you go
I wrote this because I believe WCAG should be accessible to everyone, including those of us who don’t speak fluent technical jargon.
So we created a companion Milestone, a short, visual explanation of WCAG 2.2 and its four principles. Something you can actually enjoy without feeling like you’re studying for an engineering exam.
Drop us a note. Tell us what you think, what made sense, and what we could explain better.
Watch the companion Milestone → [link]
I have fourteen minutes before my next meeting, and I need to book a medical appointment.
Simple enough.
I open the clinic’s website. Beautiful design. Clean interface. Nice typography. Even a friendly little message promising I can book my appointment in “three easy steps.”
I should know better than to trust those words.
Step one asks for my date of birth. I enter it.
The field turns red.
That’s it. No explanation, no useful message. Just a red border announcing that I’ve somehow disappointed the website.
I try another format. Still red.
Eventually, I get past it and reach the appointment calendar. I click to choose a date.
Nothing happens.
Now, being a designer, I have this annoying habit of testing things that most people would simply give up on.
I put the mouse aside and try using my keyboard.
Tab. Tab. Enter.
Nothing.
Three easy steps, my @ss.
Here’s the interesting part. Technically, the website hasn’t crashed. The servers are responding. The pages load. Somewhere, an analytics dashboard probably considers this another successful visit.
Meanwhile, I’m sitting here arguing with a calendar.
And that’s when I start thinking about something we designers don’t discuss nearly enough.
A website can work perfectly well and still be impossible for someone to use.
There’s a name for this. Actually, four.
If you’ve worked with digital products, you’ve probably heard of WCAG.
It stands for Web Content Accessibility Guidelines, developed by the World Wide Web Consortium, or W3C.
The current published version is WCAG 2.2. It contains thirteen guidelines organized under four principles, supported by specific, testable requirements.
Sounds technical. It can be.
But the principles themselves are almost embarrassingly reasonable.
The first is Perceivable.
Remember that red border around my date of birth?
Imagine I couldn’t distinguish that color. The website would be communicating something important in a language I couldn’t perceive.
An explanation like “Please enter your date of birth as MM/DD/YYYY” would have solved the problem.
The second is Operable.
That’s my calendar situation. If I can’t use a mouse, I still need a way to select an appointment. Keyboard access matters. So does being able to see where the keyboard focus is.
The third is Understandable.
This is a personal favorite, mostly because I’ve spent a ridiculous amount of my career watching organizations turn simple instructions into elaborate puzzles.
“Invalid input.”
Invalid what?
Give me a useful explanation. Tell me what happened and how to fix it. Don’t make me guess what the machine wants.
And the fourth is Robust.
This one sounds like an IT department’s favorite word, but it simply means that the website’s content and controls need to communicate properly with different technologies, including assistive technology.
A button can look like a button and still be meaningless to someone using a screen reader if it isn’t properly identified.
Four principles.
Perceivable. Operable. Understandable. Robust.
Or POUR, because apparently we can’t have a technology standard without an acronym.
Then I started thinking about the bigger problem
WCAG 2.2 introduced nine additional success criteria compared with 2.1.
Some address keyboard focus, dragging interactions, the size of clickable targets, repeated information, and authentication methods that can create unnecessary cognitive barriers.
Good stuff. Necessary stuff.
But here’s where my experience as a designer starts making me uncomfortable.
Imagine I finally get that appointment form working.
All the controls are accessible. Every field is labeled. The keyboard works. The error messages are clear.
And yet, I still have to go through eleven different screens, remember information from three pages ago, and repeat details I’ve already provided.
Could that website meet WCAG requirements?
Potentially, yes.
Would I consider it a good experience?
Absolutely not.
WCAG gives us an essential foundation for accessibility. It provides specific requirements we can evaluate and test. But meeting those requirements doesn’t guarantee that every interaction is understandable or free of unnecessary effort.
Even W3C provides additional guidance on cognitive accessibility that goes beyond the formal WCAG requirements.
Which brings me to something we’ve been exploring at Internauts.
What happens between the clicks?
We call our approach Neurodigital Design™.
The idea came from questioning something that traditional digital design tends to overlook.
We spend enormous amounts of time designing interfaces, measuring interactions, tracking clicks, and trying to improve conversion.
But what happens inside the experience?
How much information am I being asked to remember?
How many decisions do I need to make?
What happens if I get distracted halfway through?
What if I’m tired, anxious, in a hurry, or simply unfamiliar with the process?
And why does the website seem to expect me to understand how the organization behind it operates?
That’s a particularly strange expectation when you think about it.
I came to book a medical appointment. I didn’t come to learn the clinic’s administrative structure.
The more I think about it, the more convinced I am that much of what we call user error is actually the result of decisions made long before the user arrived.
Someone designed that form.
Someone approved those instructions.
Someone decided that eleven screens were acceptable.
And someone, somewhere, probably signed off on the whole thing because every feature worked.
The problem isn’t always the technology
I’ve spent years working with design teams and organizations, and one thing keeps coming up.
Accessibility is often treated as something developers need to fix.
But developers didn’t necessarily write those confusing instructions. They didn’t always choose that interaction. And they certainly weren’t the only people responsible for approving the experience.
Accessibility involves everyone who influences what people encounter online.
The designer. The writer. The project manager. The person publishing content. The executive signing off on the budget.
And yes, the developer.
You don’t need to know how to code to recognize when something is unnecessarily difficult.
You do need to care enough to look.
Formal accessibility evaluations require proper methods and testing, including consideration of assistive technologies. A quick personal experiment can’t establish WCAG compliance.
But it can help you discover problems worth investigating.
Five minutes later
Let’s return to my appointment.
Imagine a different version of that same website.
I enter my date of birth. The form explains the required format before I make a mistake.
I reach the calendar. It works with my keyboard.
The instructions are clear. The buttons are properly identified. If I get interrupted, I can find my place again.
At 8:51, I have my appointment.
No dramatic celebration. No confetti animation congratulating me for successfully completing a basic administrative task.
Just five minutes of my life spent doing what I came to do.
At Internauts, we call this Design with Manners.
It’s the same principle I appreciate in good hospitality. Anticipate what people might need. Make things understandable. Offer help when necessary. Don’t make people work harder because your system couldn’t be bothered.
WCAG gives us standards we can measure. Neurodigital Design helps us examine the human experience around those requirements.
Both matter.
And after years of designing digital experiences, I’ve become increasingly convinced that we’re asking the wrong question when we evaluate websites.
We keep asking whether they work.
I’ve started asking something else.
Your website works. For whom?
Sources
A quick note before you go
I wrote this because I believe WCAG should be accessible to everyone, including those of us who don’t speak fluent technical jargon.
So we created a companion Milestone, a short, visual explanation of WCAG 2.2 and its four principles. Something you can actually enjoy without feeling like you’re studying for an engineering exam.
Drop us a note. Tell us what you think, what made sense, and what we could explain better.
Watch the companion Milestone → [link]
Discover more about high-performance web design. Follow us on LinkedIn and Instagram.