Hands sketching a user flow

JavaScript and Accessibility: Don’t Blame the Language

Written by: Everett Zufelt

One thing that makes the web exciting, at least to me, is that it’s open to all. Designers and developers come from diverse backgrounds — it’s not uncommon to find people who are part-time, self-taught, and completely free from formal training in their chosen craft — but nevertheless, they create great experiences and share meaning through the medium of the web.

And a big part of being “open to all” is the availability of an accessible web, one that users of all types can enjoy. Which is why I suppose I shouldn’t be surprised by the frequency with which I hear the question, “Is JavaScript accessible?”

In fact, I probably hear that question more than most. I’m completely blind, so I am a user of assistive technology. I’m also a JavaScript developer, currently working as the Director of Technical Services at Myplanet. These two factors combined mean I’ve been working with JavaScript and accessibility for nearly a decade, and the result is me hearing “Is JavaScript accessible?” with some regularity. It’s also why, when I answer the question, I do so with more than a fair bit of certainty: Yes, JavaScript is accessible.

Everett presenting at Drupal North. Photo courtesy Mike Gifford

Where to Begin?

Most designers and developers I’ve worked with are eager and excited to learn about accessibility. Some become interested after coming across an article or inspirational video, but more frequently, it happens because they’re mandated to incorporate it into a project.

Once they dive into accessibility, they inevitably come across the litigation portion of the topic. Probably anyone who has been through this themselves is familiar with the 2008 Target accessibility settlement for $6m. And in the years since the Target suit, many other successful actions have been raised, including a 2017 ruling against Winn-Dixie, where the grocer was ordered to improve the accessibility of its site to make it more accessible to the blind.

The tides are shifting towards a more inclusive web, and whether it’s the good of your heart that brought you to accessibility (including working on a project that includes “doing the right thing”) or, more commonly, a mandate issued because of legislation or a fear of litigation, the desire to dig in and get more knowledge on the topic is the real start.

JavaScript = Web

In 2017, JavaScript is the web. Although it’s possible to find web applications that use no JavaScript, or that can be used without JavaScript, you are far more likely to find web applications that require JavaScript, or that are purely JavaScript. In seeking a better understanding of web accessibility, it is paramount to understand JavaScript accessibility.

JavaScript is a programming language that enables you to create dynamically updating content, control multimedia, animate images, and pretty much everything else. (Source)

JavaScript on the web is used to send and receive information from a server, and to create or modify the user interface through interacting with the DOM (Document Object Model). This allows web application developers to create dynamic user experiences that do not require loading a new “page” of content when users interact with the application.

With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model. (Source)
Image of coding

The DOM and Accessibility

In order to achieve more than a rudimentary understanding of JavaScript accessibility, you need to understand the DOM, as this has a significant impact on accessibility for persons using assistive technology. The DOM is where all of the information that represents a web application interface is stored in the browser. Headings, paragraphs, alt text, autocomplete text fields — it all lives in the DOM.

To complicate things further, what lives in the DOM is not what is consumed by assistive technologies. Most browsers map the representation of the user interface from the DOM to a platform specific Accessibility API. This is similar to how native desktop and mobile UI libraries map their components back to an Accessibility API, and provides for more reliable interoperability for assistive technology:

…technologies such as JavaScript, Ajax, and CSS have enabled Web pages to look and behave more like interactive desktop GUI applications, without the need to reload the page with each user interaction. Developers can now re-purpose HTML elements into UI components not previously defined in HTML. For example, Javascript can be used with CSS to modify a <div> element based on user interactions to make it look and behave like a popup menu. Unfortunately, the <div> element does not provide the author with a vehicle to add semantic metadata that can be exposed through the DOM and mapped to Accessibility APIs. These accessibility deficiencies in traditional markup render rich Internet applications unusable by people who use assistive technologies or who rely on keyboard navigation. (Source)

In order to add the missing semantics to all of those meaningless <div> elements, the W3C has created the WAI-ARIA (Accessible Rich Internet Applications) specification.

