Jump to main content

Is it Accessible?

  • Published:
  • Category: Accessibility

Let’s get on the same page here…

If you follow many developers or web designers on Twitter, you may have seen the following tweet:

The attached photo is of the 2016 Fronteers Conference stage, with a projected slide that reads: “In 2016, it’s okay to build a website that doesn’t work without JavaScript”.

There’s a lot to unpack in that statement. And oh the unpacking that people did… My Twitter timeline was a flurry of rants both for and against the statement, and many of those tweets came from people with no context of the talk the slide was from. We’re collectively great at getting mad on the Internet, aren’t we? (FYI, I threw a stone through my glass house while typing that.)

[Quick aside, Nolan Lawson, the person who gave the talk, posted a great follow-up article titled: Progressive enhancement isn’t dead, but it smells funny. I suggest you read it.]

Through the tweet storm, there was one particular topic that I was drawn into: whether or not a JavaScript reliant website or application was considered inaccessible if said JavaScript were unavailable.

I want to talk about this for a bit; but before I do, I want to define two terms that will play important roles in this article.

1. Accessibility

Accessibility means everyone has access, the ability to use, and are not barred from the benefit of products, services or information because of special needs or disabilities. On the flip-side, accessibility does not mean that everyone has identical access.

An accessible interface can be interacted with and its content can be consumed in a variety of ways. Whether that be via keyboard instead of a mouse, via screen readers and audio descriptions of what would otherwise be primarily visual content, or transcripts of audio and video. Regardless of the means, an accessible interface ensures that all users get the same information and can perform tasks that lead to the same outcome. (e.g. mouse click or hitting Enter both activate links.)

One of the most common physical examples of accessibility is stairs and ramps. They both allow entry to an elevated entryway, but each provide different pathways to get there.

2. Universal Design

Universal design may start with a focus on creating accessible experiences, but its focus is not solely on users with disabilities. Instead, universal design promotes the idea that products, services and information should be usable to everyone, regardless of disability, age, or technological limitations.

An interface that adheres to universal design principals should inherently be accessible, since the UX and technology decisions behind it are focused on comprehensive usability.

Now one of the most popular physical examples of universal design is a curb cut (ramp). This incline in the curb enables people in wheel chairs to cross roads without requiring assistance to get down or back onto a side walk. But it also makes crossing the road easier for people riding bicycles, pushing carriages or carts, and those using walkers.

With those two terms squared away, let’s get back to the question at hand…

Is an experience reliant on JavaScript inaccessible without JavaScript?

It is perfectly acceptable for an interface to require the use of JavaScript. [audible gasps go here] JavaScript is an integral piece in creating modern day websites and applications. At times it may even be required to ensure that portions of an interface are accessible. By using JavaScript to close any usability gaps from custom UI components, or unsupported native HTML elements (e.g. dialogs), we can provide expected keyboard functionality and semantic intent to assistive technologies (ATs).

But, in an age of single page web applications and relying on JavaScript to dynamically generate content, components, and even entire pages, what happens when JavaScript fails? Doesn’t that lead to inaccessible experiences?

Well, as is typical of most development questions: “it depends.”

A failure of everything

First let’s look at a situation where JavaScript is absolutely required. A website or application built in the popular JavaScript framework of the week, where all content is dynamically loaded into a single <div id="app"><div>. In this sort of scenario, if JavaScript fails nothing loads at all. Surely being presented with nothing more than a blank white screen must be an inaccessible experience?

Until recently, I thought so. My reasoning being that while sighted users have a few visual cues as to what’s going on in these sorts of situations, users with visual impairments may not. A loading indicator in the browser’s address bar may still be spinning, indicating that something isn’t loading quite right. Or the fact that sighted users can immediately see an empty, unstyled white page when they might otherwise know that the page they were attempting to access normally has a different background color, or, you know…content.

Visually impaired users may not get as much context. A screen reader might return a message like “HTML content is empty”, or “[Browser-name] is busy” but that doesn’t immediately explain what has happened or why. Is the page empty now, but I just need to wait for it to load? How long is this going to be busy for? What is the problem?

And that’s what my hang up was. It was the lack of immediately understandable context that had me thinking this was an accessibility issue. But, I was mistaken.

Since nothing was loaded there’s really nothing inaccessible about it. It’s a failed experience for everyone. And that visual context I was speaking of? That’s likely my own bias at work here. Being a developer I know to look for these things — I can suspect failures and then test against those guesses. The average user is not a developer, and many don’t possess the context to pick apart what’s causing a website to fail, that I projected onto them. Returning a message saying “JavaScript is required”, when it’s been either blocked on purpose or due to a failure wouldn’t likely help most people. They’d shrug, maybe swear at their phone, and then just try to load another website.

In my opinion, just because this isn’t an issue of inaccessibility that doesn’t make it OK. A complete failure of loading any content is still a frustrating user experience, and definitely should be considered a universal design issue. There are methodologies one might be able to implement to mitigate this sort of scenario. I suggest reading up on not-so-new topics like progressive enhancement and graceful degradation, off-line first, and service workers to see paths that could be applicable if you currently find yourself in an all-or-nothing situation with your own project.

I’d talk about them here, but that’d be a bit off topic. Since we’ve identified that this scenario isn’t an accessibility failure, what would constitute as one?

Content loads, but without JavaScript it’s inaccessible

Where JavaScript failing becomes an accessibility issue is essentially when we don’t utilize it properly in conjunction with writing semantic markup and being mindful of our CSS.

Let’s take a look at the following example:

See the Pen JS-reliant Accessibility by Scott (@scottohara) on CodePen.

The menu toggle button still ‘works’ without JavaScript, but not without some accessibility issues due to the way it was constructed. The hard coding of the ARIA attributes in the markup means that screen readers are going to have a tough time properly interacting with this component.

The <a role="button" aria-expanded="false" ...> will announce the link as a button to screen readers, but without JavaScript the expected keyboard controls for either Space or Enter to trigger the button won’t work (links only accept Enter by default). More over, the aria-expanded="false" will convey that the element this toggle controls isn’t open, even if a user does actually use a mouse click or the Enter key to trigger the link, activating the :target pseudo selector that opens the menu using CSS alone.

Finally, the hard coded aria-hidden="true" on the <ul> will ensure that even if a user does get the menu open and tabs into the list of links within, those links won’t be announced.

So as we can see from the situation above, the JavaScript failing wasn’t actually creating the accessibility issues. It was the fact that the markup didn’t degrade gracefully. The hard-coded ARIA attributes needed JavaScript to allow the component to appropriately change state. Without the JavaScript, the attributes screw the native semantics and discoverability of the content.

So, is JavaScript in the clear then?

As far as accessibility is concerned, there’s nothing wrong with requiring JavaScript for your website or application. When JavaScript fails, accessibility issues are more likely to exist due to underlying misuse of markup and styles.

As far as where JavaScript specifically affecting accessibility is concerned, its when one doesn’t follow appropriate recommendations in building custom UI elements, or when abusing JavaScript to do things like:

  • trapping user focus in an element
  • overwriting expected keyboard controls
  • moving focus or loading new pages without user initiation
  • etc.

then you can blame it on the JavaScript… well, you can blame it on the JavaScript in that it’s doing exactly what it was programmed to do, or not do… :)

Steve Faulkner may have said it best: