In the U.S., more than 1 in 4 adults live with some type of disability. They search the web, shop online, stream movies, use apps, and access digital content, and it should come as no surprise that they want, expect, and deserve equal access to your products.

Designing for accessibility and inclusion should matter to every UX and UI designer. Accessibility lets individuals with visual, motor, auditory, speech, or cognitive impairments get the best experience possible from your website or product. Designing for accessibility doesn’t mean your product’s UX or UI will suffer. By looking at things from different points of view, products become that much better.

What does it mean to design for accessibility?

Designing for accessibility means creating designs to meet the diverse needs of the users who engage with your products. Ask yourself a few questions about who you design for:

• Would someone who is color blind or visually impaired overlook crucial details in your UX/UI?
• Would someone who is deaf or has hearing difficulties miss notifications or alerts in your app?
• Would someone with mobility challenges lack the motor skills to navigate your website?

Not sure where to start? There’s an official set of guidelines.

Accessibility design best practices

Accessibility best practices for designers are set by the Accessibility Guidelines Working Group.

When designing for accessibility, a great resource for confirming that your work is Section 508-ready is the Web Content Accessibility Guidelines 2.1 (WCAG). Go ahead and bookmark it now. You’ll refer to it a lot while you’re designing for accessibility.

You’ll find there’s always a way to make your UX/UI more accessible. It’s not much different than making product changes to fit in a new feature or to adjust for more compatibility to attract even more customers. 

There’s not just one fail-safe approach to designing for accessibility and inclusion, but there are best practices to keep in mind and general rules you’ll want to consider. 

Don’t make color the only visual way you convey information

Color text is difficult, if not impossible, to read against backgrounds with low contrast. Now, imagine you’re one of the 12 million Americans over the age of 40 who are visually impaired or legally blind, or one of the 3.7% of Americans who are color blind, and trying to make sense of web content with no more than color as a visual cue.

To help in situations like these, use thick borders, bold text, italics, and underlines in your designs. Test your layouts in black and white to determine their readability. When showing errors on screen, add in icons or labels. Want to check the WCAG color-contrast ratios in your layout? Consult the Contrast app for Mac or the online WebAIM contrast checker.

Whatever accessibility solution you choose, try to move beyond any internal bias for color text.

Increase contrast between text and backgrounds

A lack of contrast between text and background makes it hard for anyone using your product to read what’s on screen. So just imagine the user experience for the visually impaired.

To get a feel for the experience, step away from your crisp Retina display (the way most designers see the world) and find a conference room with a projector. Then, plug a VGA adapter into your MacBook and see what low-contrast UX/UI designs look like for people with a visual disability.

Spoiler alert for those trying this exercise: low-contrast designs become fuzzy and washed out.

However, designing for accessibility and inclusion for those dealing with low or worsening vision issues (including color blindness) is a surprisingly easy fix. It’s all about tweaking designs for higher contrast. The contrast ratio between text and its background needs to be at least 4.5 to 1.

The WCAG does cite a few exceptions to this contrast ratio, such as:

• If your font is at least 24 px (or if bold, 19 px) that minimum ratio can go down to 3 to 1.
• Text (or images of text) within an inactive UI component has no contrast requirement.
• Text within a corporate logo, brand name, or logotype also has no contrast requirement.

Plus, WCAG suggests colors with higher contrast to add to the overall UX/UI color palette.

Use labels or instructions with form fields and input

“Modern” design favors a minimalist approach. Often, this means getting rid of any clearly defined boundaries or visible labels in form fields. Great for a clean design aesthetic but not as great for those dealing with cognitive disabilities or mobility impairments.

Users with cognitive disabilities may struggle to find and interact with form fields without the visual cues of a more traditional design. Placeholder text isn’t as intuitive as a visual label.

For someone with mobility impairments or limitations, knowing where to click (or simply having a good-sized, click-target field to interact with) makes a big difference, especially for people using adaptive pointing devices or other adaptive technologies available for accessibility needs.

When designers remove or hide labels or directions in forms, usability suffers for sleek design.

People using screen readers to tab through form fields also depend on form labels to navigate. Screen reading devices actively skip past non-label text in search of label elements. Under that non-label text category? Placeholder text. Always include labels and defined form boundaries.

Make navigation and focus states easily identifiable 

In 2024, 94.1% of global internet users reported accessing the web via smartphones, which may also mean that even fewer websites will offer focus states for their users.

Focus states help communicate to users when they’ve highlighted an element on a website’s interface using their keyboard or voice. These indicators are not supported by other visual cues.

Go ahead and visit a website on a laptop or desktop computer. Press the tab button repeatedly. 

Look for a visual focus indicator. Do different elements of the site become highlighted? Usually this means outlines around buttons, links, or input fields. These focused states are super helpful for people with limited mobility or who use screen readers yet more and more websites lack them.

Write useful alternative text for images 

Screen readers are a big consideration when it comes to designing for accessibility and inclusion needs. People who are visually impaired often use screen readers to read the web to them.

By converting text to speech, users can actually hear the words on a website. When the screen reader encounters an image or photo, it will describe it to the user. The quality or helpfulness of that description varies greatly.

Screen readers pick up descriptions within the <alt> attribute of the image element or within the context or surroundings of the image itself. Often, this means only hearing the word “picture.”

Other times, screen readers just read the image’s file name. Talk about an underwhelming user experience! All because there was no alt text written. Write a description that gives users context for the image, explains what’s going on, and how it relates to the story.

If an image is only there for decoration or is redundant, make it skippable for screen readers by adding an empty <alt> text attribute. Fortunately, Google’s image-captioning AI continues to improve, but just in case, keep offering useful alt text for images.

Use the correct heading markup for content

Designing for accessibility and inclusion can be as simple as providing the right headings.

Text headings define style and purpose for sites. They establish the hierarchy of the page’s content.

When developing a site, incorporate the right structural elements into your HTML. This helps browsers treat the content appropriately. It also sets up the accessibility tree for your page, the info screen readers take in to read and to describe everything to visually impaired users.

Knowing that screen readers navigate web pages by true headers, don’t use HTML tags just for style effect. Designing for accessibility means users can “hear” your UX/UI in a meaningful way.

Don’t rely on hover states to reveal links

Like previously mentioned, focus states are often indicated by the distinct outline noticeable around buttons, links, or input fields. This is a CSS pseudo-class utilized by most web browsers.

Many designers aren’t fans of the default focus indicator—some might even try to hide them. Rather than just bypassing this focus state, come up with something better. 

You might be tempted to use the old reliable hover state CSS to reveal links for users, but when doing so, think about the people in your audience with accessibility needs. These audiences may interact with your product without the benefit of a mouse to click and drag the pointer. Hover states are also a nuisance for anyone navigating with a touchscreen.

Instead of replacing focus states with hover states for design’s sake, place secondary actions inside of menus or non-modal dialogs, or let secondary icons darken for contrast when hovered or tabbed on. Whatever solution you choose, avoid hiding info useful to screen readers or voice technology.