The Three Developers and the Insightful User Tester

Prologue: Accessibility through familiarity

Throughout history the art of storytelling has been used to entertain, make connections, and instill life lessons. Stories have been used to convey concepts that some might find difficult to understand, or relate to, thus making the concepts more accessible. Fairy tales, myths, legends, and bedtime stories have been used to teach morals to children, in ways they’ll be able to comprehend. These stories stick with them as they get older. As adults, they retell the stories to their own children and peers, these lessons continue to inform and shape how new generations perceive the world around them.

If you look across cultures, many common story tropes and lessons are reused with minor to major differences. What changes in these familiar stories is the way they’ve been catered to their audiences. Pieces may have been taken out or expanded on. Names, locations, and settings are altered. All in the name of making the story resonate better with a particular audience, or to make sense in a modern setting. By doing so the story teller ensures their tale will better facilitate an emphatic connection to help spur imaginations, feelings, and convey the core lessons within.

Chapter 1: An Idea – We have to start somewhere

Once upon a time, in a comfortable chair not so far away,
There was a product designer who could not find what she desired, on Google Play.

And from that moment of longing not realized,
A brilliant idea for a product began to be formalized.

“Could it be, is it true?” the designer thought aloud.
I had thought all original ideas had been uploaded to the cloud?

A truly unique and invaluable app, I have stuck inside of my head.
I must get my sketch pad and get this on paper, before someone else releases it instead!”

Now you’ve likely heard it all before, “an app truly unique.”
Products that will “change the world”, yet their own fate ends up bleak.

But for the sake of this story, let’s just say it is true.
Let’s imagine that this idea is truly exciting, and totally new!

The designer started scribbling, creating wireframes, user stories, and the like.
She was an experienced professional, so she could do this all… save a single strike.

Her development skills were rudimentary at best, and she knew enough to know…
That she’d need to acquire additional help, if this project were to actually grow.

What she needed was the funding to build a team.
To start her own company, she could hire developers to help create her dream.

Over the months she went through all the necessary stages.
To get the LLC started, she had moments of joy, along with a few rages…

Or at least one must assume starting a company can’t be all fun…
(Psst, I’m going to skip over a bit, because the ins and outs of starting a company, I personally have not done).

Let’s just say everything is above board and the new company’s CEO she became.
Hiring a team, was her next task, ensuring they were not all the same.

For the best teams are made of those who’s skills don’t completely overlap.
If this is not understood, it could be a serious trap…

Three developers she had the resources to hire, to turn her specs into code.
Each of them with a skill set, a different “developer mode”.

HTML, CSS, JavaScript were each their own preferences.
Understanding each other’s domains, they mostly just stood in the entrances.

They were each tasked to build a portion of the app’s interface…
They knew they had a bit to learn, if they wanted to keep face.

To the Internet they went, to type in their own queries.
Each of them now, we’ll follow the events of their series.

Chapter 2: Straw – All for looks

The first of the developers, why he thought he knew best.
“I’ll get this done ever so quick!” he said, puffing out his chest.

“While the others review wikis, knowledge bases, and specifications,
I’ll lean on my deep knowledge of CSS to circumvent such onerous proclamations.

Specificity will be lax, and BEM classes will be king!
Everyone will marvel at the CSS of this thing.

I’ve learned all the tricks and even developed a few new hacks.
The transitions will be lovely, and they’ll gawk at how the hamburger menu stacks.

User delight will by my mantra, and I’ll let the Cascade do its thing.
Cutting out unnecessary markup and JavaScript is sure to make the performance sing!”

So diving right in, the developer got to work…
Wanting to prove to all that his responsibilities, he did not shirk.

As the other developers began to prep-and plan for their flows,
The CSS developer did not stop, he was all “go-go-go”!

Through the early days of the week, the CSS developer toiled, energy drinks in hand.
Getting giddy with his Sass, and nesting his child selectors with the trusty ampersand.

While the others continued to formulate their path…
The CSS developer was wrapping up, he could do the math.

“I’m going to finish this early!” he exclaimed to his peers.
Then realizing they were still hard at work, he hoped they wouldn’t take his excitement as jeers.

But slow down he did, and he started to take it easy.
There was no reason to feel stressed, this job had been breezy.

