38
loading...
Accessibility in JavaScript Frameworks Part 1: What's The Big Deal?
Over the past few years JavaScript frameworks have become the norm for developing new web applications. With the ability to create powerful, fast, and adaptive web sites it is easy to see why development teams and organizations have made the push to use these frameworks.
However, lost in all of this new found love for these frameworks has been accessibility. As usual, accessibility has been an after thought for teams using these frameworks for two main reasons. The first, because it isn't prioritized in the trainings and courses for the frameworks. The second, is the stigma that "It works the same as the web always has, so what is the big deal?".
All JavaScript frameworks have their own accessibility issues that come with them out of the box once you decide to use them. Though not overly well known, these issues can create large barriers for those with disabilities to able to use your application. Let's take a look at some of the big issues that JavaScript frameworks present from an accessibility standpoint!
By far, the largest accessibility issue that JavaScript frameworks face is focus management. Although the load times and speeds of websites greatly increase with asynchronous loading of content, accessible users are left behind.
When content is asynchronously added on the page, screen readers users and keyboard-only users can lose context of where they are on the page or even be unaware that new content has appeared. This can lead to a very difficult and frustrating experience when a person using assistive technology is trying to use your web content.
The main focus management issue comes about when a user transitions to a new page in your application.
Anytime a user clicks on a link to go to another page in your application, the focus is either kept in the same place, or potentially placed somewhere else entirely.
When transitioning between pages (or routing) the development team needs to be in control of where the focus goes when the page loads. There are multiple different techniques to achieve this:
For more information on this see my previous article on accessible routing: Accessible Routing in JavaScript Frameworks
Since JavaScript frameworks are single-page applications that load from a singular
index.html file, transitions or routes (page change) will not involve a page reload. This then means, that each time a user loads with a new page, the title will not change by default! This is an extremely overlooked issue in JavaScript frameworks that stems from the assumption of many developers that single index file equals “single title”. There are even some developers that believe fixing the issue is difficult or even impossible.
Example
index.html file, where the title is statically placed:<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta
name="viewport"
content="width=device-width, initial-scale=1, shrink-to-fit=no"
/>
<meta name="theme-color" content="#000000" />
<title>TITLE GOES HERE</title>
</head>
<body>
<div id="root"></div>
</body>
</html>The good news is, there are ways in which developers can carefully manage the page title change within their transitions or routes. Each framework has their own unique way of handling the title, but they do account for an easy way to make the change!
Aria-live and alerts regions have struggled to announce properly in JavaScript frameworks due to the dynamic nature of them. Asynchronously adding content into the DOM makes it hard for assistive technologies to pick up the region and announce it.
Most developers create a live or alert region component like the following one below, where the attribute is added to the component that is dynamically added to the page:
<div aria-live="assertive">
<span className="alertText">
{this.props.liveText}
</span>
</div>Assistive technology will greatly struggle to read the above snippet since the live region is not in the DOM on load of the page. The announcement will be very inconsistent, and more often than not would not even be read.
In order for it to be properly read, the live or alert region must be in the DOM on load, and then the text can dynamically be swapped out. This allows for proper reading of the content in the region every time!
One of the biggest added benefits of using a JavaScript framework is the ability tap into a wide array of different open source component/ui libraries. These libraries allow development to be able to use the components and functionality out of the box with very little overhead!
However, in the words of Ben Parker from Spider-man
"With great power, comes great responsibility"
If you choose to use a component/ui library, make sure you and your team do your research. A lot of teams do not take the time to look and test the accessibility of the frameworks they are using, and thus end up with an extremely inaccessible application.
Out of the box, your average UI framework is not accessible. They either have accessibility as an added "feature" or create all their components not using semantic HTML. Even some of the most accessible frameworks require some level of effort and accessibility awareness in order to fully create accessible components.
At the end of the day, you are on the hook for the accessibility of the UI framework you choose!
As obvious as it may seem to lot of web developers to use semantic HTML when creating web content, in JavaScript frameworks the use of it is a bit all over the place. For the record, the use of Semantic HTML is easy in these frameworks, it just comes down to developers getting the proper training and the will to do it.
So why is semantic HTML not used consistently in these frame works? There isn't a single reason why Semantic HTML isn't widely used or properly used in JavaScript framework development, but there are a couple of very big ones that lead to developers not using it.
These four items above all have worked in tandem to create a mess of an idea that HTML is not of value to learn and use anymore. More and more sites developed are using
<div> and <span> to create a <button> or even <input>. Investing time in learning proper semantic HTML is the best way to ensure that the web content created in JavaScript frameworks is the most accessible it can be.
So, What is the big deal?? Well, as you can see, JavaScript frameworks do have their own accessibility issues that come with them, and if they are not properly dealt with it can cause your development team to create an application that is inherently inaccessible.
The good news here is, all of these issues are very easily fixable! It may seem like this article was written to bash on JavaScript frameworks, but that is not the case. They are here to stay and have massive benefits for web development teams.
However, for ALL users to be able to use your content created in these frameworks, we have to start by creating an awareness of these issues like we have in this article. Once we have that awareness we can create developers that give a damn about accessibility and the content they create and build a more accessible future with these frameworks!
38