At the end of February, WebAIM analyzed the home pages of the top 1 million websites to get a picture of the current state of accessibility on the web. If you haven’t heard of WebAIM, they’re a non-profit organization that helps businesses and nonprofits make their own websites accessible to people with disabilities.
The results of the analysis of the WebAIM Million are overall pretty disappointing. 97.8% of the home pages analyzed contained detectable failures. It’s important to keep in mind that the errors detected are just the ones that can be found automatically by software scanners – so it’s likely that there were failures on these home pages that could not be detected through this testing method.
Passing automated tests is a nice benchmark, but a site can pass those with flying colors while still having significant accessibility issues – a topic we can dive into another time.
What I want to talk about today is the finding that sites using JavaScript frameworks and libraries were generally more likely than those not using them to contain accessibility failures. You can view the results for JavaScript frameworks and JavaScript libraries for yourself. jQuery was one of the worst offenders – sites using jQuery were 43.4% more likely to have accessibility failures than sites without jQuery.
Is JavaScript accessible?
JavaScript has a rich history. When it was first introduced in the late 1990s, it provided a way to make websites interactive in a way they never had been before. It was quirky and troublesome, and often required the code to be written twice – once for Internet Explorer and once for Netscape – but the payoff was so big, folks used it anyway.
But then it got something of a dark reputation. JavaScript started to be used for popups, scams, and general annoyances. Reputable web developers started avoiding it completely and advising others to avoid it as well. JavaScript had a terrible reputation in the accessibility community in particular, because it could not be interpreted by screen readers.
In the mid-aughts, JavaScript saw the beginnings of a turnaround, branded as Web 2.0. Web developers who had previously scorned JavaScript slowly started using it on projects. As it grew in popularity, more and more libraries and frameworks were introduced to make building projects easier and faster, but also to make it easier for beginners to get started.
The JavaScript language itself started getting lots of attention and new features were added – it became a robust programming language and started to be taken seriously. At this point, it’s nearly ubiquitous – it’s pretty unusual in 2019 to find a website that’s not using JavaScript.
Screen readers have been updated to support JavaScript, so it’s possible to use JavaScript extensively while maintaining a website’s accessibility. New technologies like WAI-ARIA make it possible to build full applications that are accessible. Judicious use of JavaScript can even improve the accessibility of a site, providing accessibility features that are missing from the browser or screen reader itself. Take a look at a11y.js, for example.
Written well and with best practices in mind, yes, JavaScript is accessible.
Are JavaScript libraries and frameworks accessible?
JavaScript libraries and frameworks are tools. And just like any tool, they can be used for a variety of purposes, both good and bad.
For the most part, there isn’t anything about libraries and frameworks that is expressly inaccessible. Many of the bigger and more popular libraries and frameworks even have their own accessibility teams that advocate for better accessibility and campaign for awareness of accessibility best practices.
But just like JavaScript itself, the accessibility of a website or application built with a library or framework lies with the developer or developers who do the actual building. It’s possible to build fully accessible websites and applications with nearly all of the modern libraries and frameworks. But developers aren’t always aware of accessibility considerations or the best practices.
That’s not the fault of the libraries and frameworks themselves – just the way they get used.
So why the bad accessibility results for JavaScript libraries and frameworks?
Given that JavaScript itself and most modern libraries and frameworks can be used in an accessible way, why did these frameworks and libraries perform so poorly in the WebAIM Million? Let’s look at a few of the possible reasons:
Reason 1: Used by popular CMS’s
Popular CMSs, like WordPress, include libraries and frameworks like jQuery, jQuery UI, and Backbone out of the box. That’s great for theme and plugin developers who want their customers to be able to build highly interactive websites without knowing any code. But it also means that folks who don’t know much or any code at all are using these libraries and frameworks extensively. Sometimes the theme and plugin developers provide a way for site owners to build sites in an accessible way, but not everyone will understand how to do so. Other times, the theme and plugin developers overlook accessibility completely.
Reason 2: Less experienced developers
As JavaScript has grown in power and capability, an already steep learning curve has gotten more steep, and the language is changing and growing all the time. It’s a challenge for even experienced developers to keep up with all the latest innovations. Libraries and frameworks provide an easier on-ramp for less experienced developers to jump in and begin building websites and applications. But with less experience under their belts in general, these developers are less likely to know about accessibility best practices and guidelines, let alone how to implement them in the projects they work on.
Reason 3: Low budgets and tight timelines
It’s a running joke among web developers that every project has the same deadline and budget – as quickly as possible for as little money as possible.
If you need to turn around a project quickly on a low budget, you have to cut some corners. It’s just a fact. One of the ways to get a jump start on a project is to start with a framework or library. It can be a huge leap forward, cutting hours, days, or even weeks off the development time of a website or application.
But if things are moving quickly and with little wiggle room in the budget, one of the things most likely to fall to the wayside are accessibility best practices. Even if you choose a library or framework with accessibility features built in, there isn’t likely to be time to make use of them.
Reason 4: Lack of awareness and training
Even experienced developers don’t always know how to implement the Web Content Accessibility Guidelines or how to use WAI-ARIA. There are a couple reasons for that. First, this content isn’t often included in web development courses and curricula. Second, many web developers are self-taught, and don’t know what they don’t know. There are a lot of myths and misconceptions floating around in the web development community that can make it challenging to convince developers that accessibility is important, worth learning, and worth implementing.
But let’s not put all the blame on web developers. Sometimes web developers who are knowledgable about accessibility and eager to implement it on the projects they work on meet resistance from project managers, website owners, clients, supervisors, or business development professionals who aren’t convinced that accessibility is worth the effort. There’s a lot of work to be done to raise awareness and convince people that digital accessibility is a civil rights issue.
How do we improve?
Hopefully, you’re asking yourself what you can do to make things better. That’s great, because accessibility is everyone’s responsibility. Take some inspiration from Ethan Marcotte, who recently wrote an article exploring the results of the WebAIM Million. Find one thing you wish you understood better about accessibility and start learning. Check out Digita11y’s Accessibility Toolkit for helpful resources to guide you on your way. You won’t become an expert overnight, but set a goal that each project you work on will have better accessibility than the one before it.
A great place to start might be looking at some of the most common accessibility failures in the WebAIM Million and learning how you can fix those. Ironically, the most common are some of the easiest to fix – low contrast text, missing alt attributes on images, empty links, missing labels for form inputs, missing document language, and empty buttons. Learn how to avoid those and move on from there.
Focusing on accessibility is a thing you can do in your job as a web developer every single day to make life better for millions of people. You can give them access to websites, information, and helpful applications that they wouldn’t be able to access otherwise.
Arm yourself with the information needed to convince others that this is a task worth doing. And hopefully the next time WebAIM analyzes the top one million home pages, the results will be much better.