On the day of the first user tests, with the light of morning creeping across the sky.
The developer did one last check, and was pleased at the speed the application did fly.

“Just look at this now, the transitions are so quick!
CSS was all I needed, it did just the trick!

These users will be amazed and delighted by what they find.
I’ll just minify this code, and leave a bit more of the bloat behind.”

Using Grunt, his favorite task runner, the developer started his build.
And with that he looked around, at the members of his guild.

The CEO was on the phone, tirelessly promoting her dream.
While other employees walked around, conversing as a team.

The mood was a bit anxious, but mostly excitement was in the air.
The CSS developer was taking it easy, he had not a single care.

The user test would be starting soon, “oh what a thrill!”
Little did he realize, the mood would soon go down hill.

The testing had started, the five users had logged on.
By the end of the hour, they would sign off and be gone.

Their reports would then be written, and sure, they might find something.
Any early prototype might have a few ‘scratches’ or a ‘ding’.

But that’s not exactly what happened, as the users began to log out.
As one user seemed to linger, causing a faint air of doubt.

And doing what he knew he shouldn’t, the developer also logged in.
Asking “how can I help you, did you even begin?”

But the user, with the handle “wolf-38”, was a pro.
They’d been giving the app a real ringer, a serious go.

And after the developer’s message, into the chat room abyss.
He was met with a message that made him feel amiss.

Wolf-38: Oh developer, oh developer won’t you let me come in?
Wolf-38: I’ve been stuck at the start screen, this app should go in the bin.

LP_Straw: What do you mean you can’t enter, the hamburger is right there?
LP_Straw: I can’t give you more info than that, did you even try? Don’t you care?

Wolf-38: The hamburger is where? I can not tell, a button I do not see.
Wolf-38: The DOM is like a bunch of straw, scattered about with little meaning, to me.

Wolf-38: I know a bit of code, and developer tools I have used.
Wolf-38: I’ll open them up, and see how this markup has been abused.

Wolf-38: And that’s what it is, you’ve structured this wrong.
Wolf-38: The “menu button” is a check box without a label, it was there all along.

With that the tester began huffing and puffing not through the UI, but the code so quick…
Blowing it all down at a speed that made the developer sick.

Wolf-38: Just so you know, it helps not to rely…
Wolf-38: on only what you can perceive with your eye.

Wolf-38: Assistive technology requires you to use…
Wolf-38: Appropriate coding, the specifications you should not abuse.

When the final reports came in, the results could not be more stark.
The first four testers had a few positive comments, but the last had not a single good mark.

The CEO did not fret much at the outcome of the tests,
But expressed a want for improvement. “Next time, aim to be the best.

Learn from what is wrong, and start working in pair!
We have another week, don’t make these users pull out their hair!

An accessibility problem we have from your CSS and markup hacks.
Fix these bugs and get this train back on the tracks.”

Chapter 3: Sticks – A drafty user experience they make

The following day to his coworker’s side, the CSS developer skittered…
Finding books on JavaScript, all across her desk they were littered.

For this developer had been reviewing all things JS,
As far as CSS was concerned, it caused her a bit of stress.

The cascade was a bit of a bother, or so she had thought.
CSS components she had been introduced to, on YouTube, she had been taught.

The CSS developer began stammering “why are you writing CSS in JS, wait it matters not…
You have to see the results of these tests, learn from what I have been taught!”

The JavaScript developer, she stopped mid-function to take heed.
The report that was thrust in front of her, what an interesting read.

Intently she parsed the report of “Wolf-38″…
Slowly coming to realize what could be their fate.

“An inaccessible experience, how do you feel?
This tester really fried your bacon, did it hurt? Did you squeal?”

“What’s with the pig jokes? Let’s put humor aside.”
The CSS developer said, taking the jabs, mostly, in stride.

“You’re right, I apologize.” The JS developer exclaimed.
“Every failure is a learning moment, let’s do this together!” she proclaimed.

With that said, the developers went back to the Internet.
“We will surely find something if we just look hard enough,” they bet.

And hard they did look, and resources they did find.
GitHub repos labeled “A11Y”, “ARIA”, and more of that kind.

