Since the passing of the 1990 ADA (Americans with Disabilities Act) established a legal requirement for businesses and public spaces to provide reasonable accommodations for those living with disabilities, the United States has become more accessible than ever before. As the Web continues to become a greater part of our daily lives, website accessibility ensures that all users (regardless of their needs) can maintain their digital independence and freedom.
Unfortunately, despite website accessibility being a concept known to many, developers and businesses frequently omit it from their designs. In this post, we will cover what accessibility means for you and your users, why it’s not more common, and what tools you can use to make realizing website accessibility easier.
What is website accessibility?
At its simplest level, website accessibility means that a site is usable by people living with disabilities. Fundamentally, the Internet was created to be universal; the more people that can use the internet on more platforms, the more powerful and useful it is. In particular, the W3 states that accessible websites should be usable by everyone (including those living with disabilities).
In more concrete terms, this means you should do two things in the development and maintenance of any website:
- Avoid design decisions that will hamper your site’s usability
- Actively leverage strategies to make your website more useful for assistive technologies
In 1999, the W3C’s Web Accessibility Initiative (WAI) introduced the first version of the Web Content Accessibility Guidelines (WCAG). Since then, WCAG has gone through some significant updates including clarifying accessibility best practices, expanding to include guidelines for more content types, and adding the foundations for tooling to aid developers in testing their websites. These guidelines offer specific directions for developers to ensure what we make is available for anyone to access.
The WAI hasn’t just stopped with WCAG; the Accessible Rich Internet Applications (ARIA) specification defines default roles for the various parts that make up web pages. This means that any page written with semantic HTML is inherently accessible. Even more exciting, as the Modern Web continues to leverage more dynamic content, ARIA allows developers to specify the role of dynamic content. With some work, even the most dynamic of Single Page Applications can be accessible.
In short, making your website accessible will mean designing it such that anyone (regardless of disability) will be able to use it. And, just as it takes some effort to keep a website mobile-friendly, it will also take some effort to keep a website accessible. Thankfully, due to WCAG and WAI-ARIA, this is easier than ever!
How do you make an accessible website?
The first step is the easiest! As you build (or update) your website, use semantic HTML. When you introduce a new paragraph of text, use a <p> tag; your website’s footer should be in a <footer> tag; links should be <a> tags, etc. In short, the HTML backing your web page should reflect the webpage’s meaningful structure.
Unfortunately, many web app developers fall into the trap of misusing <div>s. <div> is a generic content container, which makes it a frequent go-to for whenever you need to divide content into subsections. But, because it carries no semantic information (because it can be used for any purpose), accessibility technologies know very little about them.
Often, those with disabilities interact with the web using an assistive tool. These can be anything from screen readers, hands-free mouse tracking, voice controls, and many others. Just by using semantic HTML, assistive technologies have a much richer understanding of how your webpage is structured, and they can offer a much more useful experience. And, as with most best practices, once you get in the habit of using semantic HTML, it will become second nature.
This is, by a wide margin, the biggest and easiest accessibility win. If every page leveraged semantic HTML in its construction, the entire internet would be a much more accessible environment; but, don’t stop here! When your page leverages a lot of dynamic content, make sure your content declares appropriate roles (so that, regardless of what HTML you need to use, each piece of your webpage is telling browsers and accessibility tools how it should be treated).
When you’re ready to dig in further and embody accessibility everywhere on your web page, you can ensure that your development process accounts for as many principles of web accessibility as possible.
If this is so important, why isn’t it already universal?
Humans are only able to maintain so many stable social relationships. Among other things, this also limits the realm of people we consider when we design a tool or piece of software. Put another way: developers will tend to design software with a “normal” user in mind, and because developers are human, their social group will tend to define what they consider to be “normal.”
So, in essence, designing for accessibility is an exercise in empathy. As developers, we want to maximize utility and functionality for the users of our tools. To that end, we need to imagine all the different ways our users might interact with what we create.
In my experience, the easiest way to put yourself into the shoes of someone using an accessibility tool is to use one. There are tons of screen readers (several of which are free); take a day every few weeks and use it to interact with the web for your daily browsing. Go over your site too and see if you still find the site usable (if not, you’ve found an excellent opportunity to improve your UX). Do a “left-handed oil test!”
Accessibility is easier than ever to achieve for web pages, but it’s certainly not universal yet. Every developer who works to make their creations better takes us one step closer!
Tools can help!
There’s no substitute for using what you make, so occasionally using your site with a screen reader will be very helpful and revealing. But it’s not the only tool available to you. One of the tools I tend to use most frequently is WebAIM’s WAVE. WAVE allows you to get a quick overview of any significant issues on your webpage (and some warnings for things that need some further evaluation). They’ve also recently released addons that developers can install directly in their browser (so that evaluating a page is a single click away).
Using WAVE alone is a huge step forward, but if continuous testing has taught us anything, it’s that automating a test suite makes it dramatically more useful (because the break-fix cycle can be significantly shortened). To that end, WAVE now has an API offering. This would let you test pages in bulk, or even deploy the API standalone and integrate it into your CI/CD pipeline!
The most exciting part on the automated testing front is about to get better too! WCAG 3.0 is now open for public comment. Among many excellent improvements over WCAG 2.x, 3.0 will offer testable criteria for each guideline (so that automated testing tools can offer much more rigorous and specific suggestions and analyses). This means tools like WAVE will be able to give you deeper insights into your site’s accessibility automatically!
As with all UX improvements, there’s always more you can do. You can hire consultants to do periodic accessibility audits. You can ensure your site’s visual style promotes accessibility everywhere. You can use multiple accessibility testing tools (in addition to WAVE, you may want to consider TAW and Firefox’s Accessibility Inspector).
If you’ve gotten this far, you’ve probably already made the biggest leap by caring to learn. Now, all that’s left is to work to apply that knowledge!
Interested in learning more about how to transform your website into the valuable business asset that it is? Contact our team today to get started!
To enable comments sign up for a Disqus account and enter your Disqus shortname in the Articulate node settings.