Web Accessibility: Buzzword or Reality?
Web Accessibility. The unexpected lovechild of Sir Tim Berners Lee, a shoddy 12" monochrome screen that went black (and never came back) and a cat that ran away with the mouse. The cat came back, but by the time we found the mouse again, Steve Jobs decided we should all be poking at our screens instead.
Rewind to August 6, 1991 — which to the snowflake generation may seem like ages ago, except it wasn’t — a mere 27 years ago, when the first web page went live, that web page was accessible. Its syntax was semantically correct, all of its content was in the DOM, it was readable by colour-blind people, dyslexics, 20–20 vision, poor vision or no vision individuals alike. It was keyboard navigable and its logical flow was from top to bottom, left to right. The only error on that page was and still is, the missing lang attribute, which came with HTML 4.01 in 1999, making this relic by today’s standards (Lighthouse audit, AXE under the hood) an 88% accessible page.
Except there is no 88% accessibility and this is where reality already starts hitting. Thinking that a site or an application being 88% accessible is “nearly there” is just as pointless and naive as having 88% of the necessary fuel on a flight between Chicago and Ontario. What you definitely never want to hear a pilot say is:
“Ladies and gentleman, screaming babies, snoring old folks, and that young couple who spent the last 20 minutes in the lavatory; first of all, yes we can hear all of it, and secondly I am pleased to announce that we have all the fuel to fly for 88% of the distance of this trip, the rest of it, we’ll wing it (pun intended) and glide, but based on my calculations and the questionable design of this DC10, that will only cover 88% of the remaining distance, so we’ll umm… crash.”
[Andre Rieu’s rendition of “Nearer my God to Thee” slowly fading in as the three engines fade out one by one…]
Say what?!? Well, think of it this way. Most of the good and important things in life are binary and cannot be represented by percentages. They either are, or aren’t. You cannot be 88% pregnant, 77% alive, 22% married (though this could be handy) or the Earth 55% inside the Solar System. You don’t believe me? Ask Neil Degrasse Tyson. He’ll tell you!
Same goes for accessibility. Your web presence either is, or isn’t accessible. It being binary also proves that accessibility is a good and important thing, and if you think otherwise, guess what? You’re a bad… thing, cause you’re definitely not human. Somewhere between Grinch, Cylon and Troll. Or nazi, and you can read all about it in my other article.
Now, the W3C decided a good while back not to be so harsh on the poor web designers and developers of our times, and came up with a nifty way of categorising accessible web experiences based on UX into three distinct levels: WCAG 2.1 A, AA and AAA. In loosely worded terms these translate into:
A — you really couldn’t be arsed to do a proper job, but you got lucky somehow. We can’t applaud you for your efforts, but in today’s society everybody has to be a winner, so we’re gonna give you A (literally!) for effort anyway. After all, the user, with some swearing and sweating in-between, does get the gist of what your s(h)ite/(cr)app is about and is able to stumble to where they want to get.
AA — there’s some genuine work done here, you actually went beyond semantic HTML and a couple of poorly chosen aria labels, and with occasionally shoddy user experience you can actually get from point A to B efficiently via keyboard. Nothing admirable, nor should you be bursting of pride either. It’s just… fine. It works.
AAA — some people will think you’re showing off, but that’s fine and they’re wrong. You actually give a damn and you genuinely care (or legally obligated if you’re a Government site/app). You’ve put real thought into this, and made considerable effort in both design, architecture and implementation to make the experience cover all disability types. We don’t hand out medals for what in fact was always your civic duty, but do know, that you can go to bed with the feeling, that you’ve made the lives of at least 1.9 billion people considerably better.
Hold yer horses! Why are we even doing this?
Well, umm, because we did it all wrong the first time. And the second time. And the third time. And the 26th time. Basically for 27 long years we just ignored disabled folks and it has now gotten so bad and so big that governments, major organisations and large corporations had to step in and tell us how to do our jobs because for over a quarter of a century we kept writing tables, Flash, absolutely positioned CSS and JavaScript that threw everything into a span or a div ending up with something like this:
<div>
<div>
<span>
<p><span>HELLO <span class="tooNestedToProperlyTarget">World!</span></p>
</span>
</div>
</div>’Cause who doesn’t want five wrapping and completely non-semantic elements around a paragraph that should probably be a <h1> to begin with, right?
We created a gazillion plugins, modules, libraries, frameworks, web stacks, local networks, remote networks, cloud networks, extraterrestrial networks (what did you think those satellites and the dead Laika were up there for, ay?!?), artificial intelligence, geo-location, Tinder, Grinder, and computers so small we can’t see them, but somehow we just couldn’t be arsed to write accessible code for the web. Well, we could, it just wasn’t ever a priority, and now it kinda is.
So here come the buzzwords…
Accessibility, WCAG, 508, A11Y, Lighthouse, Pa11y, AXE, alt tags, semantic HTML, tab navigation, screen readers, inclusive design, ethical development and the list goes on. Mentioning two or three of these at one of the fifty-two (random number, but there’s so many these days, I am pretty sure there’s one every week somewhere) web conferences, or at an interview, will definitely trigger a conversation. And that’s exactly what the problem is. It’s mostly a conversation and it’s mostly about “alt tags” for images. A big, fat nothing!
Oh, and by the way… It is not an alt tag! Stop calling it an alt tag. It’s an attribute. You cannot possibly expect people to take your web development and accessibility skills seriously (OK, they might/will, but come on, surely you can do better) if you can’t even make the distinction between a tag and a property! There is no alt tag. There. Just. Isn’t!
Tools, tools, but none of them works!
Because what is the answer to all of humanity’s problems? Automated tools. We’ve grown so accustomed to automated solutions that manual effort seems to have become foolish and demeaning. Every time a problem poses itself, someone just assumes “there’s an app for it”. It’s gotten so bad that whenever you dare say something must be done manually, people start frantically calling on fairy Godmother Google to magically solve the problem with a monthly SAAS subscription that has the button to fix it and prove you wrong. It’s gotten so bad that you’ll convince finance faster to pay for yet another app than convincing management that it has to be done manually; and there’s a reason for that — the misinterpretation and idealisation of automated accessibility tools.
Let’s take AXE for instance. It is now the de-facto tool for checking your web app for accessibility errors. In fact its use has become so widespread that Google now includes its engine in Chrome under the Lighthouse branding, which you’ll find in the developer tools under “audits”. The road to hell though, is paved with good intentions. Isn’t it always…?
While Google wanted to create great accessibility testing integration into the browser, what this resulted in is actually quite dangerous: a false sense of accessibility. Put it anyway you like, the moment you run that tool and the score is above 80%, most people will consider it done and dusted, when in fact that 80% in reality barely means 30%. Google states very clearly the severe limitations of the tool, but will anyone care about that or care to read the “small print”? Few. Will anyone start doing the manual checks with a screen reader and keyboard? Very few.
Not part of the development process
From create react-app to yarn build and from TDD to BDD we have all the bells and whistles to get something out there and make sure we don’t throw broken applications onto the web, which is all well and good, but nearly nowhere in the development or deployment process will you find testing for accessibility, and that’s a huge problem. There are currently no standard development patterns set to enable delivering an accessible application, and this is where I believe each individual developer and the industry as a whole need to sit down and fix things.
What I would be proposing, is a 3 tiered process:
- local testing: this could be done in various ways. Either use a build plugin like React’s a11y tester, a Git hook or whatever else makes you aware of code-level accessibility issues before you even commit your code or submit it for a PR. If you’re using Storybook, it also has an accessibility plugin.
- PR testing: this level proposes either strong collaboration with your code reviewers or an automated a11y Github plugin like AccessLint (if Github is what your teams are using).
- deployment testing: finally, running accessibility tests as part of your e2e testing suite is an amazing way to ensure that everything still works after integration with no errors introduced. Here you can use things like Protractor’s accessibility plugin or Pa11y.
Note: automated testing deals with around 30% (at best) of accessibility checks and it’s on only code-level. Passing any or all of these will NOT make your application accessible! The rest is elbow-grease.
The unicorn effect
Because every website and app out there needs to be a rainbow-pooping unicorn — said no one ever! Not everything is about you, designers, and not everything has to be in a modal, carousel, drawer, mega-menu, etc. Just because it slides up and has drop shadow, it’s still a bloody pop up. Calling a donkey a unicorn, won’t make it one.
Nearly always it’s UI over UX — because (apparently) anything and everything that lives on the web needs to make designers shine, no matter the cost.
OK, I’m being overly harsh here, but here’s what I actually mean. Dear designers, we understand you are artists, but guess what percentage of this planet’s population understands and is able to appreciate Picasso’s work? A very small one. And do you know why infinitely more people identify with Van Gogh’s work? Well, interpreting Picasso’s work is guesswork and most of the time the average person has no idea what’s going on, and this is why whenever I take a girl out to a Picasso exhibition, I look smart because I make up things as I go, about their meaning — something that I cannot do with a Van Gogh because “Sunflowers in a vase” leaves nothing to guesswork or imagination; it is what it is and the brushstrokes are always consistent across all the paintings. Consistent, self-explanatory art!
The bottom line is, designers need to create “Sunflowers in a vase”. Consistent, easy to understand designs that lend themselves to all types of users. Keep your Picassos to yourselves. Please.
Is it a donkey? A horse? A zebra?
I can’t possibly end this article on a negative note, can I? Well, I won’t entirely, but I can’t ignore the current state of web design and development either. We all throw around fancy jargon, make a lot of noise how we all have a master plan of making the web this magical cloud of fluffy rainbows while underneath we’re propping it all up with more and more technical debt, false sense of achievement, bucketloads of expensive SEO, massaged accessibility and security audits, and it all seems to be falling apart, a bit like the ending to this article and that DC10 on its way to “nearly” Ontario.
The lack of cohesive and coherent software development processes on the web feel a lot like stepping on each other’s toes at a dance competition where you’re trying to do the tango while your partner is adamantly breaking out in hip-hop moves. Give yourself a second to imagine that. If you can’t, Seinfeld’s Elaine is the next best thing.
Design wants unicorns, product wants it yesterday, development gets distracted by the latest tech trends and wants to build a racehorse, while all along accessibility gets forgotten and we all end up with a limping ass (donkey) instead — only to find out three months after going to production, the customer actually wanted a zebra but that donkey will unfortunately haunt us and everyone else for generations.
Do you know what would have gotten that airplane safely to Ontario? Working together. It’s not a new concept. At all. Humans and animals have done it successfully for thousands of years. We wrote books about it and called it waterfall, agile, scrum, kanban, scrumban and a million plus one other names. Question is, can we all in web design and development start working together? Can we get that plane to land safely at Ontario airport or are we headed for our 28th consecutive year of failing ourselves, the web and that 1.9 billion? We can’t be headed for this. Not again…
Attila Vago — writer of codes, blogs and things that live on the web. Programming polyglot, pragmatic doer, member of the “taking care of business” crowd, with a no nonsense attitude. An easily inspired inspirational individual with a strong predilection towards most things nerdy, good, carnivorous food, and Lego. Uses a Mac. Runs at 6 a.m.
HackerNoon and Quora author.