But time was limited, and these concepts were new and hard to grasp quickly.
“We’re spending too much time researching, we need start building”, the developers murmured, starting to feel sickly.

Not really knowing the purpose of some of their newly found resources…
They pulled down what they thought best, quickly skimming code sources.

Copying and pasting and npm installing all the things.
Requiring all their plug-ins and updating their JSON strings.

From the CSS demo they pulled out all the best styling and committed to git.
“Now that this is built with JavaScript, and ARIA, it will surely be a hit!”

Refining and performance testing, they did it right up till the end.
It was time for the next user test, quickly compile and hit send!

The users they logged on, one after another.
Then came Wolf-38, the two developers saw and gave a shudder.

What will they find, will it be any better this time?
“Look, already there’s a message notification. What could have been our crime?”

“We put ARIA attributes on everything we could.”
“Surely that must make it accessible? It just has to be good!”

But again the user had questions, as any good tester might.
It’s just frustrating not to know what to expect, it can cause a bit of a fright.

Wolf-38 wasn’t blocked this time, “that’s better”, they thought.
But it appears keyboard focus had become stuck. They were trapped, caught!

Wolf-38: Oh developer, oh developer won’t you let me come in?
Wolf-38: It seems that you’ve committed a WCAG cardinal sin.

Wolf-38: You mustn’t trap focus, keyboard users will be stuck.
Wolf-38: I keep having to hit refresh, it seems I’m out of luck.

Wolf-38: This test, while not like the last, it still has its pricks.
Wolf-38: But what would one suspect when made so fragile, like dry sticks!

Wolf-38: The first rule of ARIA is to try not to use it, you see,
Wolf-38: You’ve recreated so many wheels, and neglected what the browser gives you for free.

Wolf-38: When controls are announced, they should have an accessible name,
Wolf-38: But you’ve neglected these, solely relying on text nodes, for shame…

Wolf-38: There are <div>s a plenty, with incorrect roles on them too.
Wolf-38: The ‘links’ are announced as ‘buttons’, but I know that can not be true.

Wolf-38: The keyboard controls are off, not at all what I’d expect.
Wolf-38: And I truly know this because the source code I did inspect!

Wolf-38: And just so you know, when the app changes state, it’s great to know how,
Wolf-38: But with aria-live="assertive" on the <main> element, it’s mooing like an incessant cow.

Wolf-38: I don’t mean to be so huffy, but I have blown this app down.
Wolf-38: It seems you’ve tried harder this time, but I’m still going to leave with a frown.

All the users began to log off. It was time to call it a day.
But the developers just sat there, unsure of just what to say.

They were taking this to heart as if they had been hit by a caravan of trucks.
They wanted to make a great user experience for all, but the app, it SUX.

“What do we do now? Is this really feedback we should take?”
“It’s just one tester, is this really important, or fake?”

But as the JS developer said this, she knew it couldn’t be true.
“I am just not an expert here, this is all totally new.”

“It’s difficult to understand,” the CSS developer said,
“But you saw how hard it was to use. And they were really using their head!”

“Hold on,” the JS developer said, with a glint in her eye.
“There’s one more user test, another chance for us to try!

Let’s go home for now, and tomorrow we’ll start a new.
Fortunately, there’s another developer we can add to our crew!”

Chapter 4: Bricks – Building a proper foundation

The last of the developers had been steadily at work.
Moving at a consistent pace, and ensuring to squash any bugs that did lurk.

Her app was not overly-pretty, her styles were for practical use.
She wanted to get the structure in place, and not make anything obtuse.

The functionality was mostly limited to HTML out of the box.
With only some JavaScript, used cleverly, like a fox.

Links went places and summaries revealed details below.
From the top of the DOM to the bottom, content and focus did flow!

The two developers entered that morning, and walked to her side.
Their faces a bit long, on their sleeves, they wore their hurt pride.

“We tried this on our own, but we both failed the important test.
The accessibility, an inclusive user experience, ours was not the best…”

The HTML developer, she turned round in her chair,
“Come, look how I’ve done this,” her knowledge she was ready to share.

They poked and they prodded, reviewing her source.
“Wait,” the CSS developer said, ” <i> isn’t for icons?” The HTML developer sighed, “But of course.

It’s not always easy to understand HTML’s purpose when you’ve learned from those,
that care more about the latest framework trends, and impressing their bros.