The WAI-ARIA specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive technologies in document-level markup.

In a nutshell, WAI-ARIA is a set of properties that can be added to DOM elements, that enrich the meaning of the elements. As an example, you can add role=“button” to a <div>, and this will map to the “button” role in platform specific Accessibility APIs. The challenge, however, is that WAI-ARIA is only intended to convey meaning, and does not modify the behaviour of browsers, so you will need to implement JavaScript to control these new meaningful elements, including ensuring that they are fully accessible from a keyboard. A further challenge is that not all assistive technologies implement all of the latest changes in the WAI-ARIA specification, so research is required to ensure that what is being built is practically accessible.

Using WAI-ARIA, in combination with HTML, CSS, and JavaScript, allows web application developers to create dynamic, interactive, and accessible user experiences.

JavaScript, as a programming language, is not to blame for issues with accessibility. The use of JavaScript to update a web application’s user interface without sufficient consideration of how this influences the experience for users of assistive technology, is to blame.

“But I just want to create something cool!”

At this point many of you will be thinking that this is all a little bit overwhelming. You want to create something cool, and don’t have the time to read and understand pages of documentation from the W3C in order to understand how to ensure that everyone can enjoy the new (insert comical web-meme based fictional product name here) that you’re planning to launch.

As someone who both requires web applications to be accessible for daily use, and who leads teams of developers under the triple constraint of budget, time, and scope, I empathize with anyone who feels like accessibility isn’t achievable. You’re not alone, and you can start small. Like anything of value, becoming an expert, or even proficient, will take time and effort.

Image of team planning with laptops

5 easy steps to get started

1. Learn how people with disabilities use the web. Even if your mandate is to avoid litigation, you’re going to be most successful if you build empathy for the people on the other side of the DOM.

2. Join a community of those learning to build more accessible web applications. The WebAIM Web Accessibility E-mail Discussion List is one of the first I joined.

3. Attend an accessibility meetup or an accessibility camp. These events are typically a mix of beginners, experts, and everyone in between. Like many meetups, they often have pizza and beer.

4. Recruit users with disabilities to take part in your next round of testing. Ask them to bring their own device / assistive technology, so that you get the full experience of the barriers they face with your web application.

5. Find some accessible UI components. There are many out there, and I recommend a web search for “[component name] accessibility”.

Do Good, Feel Good

I was on a flight to San Francisco the other day and began speaking with the passenger beside me. He worked for a FinTech company, and shared with me that they put a lot of effort in to accessibility. I didn’t ask him what caused them to start looking at accessibility, but assumed it was regulatory.

He told me that one of the core constituents for their service is veterans with disabilities. He went on to say that they receive feedback from these users that theirs is the only service they could find that they could use. He didn’t use the word, but from the way he told his story, I could tell that he was proud. That’s a feeling we can all replicate using the simple steps above.

Remember, Rome wasn’t built in a day and you don’t have to be an expert out of the gates. Start small: find some users with disabilities, take them to lunch and listen to their stories about how they use the web. Pay them to show you how they interact with your web application and ask them to point you to others that they enjoy.

Perfection isn’t the expectation, but it should be the goal.

Improve incrementally, you don’t need to boil the ocean. Your web application team likely isn’t building all of its user interface components from scratch, you’re likely using a UI framework, or open source components from NPM. Do some research, find out what people are saying about the tools you’re using and look at versions — you may be missing out on new accessibility improvements and new features. Look for other libraries that provide the same component with built-in accessibility, it may not be that difficult to make the switch.

Give back, read a few articles on how to make that complex component more accessible, and file the PRs or bug reports that will improve the component for users around the globe. And be proud, you’re making the web more open to all!

***

Interested in making the web more accessible to all? Apply for one of our open developer roles here. Interesting in having your web experience upgraded for your users? Contact us here.

***

Found some good info in this piece? Be sure to applaud 👏 and share!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.