ac·ces·si·bil·i·ty: the quality of being able to be reached or entered.

What is accessibility and why is it important?

In a diverse world like ours, we cannot simply assume that all the users access and experience digital products in the same way. That's when accessibility becomes a crucial element of the design process that has inclusion and diversity in mind.

An accessible product — in it’s simplest sense is making sure that all of your users can consume your content. The products we work on are designed with the perceived majority of our users in mind — users who do not experience any difficulty in using a web or mobile application. In many cases, there is very little thought that is put into designing components for most products that work for almost any user — be it someone who has a broken hand, someone who’s hard of hearing, or someone who has visual impairments.

Digging deeper into accessibility statistics, it was found that close to 56.7 million Americans, that is 18.7% of the U.S population, experience some type of disability. Out of this number, it was found that 38.3 million have serious disability problems. This accounts for 12.6% of the entire U.S population.

These are figures are as of 2012, for just one country. When scaled up to the entire population of the world, these numbers would reach an alarming point, and it is no more a case of a “minority user base”.

Accessible design aids in creating a better experience not just for people with disability, but also for people without it.

Curbed ramps have been designed for helping people in a wheelchair move around cities. This also has a plethora of other uses — parents walking the streets with strollers, people out for a run, people using the sidewalk to skate etc.

Push to open buttons have been installed in most buildings to help people on a wheelchair open doors. This is also used by people to open doors when they’re carrying a lot of bags, or a child, or just use it all the time because it is easier than pulling/pushing doors open.

Section 508 Law mandates that federal agencies have their digital/electronic applications accessible to people with disability. Companies have a minimum required level of compliance based on WCAG to aid people with disability in using their products a lot easier.

More than laws and compliance rules, is it not just human to make sure that our products can be more widely used?

It is important to not view accessibility as a checkbox that you need to tick to meet requirements, but as a tool that helps to design for people, those we have been ignoring all these years.

Current landscape of Assistive Technologies

Before delving deeper into patterns, do’s and don’ts, it is imperative to get an understanding of how existing assistive technologies for the web work. The Mac OS comes with VoiceOver, and Windows users have the option of using NVDA (NonVisual Desktop Access).

It is highly recommended to try using a website by dimming the screen brightness and using assistive technologies such as VoiceOver or NVDA. This would help designers empathize with how users who are differently abled use the computer.

Assistive technologies for the web read three attributes of any component that is focused through tabbing — Role, Name, and Value.

Recommended visual patterns for an accessible interface

1. Color Contrast

The first step towards an accessible UI is to get the color contrast for your product right.

The recommended contrast is 3:1 for large text and 4.5:1 for small text.

What does this mean?
The readability created from the difference of foreground and the background color is the contrast generated. Large text is any font larger than 18px when bold, or larger than 24px for regular font-weight. Small text is anything smaller than 18px.

Tools that help with contrast check
Color Safe is a great tool if you are starting a project fresh and want to figure out beforehand what colors work for accessibility.

However, products we work on already have an established color guide, or a set of brand colors to choose from. In such cases, it is important to find contrast ratios of colors from the product’s palette. WebAim is the go-to tool for such checks.

Quickly identifying areas to improve contrast
Even the process of checking on WebAim for each of your foreground and background combinations can be a daunting task. A quick way to run a first-pass to get a sense of probable trouble points in your design is by using a nifty Chrome tool called Color Contrast Analyzer developed by awesome folks at NCSU.

This quickly identifies areas that require work on a screen. The areas on a screen that maintain good contrast is highlighted by white lines, and areas with poor contrast have subtle outlines that are not very prominent.

2. Focus

Focus is one of the most important accessibility features that enables users to use a computer with only a keyboard without the need for a mouse. Most reset stylesheets have this one line of code that causes major accessibility failure -

:focus {
outline: 0;
}

This is an anti-pattern that needs to be avoided like the plague. Keyboard only users know what elements on the page they are interacting with the help of focus styles.

Focus highlighting should be used only for interactive components within a page such as form elements, buttons etc.

There are websites out there, in the attempt to make their content more accessible, the heading and body text is tweaked programmatically to highlight on focus. This is absolutely unnecessary effort as screen readers would read the content out by default and directing focus to such content particularly does not help in any way. There are a few caveats to this rule which will be discussed later with examples.

Focus Contrast

As a rule of thumb, it is necessary to have the focus color as distinct as possible from your background color.

