In the pyramid schema I’m going to talk about today, HTML is at the bottom and JavaScript at the top. Before that though, let’s go back to the basics of what a website is.
A website, is comprised of one or multiple pages. A page, is comprised of multiple elements that collectively make a whole page.
Every element, and every page, has three fundamental layers—the first is HTML.
HTML stands for HyperText Markup Language—it’s the world wide web’s official scripting language, one that browsers understand and render *mostly* consistently back to users via various browsers (e.g. Chrome, Firefox) and browser versions from all over the globe (yes, even in pyramids).
In more layman terms, HTML (without its CSS and JavaScript siblings) can be simplified down to text and undecorated media elements (image, video, audio, etc). A page or element without CSS and JavaScript looks like this:
[SAMPLE HERE]
While this unstyled and non-interactive version may seem insignificant and unimportant, it’s not. Crazy as it may sound, a version of a page or element reduced down to this level is more often than not barrier free (aka accessible).
Here are a couple of main reasons why:
1. For starters, the page is minimalist. It’s innate linearized composition makes the content more traversable and predictable to interact / engage with.
2. A screen reader (used by a blind person) will crawl a page, and convert the text to speech. Guess what a search engine "bot" (or crawler) does? In very simplified terms, it too crawls a page and parses the HTML. It then returns results based on matching query terms and content keywords. Query terms is just a fancy way of saying "searched words".
***
The HTML is the foundation. You stylize your foundation with CSS, and then you enhance that coupled HTML + CSS version with JavaScript.
Now, what happens when you turn a pyramid upside down? It becomes a spinning top (toupie). And guess what? A spinning top doesn’t stand upright without friction and torque. Compare that to the pyramid whose utmost design is solid and sound—it’s *robust*.
If your pages are front-loaded and dependent on JavaScript, you will have that same reverse pyramid problem. You’ll have to throw all sorts of things at it to get it to do what it needs to do to check off your inclusive design and accessibility checkboxes. I’m not here to argue that it’s not possible to tweak a JavaScript powered version to cater to those audiences, but I can say with profound confidence that doing so is far from a straight forward and practical (let alone predictable) way. It tends to be expensive, unsound, and quite frankly—complicated for nothing when there’s a perfectly sound alternative (turn the pyramid over already!).
***
So next time you start a web project, ask yourself if it works without JavaScript. Not because having your website function without JavaScript per se is an accessibility requirement, but because any other way is wacky. And because, a site too dependent on JavaScript without a strong backbone will inevitably face all sorts of direct and indirect problems.
The accessibility criteria I like to point out for people who get the "to JavaScript or not" concept / principle confused, is the *very first one* > "Guideline 1.1 – Text Alternatives" word for word it says "Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language." ... need I say more? I think not.
Just in case I do, let me highlight the important parts that pertain to this argument "... text alternatives for any non-text content so that it can be changed into other forms ..." JavaScript ingested text, is not text that search engine crawlers can predictably crawl. A complex JavaScript powered interactive or immersive space, cannot innately be transformed into another form. But guess what? Disabling JavaScript to expose it’s components’ underlying HTML equivalent is one "hack" workaround a disabled person might resort to should they get stuck and see no effective alternative readily available (yes, they may try to deliberately disable JavaScript, refresh the page, and recrawl the page with the hopes that the rudimentary HTML version is more accessible).
And if that doesn’t convince, let’s move down the list to "1.1.1 Non-text Content" (level A). Here’s it’s short description "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below."
Again here, a rich and complex interactive may possess text, but that doesn’t qualify it as "text content". Text content should be considered as rudimentary and classic text, not text superimposed into a supercharged Goliath or mammoth interactive. And so what do we need? A text [based] alternative. The most minimum viable product way to do that, is to at least make sure your page is built in a progressively enhanced (HTML > CSS > JavaScript) or gracefully degrading (HTML < CSS < JavaScript) manner.
Is there subjectivity to what that WCAG criteria means and where / when it applies? Of course. As there is for most accessibility criteria. But here’s what’s not subjective, the fact that complex for nothing JavaScript powered pages, elements, and sites, come with a slew of complications—and guess who’s impacted more than anyone else? A person facing one or more barriers.
I’m gonna stop there for now but the point is, a healthy starting point and great failsafe approach to employ is to ensure that all pages and their constituents parts are comprised of HTML, CSS, and JavaScript. And when possible, they should be built in the 1 > HTML, 2 > CSS, and 3 > JavaScript order. Don’t turn a pyramid onto it’s head, don’t put the horse before the cart, and don’t try to hammer in a screw. And when you must, at least now you know what the consequences are.