Accessibility 101 — Good Client-side JavaScript

You Should ENHANCE An Already Working Page, Rather Than Be The Only Means of Providing Functionality.

Jason Knight
Jul 14, 2020 · 6 min read

I’ve spent the past decade working as accessibility, efficiency, and usability consultant to companies who have found themselves in court over accessibility failings. When I first started out in this type of freelancing I already had three decades of programming under my belt, around 12 years of that working with web technologies. At that time in 2010 the most common failings were easy ones to fix … well, if you could kick the ignorant PSD jockeys under the DELUSION they were designers to the curb.

Illegible colour contrasts; fixed width layouts; illegible undersized fonts in pixel metrics; These were the daily routine… I came to call them the “Trifecta of /FAIL/ at web development”. More so when “frameworks”, the monuments to ignorance, incompetence, and ineptitude were involved.

As time has pressed on frameworks got fancier and developers got dumber. Inaccessible broken non-graceful degrading JavaScript has soared past those other bad practices, to the point that with most of my recent clients it’s not a simple patch job. Instead everything they have client-side facing needs to be discarded wholesale and started over from scratch. It’s faster, simpler, and easier when trying to get people out of the courtrooms to start over from nothing, than to try and hammer these inherently flawed practices into behaving.

WAIT! You Can Be Sued or Fined for Accessibility Violations?

Absolutely! There are accessibility laws and they vary by country. The United States has its “Americans with Disabilities Act” or “ADA”. In the UK it’s their “2010 Equality Act”, aka “EQA”. These laws have traditionally targeted healthcare, insurance, banking, public utilities, and government websites, with banks having been my bread and butter for a while.

However, over the past few years there’s been an uptick in civil cases against regular businesses and websites. From Beyonce to Dominos this has been getting more and more high profile, with the supreme court refusing to hear / overturn the Dominos case making it “open season” on ANY business that operates in the US and deals with US customers. If you are an online seller, pay really close attention to that!

Queue the Lame Excuses

You’d think this would be a wakeup call, but instead site developers — especially React/vue/angular/jQuery JavaScript junkies who drink far too deeply of the tainted flavor-aid — are sticking their heads in the sand, or worse parroting lame excuses and bald faced lies to defend their broken, half-assed approach to web development.

You can even hear it in the rhetoric they spew, where they attack the blind man who filed the lawsuit instead of Dominos for being in blatant violation of the ADA. Don’t even DARE to suggest that their developers were either inept, or willfully negligent in doing their job. I hear this from my clients too in that they basically want to say “screw the disabled” and cannot believe that their own ignorance is at fault.

And it is always the same tired fallacies in action, such as:

But thousands of major companies use this framework.

And if all the other lemmings go running off a cliff? The “bandwagon” fallacy — oft powered by “testimonial” is insanely powerful at bypassing rational thought. Just because millions or even billions believe something is true, doesn’t make it true.

But so-and-so said it’s perfectly fine. They’re a big name in the industry.

Mercola, Paltrow, and the dirtbag calling himself an avocado are big recognized names. Doesn’t mean they’re not peddling snake oil by spewing lies.

But it’s easier to work with and maintain.

More often than not, the people who say this don’t know enough about HTML, CSS, or JavaScript to be flapping their yap on the topic. This is again doubly true for these stupid broken “frameworks”. Anyone qualified to work with the underlying languages should take one look at systems like Bootstrap, Tailwind, W3Fools “w3.css”, Angluar, React, Vue, etc, and RECOIL IN HORROR at the absolute garbage these systems vomit up and have the unmitigated gall to call HTML/CSS/JS.

Most of these claims of frameworks and “JavaScript for everything” being “easier” or “better for collaboration” are BALD FACED LIES rooted in propaganda techniques (bandwagon, testimonial, transfer, glittering generalities, card stacking) to sell you a feeling, instead of facts. When you factor in the bloated incompetent disasters they generate and the associated accessibility violations, they are at best dimestore hoodoo; five and ten voodoo.

So How is JavaScript an Accessibility Violation?

It isn’t always. It’s entirely possible to use JavaScript on a page without making an accessibility violation. The key is to progressively enhance the already working page so that it gracefully degrades. THINK before you dive for the scripting.

If scripting is off, can the visitor get to the content and perform basic operations? No? Well, you’re in violation.

Yes, there are some things — fancy things like maps and graphs — that require JavaScript to implement. That’s fine… but if someone can’t use your contact form, cannot place and track an order or other account information, or access your normal content, you went and screwed the pooch and likely need to back away from the scripting and take the time to re-learn to use HTML properly. It’s that simple.

… and that’s the laugh of most of these accessibility lawsuits. If the creators of these sites understood why HTML exists (device neutral delivery of content via semantics, saying what things ARE and not what you want them to look like), what CSS is for (styling that semantic markup for specific media targets), and when to and when NOT to use JavaScript, they wouldn’t be sitting there paying a lawyer for defense, paying daily fines, paying someone like me to fix their problems, and having their reputation tarnished.

“Progressively Enhance”, What’s That About?

Progressive Enhancement is a very powerful process for building accessible websites that “gracefully degrade”. It means building a page from the bottom up, instead of starting with what should be in the middle (appearance) or at the end (scripting). It is also something that artists under the DELUSION they know what design is, and scripting junkies oft scoff at or are utterly incapable of working with.

The overall process of progressive enhancement in client-side site building is:

  1. Start with your content or a reasonable facsimile of future content in a flat text editor and organize it into a logical order as if HTML doesn’t even exist.
  2. Mark that content up semantically, your tags saying what things ARE grammatically and structurally, NOT what you want them to look like!
  3. Create your CSS style(s) for each media target you want to support, along with any responsive / media queries. The semantically neutral tags DIV, SPAN, and Anchor get added only at this point, with any classes or ID’s saying again what things ARE, NOT what you want them to look like! (this is why HTML/CSS frameworks are incompetent garbage made by people unqualified to tell others how to make websites.)
  4. Then and ONLY THEN do you further enhance the page with JavaScript

If you are not following this process, your website is likely on the hit-list to sooner or later have an ambulance chaser come after you! You follow this process your page should work thus:

  1. Scripting off / blocked / disabled / irrelevant
  2. Images off / blocked / disabled / irrelevant
  3. CSS off / blocked / disabled / irrelevant
  4. Tag stripped so that if HTML’s “meanings” can’t be handled by the UA the content is still in a logical and usable order.

That base underlying HTML being the fallback for everyone, even the non-sighted. It’s called graceful degradation, as each of the fancy doo-dads fail, what lies underneath is at least USABLE even if it lacks the bells and whistles.

HTML is supposed to be for everyone. That’s why the tags have MEANINGS and why if you choose ANY of your tags for appearance reasons, you have failed to even understand what HTML is for. Doesn’t matter if it’s a sighted user on a screen, a blind user on a screen reader, braille reader, or TTY, or a search engine (which doesn’t have eyeballs). If your page is useless without CSS and JavaScript, you have failed in your job as a web developer. Full stop, do not pass go, do not collect $500.

It All Boils Down To One Simple Concept:

“If you cannot make a fully working useful accessible website without JavaScript first, you likely have ZERO business adding scripting to it.”
— Dan Schulz (RIP)

Sure, there are exceptions to this — Google Maps for example — but most business websites have no such excuse, and it’s why all this “JS for nothing” does little but screw you and your visitors over.


Everything connected with Tech & Code

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store