designing for accessibility

7 best practices when designing for accessibility

Reading time: about 9 min


  • Customer experience

In the U.S. alone, 61 million people (over 1 in 4) live with some type of disability. Like everyone else, they search the web, shop online, stream movies, use apps, and access digital content. It should come as no surprise that they want, expect, and deserve equal access to your products.

And really, designing for accessibility and inclusion should matter to every UX and UI designer.

After all, great digital products are made for everyone’s enjoyment. Accessibility lets individuals with visual, motor, auditory, speech, or cognitive impairments get the best experience possible from your product. Designing for accessibility doesn’t mean your product’s UX or UI will suffer.

If anything, most designers welcome the challenge. Constraints inspire creativity and spark new ways of thinking. By looking at things from different POVs, 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 really 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 who has mobility challenges lack the motor skills to navigate your website?

How can we know the needs of every user imaginable or what we should design to make a better product experience possible? It never hurts to start off with an official set of guidelines.

Accessibility design best practices

Design best practices for accessibility 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. Or as all the cool design kids call it, the WCAG.

Go ahead and bookmark it now. You’ll refer to it a lot while you’re designing for accessibility.

Whatever the ability, context, or situation that users tackle, 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.

Whatever the disability—a mobility handicap, a cognitive impairment, a hearing loss, or a visual difficulty—there’s never 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 5.5 million Americans over the age of 40 who are visually impaired and legally blind and who are trying to make sense of web content with no more than color as a visual cue.

Even the 7.4% of Americans who are color blind (unable to distinguish red from green) struggle to read color text on screen. 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.

designing for accessibility

Have contrast between text and background

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

To get a gut feel for the struggle, 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 the color blind) is a surprisingly easy fix. It’s all about tweaking designs for higher contrast. For the basics, 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 even suggests colors with higher contrast to add to the overall UX/UI color palette. Warning: many UX and UI designers discover they prefer designing to higher contrast anyway.

Use labels or instructions with form fields and input

“Modern” design favors a minimalist approach. Many times, this means getting rid of any clearly defined boundaries or visible labels in form fields. Great for a clean design aesthetic. For those dealing with cognitive disabilities or mobility impairments? Not so much. So keep this in mind.

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 

By 2025, almost three-quarters of the world’s internet users will access the web solely via their smartphones. Which may also mean that even fewer websites will offer focus states for their users.

Focused 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.

Consider how critical focused states are to designing for accessibility. Browsers have default focused state styles of their own that can easily be customized to fit your site’s UI look and feel.

Write useful alternative text for images 

Screen readers are a big consideration when it comes to designing for accessibility and inclusion needs. The 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 wildly and depends on the effort the design team puts into the UX/UI.

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. For accessibility’s sake, 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 and is almost 94% accurate by some standards. But for now, keep offering useful alt text for images.

Use the correct heading markup for content

Yes, 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. Bigger font sizes indicate a title, helping users to better figure out the order of the 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 count on hover states to reveal links

Like previously mentioned, focused 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. If this is you, don’t. Rather than just bypassing this focused 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. Of course, hover states are also a nuisance for anyone navigating with a touchscreen.

Instead of replacing focused 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. But whatever you do, avoid hiding info useful to screen readers or voice technology.

Designing for accessibility and inclusion is a worthwhile pursuit. Instead of looking at the ways it may limit or affect your usual design preference, consider how the challenge drives creativity and makes your UX/UI much more impactful, intuitive, and appealing for a wider range of users.

Establish your accessible design best practices and collaborate with your team today in Lucidspark.

Get started

About Lucidspark

Lucidspark, a cloud-based virtual whiteboard, is a core component of Lucid Software's Visual Collaboration Suite. This cutting-edge digital canvas brings teams together to brainstorm, collaborate, and consolidate collective thinking into actionable next steps—all in real time. Lucid is proud to serve top businesses around the world, including customers such as Google, GE, and NBC Universal, and 99% of the Fortune 500. Lucid partners with industry leaders, including Google, Atlassian, and Microsoft. Since its founding, Lucid has received numerous awards for its products, business, and workplace culture. For more information, visit

Related articles

  • All about the Double Diamond UX design process

    Double Diamond UX design is a customizable, structured framework that promotes divergent and convergent thinking.

Bring your bright ideas to life.

Sign up free

or continue with

Sign in with GoogleSign inSign in with MicrosoftSign inSign in with SlackSign in

By registering, you agree to our Terms of Service and you acknowledge that you have read and understand our Privacy Policy.

Get Started

  • Pricing
  • Individual
  • Team
  • Enterprise
  • Contact sales
PrivacyLegalCookie privacy choicesCookie policy

© 2024 Lucid Software Inc.