Off-screen content

When off-screen content hidden from the viewport exists in the form of hamburger menus, modals etc, it is likely that when a user is tabbing through focus points, they would lose track of the focus as it is highlighting something that is off the working area. This can cause confusion and make users lose track of their current position on the screen.

Recommended Solution: One way to tackle this issue is by either hiding the elements when the menu is closed with CSS with display: none, or making sure the focus does not enter the menu when collapsed by programmatically altering the flow of focus with JavaScript.

Modals

Modals are another type of off-screen elements that can be a huge accessibility disaster when not executed fittingly. When a user is navigating within the modal, it is necessary for the focus to remain within the modal and not move through points behind the modal.

This is one of those rare use-cases where it is okay to programmatically force the focus to get to the title of the modal window to ensure that users are not deviating from the intended flow.

Hover States and Focus

Hover states and focus have different functionality. Many products have actions hidden under hover states. A good example is Facebook’s hover states for reactions.

A bad example is Product Hunt’s cards. They show multiple actions that become visible only on hover which is not keyboard-only accessible.

Scenarios to “re-focus”

When an UI element on the page is removed from a user’s action, it is important to refocus to an element within the context of the current working area. A good example to this is when a user decides to delete an item — the focus disappears from the current element and moves to the top of the page. There is a clear need to bring the focus back to an element after the deleted item.

3. Click Targets

Cards

Cards are very prominently used in products these days. Thanks to Material Design, there is a lot of structure and guidance over how cards should be designed. However, it is important to create accessibility-friendly ones. Cards can get quickly complex with multiple states based on the type of interaction being performed on them.

Another bad example of card design are cards used on the Product Hunt page (Sorry guys, I really love Product Hunt but this seemed like another apt example). Imagine a user tabbing through these cards without using a mouse.

A great example of how cards can be made accessible is Google Inbox —

☑ They assign specific focus states for cards when they are navigated to.
☑ They hover action is accomplished when on focus.
☑ Only actionable items are focused and not every element within the card.

Target Areas

Users with motor impairments find it hard to select items on the page with precision. It is our job as designers to make sure that target areas are not very narrow or hard to access.

4. Quick Access to Content

If you are a user navigating with only a keyboard, and you would like to get to the content immediately. But, there is a high possibility that there are multiple menu items or other navigational items before you can actually get to the content of your product.

It can be a pain for users to sift through each one of those links before they can get a glimpse of the product.

Below is an example of a bad experience from a very famous blogging platform —

One possible solution to this problem is by providing a quick way for users to jump to the content as they start tabbing through the product. Below is an example of how AirBnB achieves this.

5. Summarizing Information

It is tricky to get an ideal experience when a user with accessibility needs is going through a checkout process, or any flow that consists of multiple steps. Use-cases to such a scenario can be —

1. Booking a flight ticket.
2. Searching after filtering with a bunch of options.
3. Adding items to a cart and checking them out.

It is of primal importance to give the user a summary of information that is being entered before or after they hit the call to action.

This rule holds applicable in UI components such as a date picker, steppers or setup wizard etc. This is particularly tricky because you don’t want redundant information to be visible for users without accessibility needs.

Recommended Solution: When users are tabbing through information, there could be elements that I’d like to call “Ghost elements” that show up only when a user tabs through complex UI components such as date pickers. These ghost elements contain a brief summary of the selected value that the screen reader can read out to users for confirmation.

Such an approach is usually critiqued as power users who navigate with keyboard faster will have to tab through twice to get to the next element. This is when the accessibility toggle comes into the picture.

6. Accessibility Toggle

For most products, it is a small, yet important fraction, of users who require assistance for a better experience. To not interfere with the experience for the larger fraction of users, there should exist a switch that toggles between accessibility mode and default mode.

The accessibility mode should contain a color scheme that offers high contrast and easy navigation between elements on the page especially when it is in the form of keyboard-only interaction.

Closing Thoughts

Accessibility should be inscribed early in the design process as it gets harder to allocate resources and time for handling it as a standalone project. Every component or pattern designed should be vetted with accessibility as a parameter.

There will be a detailed how-to on methods — to write code for web-accessibility and how to test it — in an article that would follow this.

I am interested in learning more about your process for designing accessible products in comments below.

We have invited Adhithya to be part of this series for his work with accessibility at OpenDNS. Making our products accessible is a crucial step for a more inclusive design in our diverse world.

See you in the next article.