Different tags have different meanings, their semantics convey intent.
So it’s always optimal to use the HTML for the purpose it was meant.”

Lessons she gave them, as they parsed through the app.
Relying only on keyboard, the magic mouse took a nap.

The JS developer’s eyes grew, on her face was a large grin.
The CSS developer wouldn’t stop stroking the hair on his chinny-chin-chin.

And when they were done, the two developers were excited.
“Oh what will be missed when we only build thinking of the sighted!

And it’s more than just that, every user is unique.
We should aim to be as inclusive as possible, let’s keep up that streak!

Now we get what you’ve done here! This structure is sound!
How can we help? Can we turn this styling, and JS, around?”

“Yes, that would be best,” the HTML developer exclaimed.
Let’s all do this together, myself a designer, I never once claimed.”

And through the remaining days leading up to the last test,
The three developers worked side by side, there was little time to rest.

When finally it came, the time of the user test was here.
But it was different than the last, the developers only felt “a tiny bit” of fear.

The structure was redone and passed many automated checks.
Nu HTML Validator, Google’s Lighthouse, and AXE were now in their accessibility decks.

So they waited for the issues to start to be reported.
The HTML developer was patient, but the other two’s brows were contorted.

Then again Wolf-38 had sent them a ping.
But this time the message, it was encouraging and lacked the expected sting.

Wolf-38: Oh developer, oh developer, you have performed quite a feat.
Wolf-38: My expectations you shattered, almost every check you did meet.

Wolf-38: I have a few things to report, but I must say,
Wolf-38: Compared to before, you’ve taken my breath away.

Wolf-38: No matter how I huff or puff through this markup,
Wolf-38: It seems now you have an app worthy of your startup.

Wolf-38: So I bid you adieu, and only wish to say…
Wolf-38: I’ll be here waiting to run users tests, for another day.

The developers rejoiced! They had passed the last test.
And their lesson they shared at the next lunch-and-learn, by request.

CSS is wonderful for the visual style…
But relying on it for functionality, you’ll be lucky to go a mile.

JavaScript and ARIA can be powerful when you use them right.
But never forget the inherent might…

Of the HTML language, while declarative it may be,
But in the end, it’s the primary thing the browsers need to see.

It matters not what framework or library you choose.
Browsers render HTML output, so try not to lose…

Sight of what’s compiled, how it’s announced, and what markup works best.
For all users just want it to function, they typically don’t care about the rest.

Epilogue: The moral of the story

Diligence and truly understanding what one is building, the intent of the experience, are important aspects of web accessibility. Often I’ve seen many developers, especially those new to the field, want to jump right in and just start building. I’ve done the same myself. Building a website or application is fun (when it isn’t frustrating). Taking the ideas in your head and turning them into an experience that people all the world over can share. That’s just exciting!

But what we tend to forget, when wanting to share our experiences, is that not everyone experiences things in the same way. Rarely this is on purpose, but it’s an extra effort to constantly take oneself out of your shoes, and know all the different shoes you should be trying on. In an effort to rapidly bring our ideas to life, we may neglect to add in the fundamental structures that will ensure these ideas have a life that is healthy, built for longevity, and full of diversity.

Typically stories don’t turn out the way they did here, where development is able to rely on truly insightful user tests by those who know their way around accessibility development concepts, keyboard controls and WCAG success criteria. Often products ship and accessibility is an afterthought that needs to be tacked on. The “wolf” of this story was only seen as a threat because they had blown down, and found holes in the application that the first two developers had created. In the real world, we don’t have to worry about literal wolves, but we do have to worry about letting our users down, and creating experiences that make them feel like they’re using a sub-par products or services.

By correctly using our tools and building a strong foundation…
Our experiences will be accessible, a strong proclamation…

For how we care for our users, regardless of ability,
They’re the reason we do this, providing company stability.

Sure not everything is perfect, and sometimes what we need to develop, specs they may lack…
But contributing to open source, and the W3C you can back.

And while there may not be support for a particular feature…
Using ARIA, but reasonably, will not make a horrible creature.

A universal, and inclusive experience, strive to be their crafter.
And then to all, we can try to live a bit more happily ever after.

The End.