The term du jour is web accessibility—in my opinion, one of the most frequently misunderstood and poorly applied aspects of web design. The common misconception is that accessibility is designed solely for disabled people. In fact, everyone benefits from accessible content, and your audience will increase by gaining access to accessible content on different platforms or in different ways, because they can use your content with fewer constraints.
Unfortunately, a lot of web developers do not make their content accessible and do not follow web accessibility guidelines; thus, many people experience unnecessary difficulties using their designs and enjoying content. In extreme cases, certain groups of users can’t use such a website effectively at all.
Building accessible content should be second nature to any developer, designer, or content creator, the same way the consideration of ramps, stairways, and lifts is to an architect designing a new building.
Let’s take a closer look at what’s behind the scenes and why so many developers seem to overlook web accessibility standards for no good reason.
1. What Does “Accessible Design” Mean?
Accessible content is content everyone can use. We don’t know all the aspects of how the users are accessing our content, so we need to design with accessibility in mind ahead of time.
As I highlighted earlier, this does not concern people with disabilities, accounting for about about 15% of the world’s population. In real life, users often end up not consuming content and interacting with devices in the exact same way as envisioned during development. Accessible content is also required for legal reasons in many jurisdictions. Read “Legal and Policy Factors in Developing a Web Accessibility Business Case for Your Organization” for additional information on accessibility compliance.
Consider the following scenarios while thinking about accessible content for users that may be:
- Unable to hear well. 360 million people worldwide have hearing disabilities. Audio content should have transcriptions and video should have captions.
- Unable to see well. 285 million people are estimated to be visually impaired worldwide: 39 million are blind and 246 have low vision. Users that are visually impaired they use screen readers (that read the content using synthesized speech), refreshable braille displays (screen content appears on the braille display, and the user can navigate and interact with their device using the keys on the display) or high-contrast mode.
- Affected by dyslexia. People with dyslexia find difficulty in reading and understanding content, especially, e.g., justified text or all caps.
- Suffering from physical limitations. Not all people can use all devices. For example, navigation through the content must be available not only for mouse users, but also for users that can’t use a mouse.
- Using mobile devices. Adapt your content for small screens. Allow the user to zoom or increase the font size.
2. How to Ensure Good Web Accessibility
People use very different ways of navigating and consuming content. There are users that need to be supported by additional software tools that helps them access content easier. These tools, known as assistive technologies, range from screen readers to touchscreens and head pointers.
However, your application and assistive technology need to talk to each other. Not everything that is written in HTML is fully understandable for assistive technologies. In order to help “translate” content from “technical language” to more human readable language, additional accessibility API standards have been created.
This basic web accessibility diagram should give you a better idea of how assistive technologies work.
<a href="#” class=”button”>Delete</a>
This simple code, for people who use the screen reader, doesn’t mean much. It’s even misleading and reads only as a link with the text “Delete”. In order to help users to understand what kind of method is used to perform the action, we can use ARIA (Assistive Rich Internet Applications) attributes (specified at https://www.w3.org/TR/wai-aria/) to override the original role. We change the meaning of a link to a button by adding attribute
role="button". In that way, screen readers will read it as a button, not a link. Which is more appropriate.
In short, attribute ARIA:
- Gives or enhances semantics of non-semantic or other-semantic elements,
- Ensures that dynamic (live) content is still accessible.
- Provides the role to describe the type of defined widget (menu, tree item, slider, progress meter, etc.).
- Provides the role to describe the structure of the web page (headings, regions, and tables).
- Provides the state of the widgets (checked, has popup, etc.).
- Provides properties for drag-and-drop that describe drag sources and drop targets.
What Is Accessibility in Web Design?
Whenever you design a content think about two things: how the content is perceivable and how it is operable. Let’s examine some examples to illustrate accessibility in web design.
Let’s say you are going to design a custom select dropdown element. Here are the things to consider while designing the element:
- Mark different states: enabled, disabled, read-only.
- Mark the element when it gets the focus/hover state.
- Mark every option element when it gets focus/hover state.
- Make sure the content is still readable when only the text is zoomed up to 200% level.
- Make sure that there is enough contrast between the text and its background. It helps people with moderately low vision or on devices in extreme lighting conditions, e.g., exposed to direct sunlight or on a display with low brightness, to read the content.
Another example could be selecting a color to describe a state. Here are the things to consider while designing a section where the user will be able to pick up a color:
- There are people that have difficulty distinguishing certain colors. So green doesn’t mean green for all your visitors. To fix it, add a description for every color that describes the purpose.
- Mark each element when it gets the focus/hover state.
- Make sure there is enough space between elements so that every element can be easily activated, e.g., on devices with a smaller viewport.
3. Accessibility Testing: Where to Begin?
There is no one way to check and be sure that web content is fully accessible. Multiple techniques need to be used in order to verify and fix the accessibility issues. You may start by defining issues, solutions, and priorities.
While working on accessibility issues, always try to create one ticket per problem with a clear title. This should simplify understanding the issue and help to define a priority.
Bad example: The user can’t use the keyboard on the page.
Good example: Unable to use keyboard navigation in the main menu.
The bad example leads to a case that will be quite difficult to close in a short time. Discussions on multiple topics might start in the comments section as well, as the ticket title is too generic.
The good example points exactly to the problem and focuses only on one thing: keyboard navigation in the main menu.
Prioritize Web Accessibility Issues
Priorities are important because they define which problems must be fixed first. For example, WCAG is divided by three conformance levels: A, AA, AAA, which means you should start from a minimum level A, but that doesn’t automatically mean that AA and AAA levels are merely “nice to have.” All of the levels are important, and it’s important not to prioritize assuming that level A alone is sufficient.
However, WCAG levels (or any other guidelines) might be quite difficult to understand sometimes and in order to simplify it a bit, you may also consider the following priority definitions:
- Critical – Issues that prevent users from using an application. No workarounds available.
- Major – Issues that make using an application difficult and/or disorienting, but don’t block a user’s ability to complete the operation.
- Minor – Issues that are annoying but do not hamper use, or enhancements that could be made to the application.
- Info – Does not adhere to best practices. General recommendations for improvements.
None of the guidelines—by which I mean WCAG, Section 508 or ADA—will give you a straight solution in terms of technical code for how a specified problem should be fixed. They only define expected behavior. However, WCAG additionally has defined test procedures that should help to understand how to reproduce the issue and there is an Automated WCAG Monitoring community group, a W3C community with a focus on developing reliable rules for web accessibility testing, both automated and semi-automated.
An example for WCAG technique G4 (“Allowing the content to be paused and restarted from where it was paused”):
On a page with moving or scrolling content,
- Use the mechanism provided in the web page or by the user agent to pause the moving or scrolling content.
- Check that the moving or scrolling has stopped and does not restart by itself.
- Use the mechanism provided to restart the moving content.
- Check that the movement or scrolling has resumed from the point where it was stopped.
No. 2 and No. 4 are true.
As we can see there are no technical solutions, but defined expected behavior. How web developer simplement it is up to them.
Web Accessibility Guidelines and W3C Standards
Following basic web standards should be your starting point:
- The most common is the Web Content Accessibility Guidelines known as WCAG. WCAG 2.0 is “a stable, referenceable technical standard. It has 12 guidelines that are organized under 4 principles: perceivable, operable, understandable, and robust. For each guideline, there are testable success criteria, which are at three levels: A, AA, and AAA.”
- Techniques for WCAG 2.0 is a comprehensive guide for web content authors.
- W3C Media Accessibility User Requirements — This document presents the accessibility requirements users with disabilities have with respect to audio and video on the web.
- Twenty-First Century Communications and Video Accessibility Act — The CVAA is divided into two broad titles or sections. Title I addresses communications access to make products and services using Broadband fully accessible to people with disabilities. Title II of the accessibility act breaks new ground to make it easier for people with disabilities to view video programming on television and the internet.
- Section 508 — accessibility requirements for information and communication technology (ICT) that applies to all federal agencies when they develop, procure, maintain, or use electronic and information technology.
- Website Accessibility under Title II of the Americans with Disabilities Act (ADA) — There, you’ll learn how the nondiscrimination requirements of Title II of the ADA apply to state and local government websites.