In 2010 when I was diagnosed with fibromyalgia, I did what any good nerd would: I started searching for more information online. While searching, I came across many disabled people and disability communities discussing the issues they had with accessibility - both physical and digital.

This opened up a whole new world for me: Accessibility was never taught in college or mentioned in any programming job I'd ever had. I, like many people, assumed that the Web was for everyone, and it would just magically work. My eyes were opened, and I found it terribly unfair that people were struggling so much to access the greatest resource of human information ever. Wasn't the Internet supposed to be the great equalizer?

Wasn't the Internet supposed to be the great equalizer?

Accessibility Standards

Let's start with an introduction to some of the standards that govern Web accessibility - there are several. You've likely heard of the W3C, or the World Wide Web Consortium (https://www.w3.org/), the standards body for the Web. The WAI is a part of the W3C that specifically deals with accessibility, as the Web Accessibility Initiative (https://www.w3.org/WAI/). There are two primary standards developed by the WAI: WCAG 2.1 and ATAG 2.0.

The Web Content Accessibility Guidelines (WCAG) (https://www.w3.org/TR/WCAG21/) are currently at version 2.1, released in June 2018. WCAG deals with accessing content - think about reading a newspaper or magazine article online or watching videos on YouTube.

The Authoring Tool Accessibility Guidelines (ATAG) (https://www.w3.org/TR/ATAG20/) are a newer standard; v2 is from 2015. ATAG applies when tools are provided to create content, i.e., writing a post on Medium or creating an Instagram story.

You'll notice that many familiar services are bound by both standards. If you provide a product that allows users to create and post their own content, you'll need to consider ATAG for content creation and WCAG for content display. I'll focus on WCAG in this article, because there are far more people viewing and reading content than there are creating it, even when you consider social media.

WCAG Overview

WCAG is broken down into four guiding principles: Perceivable, Operable, Understandable, and Robust, often abbreviated as “POUR.”

Four guiding principles of accessibility: Perceivable, Operable, Understandable, and Robust (POUR)

These principles are key to understanding digital accessibility: If you remember nothing else, try to keep POUR in mind. There are three WCAG ratings, single A (A), double A (AA), and triple A (AAA). In general, you'll be aiming for AA, except in cases where AAA is easily attainable with a little extra effort. If you're new to accessibility, A may seem like a good place to start, but be aware that level A criteria are seen as the barest of the bare minimum; not even a real improvement over forgetting or disregarding accessibility altogether.

Perceivable

Let's start with perceivable, the first step for accessibility and the foundation for the other three elements. After all, how can you operate or understand something if you can't perceive it?

All input to our brains comes via one or more senses, with seeing, hearing, and touching being the primary ways for humans to take in and convey information. A person who's blind or visually impaired needs to use another sense, such as hearing, to access information that sighted people get visually. You may have heard of screen readers, which are tools that literally read out the underlying code of a site so a blind or low vision user can access it.

Screen Readers

The most common categories for disabilities are pain, flexibility, and mobility, followed by mental health, dexterity, and hearing, and then seeing, learning, and memory. Although screen readers are essential tools, focusing only on screen reader users means that you've ignored six other more common disability categories completely. And of course, disabilities have multiple aspects - over 75% of disabled people reported in more than one category.

If you're curious about how screen readers work, I can almost guarantee that you have one in your hand or pocket right now. All Apple and Android phones and tablets come with one built in, and they're pretty easy to pick up and start using. Take a look at the settings and enable VoiceOver (Apple) or TalkBack (Android) and give it a try for yourself. What's the same and what's different about accessing sites and apps this way? Can you access them at all?

Semantic HTML

For Web accessibility, properly semantic HTML is key for many reasons; knowing how screen readers work can help you understand why. These tools present much more of the underlying structure of a site than a sighted user may expect. For example:

A screen reader describes a link with the text of “All” as “All, link” or “All, visited link” depending on the state.
A screen reader announces specific elements such as buttons and headers along with their level (i.e., h1, h2, etc.).
For images, screen readers attempt to read out a description of the image (alt text), if one's provided. If not, the file name of the image is used instead, even if it's obfuscated or otherwise confusing and unhelpful.
Most screen readers ignore non-semantic elements, such as divs and spans.

The div example brings up a common scenario: If you've done any Web development, I'll bet that you've seen cases where a div has been styled to look like a button, instead of using the actual button element. This is problematic accessibility-wise for a variety of reasons. A screen reader or other assistive device may skip it completely, confusing users. Using the wrong element may cause assistive technologies to announce it incorrectly, which causes frustration. Or, your button may be inaccessible by keyboard - and many disabled people rely on keyboard-based navigation. Ultimately, you lose all of the built-in benefits available with a semantic button.

Semantic elements such as buttons, links, inputs, checkboxes, etc. provide information to a browser that gives context to the element, even when it stands alone. Non-semantic elements, such as divs and spans, don't provide this contextual information to the browser, and therefore they do not provide necessary information to assistive devices or to users.

Color

Color is a big aspect of perceivable. A large number of people are color-blind or have low vision, so in order to have accessible content, you must use colors that provide sufficient contrast between the background and text (or image) colors. The WCAG AA standard for color contrast requires a ratio of 4.5:1; for AAA it is 7:1.

Luckily, you don't need to do the math yourself! There are a number of tools that let you input the background and foreground colors in hex, RBG, and HSLA formats and receive the contrast ratio. Some tools even take font size into consideration - a larger font can have a lower contrast ratio than the general guideline and still be AA or AAA compliant.

Using color alone to convey meaning causes accessibility issues as well. Someone who's red-green color blind may not be able to tell the difference between a grade written in green (i.e., a pass), and one written in red (a failure). Adding another indicator, such as a thumbs-up or thumbs-down icon, provides additional context, and makes the site more usable for everyone, not only users with disabilities. Be careful with icons though - solely using icons (no text) can cause issues for people with cognitive disabilities or non-disabled users who have a different cultural background.

Transformable

In order for content to be perceivable, it has to be transformable as well, to support users with different abilities. In general, you'll want to provide text alternatives for images, video, and audio.

For images, transformable content is called alt or alternative text, and it's a description of an image that conveys the necessary meaning to a screen reader user. You may also need to consider whether this image is purely decorative, in which case you provide an empty alt text attribute to hide it from screen readers.
With videos, transformable content can mean captions or described audio, which are distinct and have different features. Captions transcribe speech; a similar feature you may be familiar with is subtitles on a TV show or movie. Described audio is an audio description of everything appearing on the screen. Think of it as telling a friend about the amazing hotel room you had while on vacation: “When I turned the corner, and saw the room for the first time, it was HUGE! There was a sunken coffee table area and…”
When you have purely audio content (like podcasts), a transcript is required.

Did you know that all the major social media platforms have a feature where you can add alt text to your images as you post them? It's not enabled by default (which could be considered a violation of ATAG), but check out the settings on Facebook, Twitter, and Instagram and start adding alt text to all your images. Unfortunately, you can't add alt text to a gif on these platforms, but you could include a description as part of your content. After all, you never know when you're going to go viral, and everyone really should be able to experience your brilliance and wit.

Operable

Next up is operable. How do you usually move around online? Probably with a mouse or by tapping on a phone or tablet, right? If you have to enter information, you use a keyboard.

Some users, such as those with Parkinson's, may not have the fine motor control needed to use a mouse. In other cases, people with limited mobility may use assistive technology that replaces their mouse or keyboard entirely. These users can also have difficulty with areas that are too small to tap accurately, particularly on a phone or tablet.

Operable generally refers to keyboard accessibility, because most assistive devices mimic keyboard functionality. This also makes operable one of the easiest principles to test: I dare you to disconnect your mouse and try to navigate through a site you use every day.

I dare you to disconnect your mouse and try to navigate through a site you use every day.

Is it always clear where you are on a page (i.e., the focus state)?
Can you interact with all the controls you normally would - things like menus, buttons, and drop-downs?
Is it possible to bypass irrelevant or repetitive sections easily, such as the header or navigation, via a skip link?
Is the content structured in a consistent and meaningful way, with labels always positioned before, and properly associated with their controls (i.e., can you interact with a control by clicking or tapping on the label)?
And what about hotkeys? You probably already know about using the backspace key instead of the back button, but do you know about the hotkeys specifically for, say, the Twitter Web client, or do you have to figure them out by trial and error?

Speaking of errors, users will make them, so it's crucial to provide ways for users to recover from these errors. For the most part, this isn't too difficult: If someone makes a post by accident, you can allow them to edit it or delete it and start again. But what if a user transfers $1,000 to the wrong account? This can be much harder (or impossible) to undo. Things like confirmation screens, alerts, and warnings benefit all users, not just those with disabilities. Even better, provide instructions before users start a long or complicated process; these help users avoid errors from the start.

These examples show inclusive design principles - rather than designing a product and only then figuring out how it might work for disabled people, you can intentionally design products that work for all users, including those with disabilities.

Giving users control over timing and time limits is also crucial to operability - I'm looking at you, Ticketmaster! Consider the situation where you're trying to buy tickets for your favorite band and there's a time limit on the process. Now think about the experience of someone with a cognitive disability who has a slower response time. And what if they're also using an assistive device, which could also increase their response time.

This kind of control also applies to animations and videos: An epileptic user needs to be able to stop or pause a rapidly flashing animation or video before it causes a seizure, and all users benefit by being able to scan through a video to see what they missed (or skip ahead to the good parts).

Understandable

Once your content is perceivable and operable by a wide variety of users, you need to ask whether they can understand it. Language choices matter to accessibility: What counts as “understandable” depends on your audience, but unless you're 100% sure about education, background knowledge, life experience, and culture, it's best to default to very simple and concise text.

Basically, you don't want to use a long word when a short one would work just as well - and probably better. For example, instead of saying additional, say added. Instead of contains, say has, and rather than expiration, just say ends.

Functionality also needs to be understandable. At some point, developers decided that the hamburger icon (three stacked horizontal lines) would represent menus, and people have become familiar with this icon. So, unless there is a very good reason to break from the standard, you should also use the hamburger icon to represent menus on your site. If you do decide to do something unique, it's important that you're at least consistent within your own site. Don't use both the hamburger and your custom icon or you'll just end up confusing your users.

Forms often present problems with understandability. For example, when the Save or Next button is disabled, it's not always immediately clear what a user needs to do to enable that button. Rather than force users to poke around the form, filling in values at random until the button becomes active, consider accessibility and inclusive design. Although it's possible that someone without a disability may figure out how to get the form working more quickly than someone with a disability, it's a terrible experience for both users.

Robust

Last, but absolutely not least, we have robust. Does your site work in Chrome? Probably. What about Firefox? Yeah, probably that one too. What about IE11 and Edge? Safari, UC Browser, Brave? Does your site work on older versions of these browsers? What about the developer/canary versions? Does your app work on an iPhone 5? What about an iPhone X, with the notch at the top? What about allllll the different types of Android devices?

The key for robust is that unless there is a critical compatibility issue, everything should just work. Users need to be able to choose their own technologies in order to meet their own unique needs. I can feel you glaring at me through the page: This doesn't mean that you must support every version of every browser out there, just that you shouldn't be too restrictive.

Having a message on your site that it only works in the latest version of Chrome doesn't do anyone any good. When thinking about inclusive design as well as accessibility, consider the user who is at work and doesn't have permission to install the latest version of Chrome, as well as the disabled user who can't use Chrome with their assistive technology.

There are standards for HTML and CSS and you should be following them. Not only is this good for accessibility, it also provides a certain amount of future-proofing. When Apple first announced that websites would be available on the Watch, they noted that any sites using standard HTML would just work. Other sites, well they were in a bit of trouble.

Accessibility with ARIA

So how do you make Web content accessible when there's no standard? For example, there's no semantic HTML element for tabs, so you must create your own visual representations using lists and divs.

Fortunately, there's a tool called ARIA - Accessible Rich Internet Applications - that's meant for cases when you have to go above and beyond the existing standards. The first rule of ARIA is that you don't use ARIA.

The first rule of ARIA is that you don't use ARIA.

Let me explain: Bad ARIA is actually worse than no ARIA at all. When you have a non-standard HTML element or have used a standard element in a non-standard way, you may cause confusion or problems for disabled people using assistive technologies, but it's likely that they're familiar with these types of problems and can work through it. However, if you have added ARIA without knowing exactly what you're doing, it's very likely that you've made that element, or possibly your whole site, completely unusable.

ARIA should be used in three cases:

When you have dynamic content. A common pattern in Web development is to create a single-page application (SPA), where the page never actually refreshes. This is problematic for screen reader users, because they have no indication that the page contents have changed or have been updated.
When you need to expose your content to either sighted users or assistive device users, but not both (or both but in different ways). For example, you wouldn't want your skip link to be visible to all users, but it should be focusable by anyone using assistive technology.
When you have advanced UI elements. As I mentioned above, there's no standard HTML element for tabs, so you create these controls using lists, divs, and a whole bunch of CSS to make them appear visually like tabs. But what about screen reader users? You can use ARIA to indicate the relationship between a list item and a div, as well as the current state of the div (i.e., is the tab active/visible).

ARIA is an extremely powerful tool that allows you to hook directly into the accessibility tree of a browser. The accessibility tree is basically the DOM (document object model), but for accessibility. All styling is removed, any elements that have been hidden from assistive devices aren't included, etc. There are three aspects of ARIA that affect how an element is presented in the accessibility tree: role, relationship, and state.

Role

Semantic and interactive HTML elements have a role based on the type of control - button, checkbox, heading, etc. Non-interactive HTML elements can be given a role via ARIA, and the default role of a semantic element can be overridden. Consider this snippet of code:

<h1 role="button">
     This is a heading - or is it?
</h1>

Here, I've used a semantic element, a heading, but I've also provided an ARIA role of type button. Visually, this will be rendered as a heading. However, as far as the accessibility tree is concerned, this code represents a button. Screen readers and other assistive devices will announce this as a button, but the user won't actually be able to interact with it as a button - there's no click event or handler, no hover state or tooltip.

And of course, I can also do the opposite:

<button role="heading" aria-level="1">
     My Button?
</button>

Again, I've overridden the role of a semantic element (in this case a button), so the accessibility tree believes it's a Level 1 heading. You can see why it would be better to have no ARIA at all, rather than misleading and just plain wrong ARIA.

Relationship

ARIA can be used to describe the relationship between two elements. This is similar to setting the for attribute on a label, which links the label and the control together, as far as the browser is concerned.

If you think about the tab example again, you can use ARIA to link the first element in a list (i.e., the “tab”) to the appropriate div. This tells the browser - and the user, ultimately - that clicking on a specific tab activates or displays a specific div.

Another use for ARIA relationships would be for a description of a chart's data. In this case, you'd display your chart, and then have a visually hidden div or span linked via the describedby attribute. When a screen reader user reaches the chart, the contents of the div will be read out because the two elements have been linked together in the accessibility tree.

<canvas aria-describedby="chartDesc"></canvas>
<div id="chartDesc" style="display:none;">
     This is a description of the data
     in the chart.
</div>

State

If, for some reason, you decide that you need to create a custom checkbox instead of using the default one, you could use ARIA to expose the current state (checked or unchecked).

<div role="checkbox" aria-checked="false">
On
</div>
<div role="checkbox" aria-checked="true">
Off
</div>

Please, please never do this! This is an extremely simplified example - you'd need at least five other attributes on this custom checkbox to make it properly accessible. Or, you could just use the standard, semantically correct checkbox input element instead and get all the functionality automatically. Up to you!

Next Steps

Knowing anything about accessibility - even just a vague idea of what it means - puts you in a better position than many people out there, unfortunately. I urge you to keep accessibility in mind, remembering that small changes are important and they do add up.

When you're thinking about which library or framework to use; when you're considering performance enhancements; when you're writing a spec doc, designing a mockup, or writing a test script - just put the word accessibility out there. Maybe it'll force you to reconsider some assumptions. Maybe you'll realize that you don't need a library at all, because there's a native HTML element that does what you need. And you know what? Maybe nothing will change. But sometimes it will. In the future, you'll consider another aspect of accessibility. Build an accessibility toolbox, just as you would with any skill.

Build an accessibility toolbox, just like any other skill.

Maybe you're thinking that you don't have time for accessibility. However, using properly semantic HTML is much quicker than using custom elements, so you'll likely be able to gain some time that way. Then think about all the times you've given an estimate for finishing a task and completed it quicker than expected. Now you have an extra half hour or more to dedicate to accessibility, and tasks like checking the contrast ratio, adding alt text to images, and verifying keyboard navigation take very little time.

Don't forget about your internal tools and systems: Just because you're not selling something doesn't mean that accessibility doesn't matter. Could you hire a visually impaired developer tomorrow and have them use the same tools as your current team?

I'll also ask you to think about physical accessibility, which is still a problem and concern for many disabled people. When you go to meetups or conventions, ask if they're wheelchair accessible (and make sure they're truly accessible, not “oh, there's just one small step, I'm sure it's fine”). Ask if they have accessible and gender-neutral washrooms. Ask if there are accommodations for visually impaired, blind, or deaf users. If they're serving food, ask if there's a process for handling allergies and sensitivities.

Disabled people are already very aware of places they're not welcome, which allows those venues to say, “disabled people don't come here, they're just not interested in what we provide.” In reality, disabled people just don't want to deal with the frustration and possible humiliation of not being able to access a building or event. However, if abled people start asking these questions, accessibility will be presented to the venue as something that's desirable and changes (may) happen.

I'm here to put accessibility into your heads, and I hope you'll do the same with others in your communities.

Did you know?

Did you know, according to Statistics Canada, 20% of the Canadian population between 25 and 64 years old has a disability? Given that that stats for wealthy western countries are very similar, that would mean that there are over 65 million people in the United States who have a disability. And of course, our populations are aging - by 2030, nearly a quarter of the Canadian population will be seniors, and the likelihood of disability increases as we age. Did you know that less than 25% of children with disabilities are fully supported in school, leading to them being less likely to graduate high school or attend college or university? Overall, disabled people are employed less and paid less, even when they are employed. Technology alone cannot solve these issues, but it certainly shouldn't be making them worse either, which can be the case when digital accessibility isn't considered.

Tools

Chrome Accessibility Audit: This is a tool built right into the Chrome browser as part of the developer tools. Bring up the dev tools (F12) and then go to the Audits tab, where you'll see an Accessibility option. This is a great place to start if you're not sure what accessibility issues your site may have.
Contrast Ratio by Lea Verou (https://bit.ly/1q8vAZm): This is one of my favorite tools for checking contrast ratio. It's all manual, but I don't do a lot of design work, and being able to see my colors against each other as well as get the ratio is ideal for me. Alternatively, Chrome has a contrast ratio calculator built right into the Inspect Element and color-picker tools.
Access Needs Posters (https://bit.ly/28UkkQG): These are quick visual guides to six different types of disabilities and access needs developed by the UK Home Office. Neovation printed these up and hung them in the office as a reminder of the many aspects of disability. With the information included in these posters, you could easily create a checklist of small items to check when you have an extra five minutes.
Color-Blindness Simulator (https://bit.ly/2LgaAmI): This is a handy tool that allows you to see what your site might look like to users with different types of color-blindness. Just take a screenshot, upload it to the tool and play with the various options.

POURing Over Your Website: An Introduction to Digital Accessibility

Published in:

Filed under: