How to Design & Develop for WCAG Compliance

Design

2021-09-17T18:24:53.447Z

Zigzag

When developing a software product, your designs aim to solve a specific need for a target group of potential users.

This usually means making some assumptions about the average user and then building a product for that user with some consideration made for different roles and technical proficiencies. These assumptions usually place no restrictions (within reason) on the size of UI elements, the colors used, or the complexity of interactions/gestures required.

While it’s important to focus on the average user, you should consider the diverse needs of your user base, including those users who rely upon Assistive Technologies (AT) and those who may otherwise have difficulty interacting with your product.

Throughout the design and development planning, consider how you can make Web Accessibility an integral part of the process rather than an “add on”.

What is Web Accessibility?

Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or access to websites and applications by people with disabilities. When websites are correctly designed and developed, all users will have equal access to their information and functionality. The Web Content Accessibility Guidelines (WCAG) are a series of technical guidelines designed to measure digital accessibility and can help you better understand and ultimately implement web accessibility.

What assistive technologies are most common when designing and developing an accessible experience?

  • Screen readers
  • Screen magnifiers
  • Color contrast analyzers
  • Speech-to-text and text-to-speech software
  • Keyboard only and alternative keyboard devices

Designing for accessibility from day one can save on future development time, should you decide you need accessibility features down the road. Depending on the complexity of your product and the technologies used, providing an accessible experience may only be possible through a complete rework of the product.

Costs aside, designing for accessibility can provide benefits to all of your users. With regulations constantly changing, and with an aging population (at least in the United States), you can’t afford to treat the accessibility needs of your users as an afterthought.

The Importance of Contrast

Modern brands often use vibrant color palettes to express a youthful nature and visually tell their story. Designers might feature this palette across the site, like in the example below, but the lack of contrast can limit the site’s accessibility to visually-impaired visitors.

A. The white text (even the large heading text) on that transparent color does not create enough contrast.

B. The light blue/green text on white does not create enough contrast.

C. The body text is too small to be fully legible.

This might seem subjective but there are actually hard, fast rules when it comes to contrast and accessibility.

The Web Content Accessibility Guidelines (WCAG) outline two levels of contrast compliance. Level AA requires a a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, while Level AAA requires a contrast ratio of at least 7:1 for normal text and 4.5:1 for large text.

Large text is defined as 14 point (typically 18.66px) if bold, or 18 point (typically 24px) if not.

Luckily, there is a handy tool that can help you ensure that your contrast levels are compliant.

Here is what this design might look like if it had been designed with compliance in mind.

All text is significantly darker, the photo filter has been darkened, the body copy size has increased, and there are clear dividers in the navigation.

The Importance of Size and Functionality

Recently at Devetry, we designed a form that included date selection.

Date inputs can be handled any number of ways, from standard text inputs to calendar-based datepicker widgets. If you’re not designing for AT users, an off-the-shelf datepicker module often provides the most bang for the buck. As opposed to standard text inputs, datepickers provide an easy-to-understand, calendar-based UI for average users.

That’s all well and good, but:

If you’re a user with limited eyesight, how are you going to read it?
Datepickers usually utilize lots of small text that is close together. Users with limited eyesight may have difficulty navigating between available months/years, and may have trouble finding a particular date. Design for these users by increasing color contrast and font size.

If you’re a user with limited mobility, how are you going to interact with it?
Datepickers usually include many small buttons that are close together. Users with limited mobility may have difficulty using a mouse and/or touchscreens, and small buttons may be impossible to click. To help, increase button size and make the datepicker usable with only a keyboard.

If you’re a user with a cognitive disability, how are you going to understand it?
Datepickers usually include hide/show functionality, and require calendar navigation (typically by month), with little explanation. Although many users understand how a datepicker works through previous exposure, users with cognitive disabilities may find such a complex interface daunting. Add help text and decrease UI complexity overall (e.g., remove hide/show transitions) to improve the experience.

If you’re a user relying on a screen reader, how are you going to use it?
All of the above problems may be present for screen reader users, but these users have the additional challenge of being unable to see the datepicker itself. These users rely on screen reading software to not only read the words on the page but also provide context to the various elements. In the case of the datepicker, you need to convey what the element is (a datepicker), what it expects (a date), and how to interact with it (via a calendar interface with many buttons). This is challenging as just a thought exercise, let alone as a development task. The solution lies in adding screen reader-specific help text, implementing keyboard navigation, and decreasing UI complexity.


With all these additional requirements, it may be tempting to provide different experiences to your various users.

For example, we could have provided simple text input for AT users and a calendar-based datepicker for the remaining users. However, separating experiences increases development time (because you’re now creating and maintaining two UIs) and an inferior experience for AT users. Besides, additional development time is still required to make the (subpar) AT experience usable.

We ultimately decided away from the datepicker altogether. While it may have been intuitive for most users, it made assumptions about our users’ abilities. Using a “standard” datepicker places the burden on the user to understand and manipulate a fairly complex UI in a relatively small amount of space.

Instead, we built a datepicker with a series of year/month/day dropdowns, because:

1. Dropdowns have simple behavior (hide/show, select a value) that does not require modification or extra explanation

2. Dropdowns are easy to use via keyboard, touch or mouse

3. Dropdowns help prevent invalid input

Instead of ignoring the needs of some of users, we used Web Accessibility constraints to our advantage. A product (datepicker) that might be difficult to read, use, or understand for some users is likely a product that is too difficult to read, use or understand overall. So, instead of looking at our users as the problem, we looked to solve the problems in the product itself.

100% web accessibility is difficult to achieve, but that doesn’t mean that you should avoid it altogether. Implementing a few accessibility-minded features can make your product available to new users while improving the experience for all of your existing ones. Designing with accessibility in mind forces you to simplify your solutions, reducing effort in the long run.

Educate your team, follow the guidelines, and plan for Web Accessibility from every project’s beginning to ensure you’re designing the best possible experience for all users.