Accessible experiences

“Accessibility” refers to the design of products, devices, services, and environments for people who experience different types of disabilities. At Intuit, we work to create truly accessible products that address both “direct access” (unassisted by another device) and “indirect access” (compatibility with a person’s assistive technology, such as a screen reader or keyboard).

Our goal is to ensure our ecosystem of products meets criteria in the Web Content Accessibility Guidelines 2.1. Check out WCAG 2.1 at a glance

Why is this important?

Our mission at Intuit is to power prosperity around the world, which means delivering awesome experiences for ALL our users. As designers and engineers, it is our responsibility to create products and services that everyone can use, no matter the level of their physical or cognitive ability.

About 20% of the population has some sort of disability that makes it tough to hold a job or do work on the web. This percentage will continue to grow as people live longer while managing health conditions.

Why do we have accessibility guidelines?

This info is meant to educate and guide designers and engineers. The guidelines also help everyone who works on our products understand the importance of keeping accessibility top of mind from the very beginning and throughout the design and development process. It starts with empathy. The work we do as designers and developers starts with gaining a deep understanding of our customers’ problems and the challenges they face. Laws and regulations aside, making our products accessible is just the right thing to do.

Our accessibility principles

When we create accessible products, we make things better for everyone–with increased access, reduced friction, and smoother experiences for the greatest number of people.

Our guidelines for web content accessibility are driven by four principles: Perceivable, Operable, Understandable, and Robust (POUR). Keep these accessibility points in mind as you plan, design, and build our products.


All our users need to be able to understand what’s on the screen. Is there anything in our product or on our site that a blind, deaf, low vision, or color blind user can’t perceive?


Make sure all videos have captions.

Include meaningful alt text for images, icons, and controls. If it’s text meant to be read, don’t put it in an image.

When a label is used multiple times on the same screen (Edit, Learn more), provide screen-reader-only text to your PD partner to put in the code to clarify (Edit profile, Learn more about banking).

Create text alternatives for charts and graphs. A cool way to do this is to include a data table near the chart.

In-flow content shouldn’t refer to color, or where elements are on a screen.

Color and contrast

Check your contrast. AA contrast standards are 3:1 for UI elements, 4.5:1 for normal text, and 3:1 for large text.

Linked text should stand out from body text.

Don’t use color alone to indicate status. Include icons with text to make things clear.

Focus indicators should be highly visible on fields and all interactions. Really, really visible. Now is not the time to be subtle.


Font face, size, and weight are all elements to consider when designing for readability and legibility.

Keep in mind that some people with low vision use screen magnifiers, or zoom in to enlarge text and make things easier to read.


Interactions and targets

Make sure you can keyboard through the entire UI. Keyboarding order should be left to right, top to bottom, without skipping any interactive elements, including info icons and tool tips.

Make sure interactions are well-separated and easy to hit with a cursor or a tap.

Keep screens feeling “light” – don’t make them overly dense.

Targets on mobile

Make sure everything is thumb-able.

Targets should have a minimum height, width of 48px and have enough space between them so they can be selected individually.

Touch targets should be visually identifiable. Is it clear what to do next?


Make sure fields labels persist and are visible when the focus is inside the field.

Labels, tooltips, and input fields should appear in the right keyboarding tab order.

Present errors clearly, use an element in addition to color, and tie to the right field in the code.

Make sure field validation happens only when the form is submitted, rather than when focus moves to a new field.



Keep content clear and easy to read and listen to. Remember that when someone is using a screen reader, the content is spoken aloud.

Present only the info users needs, and only when they need it.

Keep sentences simple. Aim for 5th to 8th grade readability.

Use images to support content. Illustrations and graphs can clarify complex concepts. Just make sure that any images or graphs also have a text alternative.

Info hierarchy and layout

Make page titles unique and informative.

Keep heading styles consistent. Use typography and styles to provide meaning and structure.

Make sure the correct HTML is used (H1, H2, etc.), so that screen readers can easily interact with the page structure.

Use headings, sub-headings, and bullet points to make content easy to scan.


Make sure things work well enough across platforms, browsers, and devices–different assistive technologies work better in some areas than others.

Try to be platform agnostic.

Don’t dictate the technologies a user has to use.

Experience and empathy resources

Do you have a daughter in the fourth grade? A father who runs his own business? A friend who’s an accountant? What if someone close to you lost their hearing, vision, or mobility?

When we have empathy, it makes us better designers and better at solving problems for our customers. Having a hard time imagining what using an assistive device is like? Here are some short videos to give you an idea of how people use assistive technologies to access information on the web and navigate through interfaces.

Design resources

There are tons of accessibility tools, plugins, and extensions available to help you test your designs. Here are a few popular tools to get you started.

Figma plugins
Stark (contrast and accessibility checker)
Accessibility Annotation Kit (for that hand-off moment)

Web tools
Stark for Chrome
Stark for Safari
WAVE Chrome & Firefox Extension (for evaluating issues)


Accessibility Cheat Sheet
Check out our cheat sheet and learn to build accessible products for everyone. Download a PDF cheat sheet for:

Design hand-off

Content readability tools
Hemingway App Editor
Readability Test Tool

WCAG 2.1 Checklist
WCAG 2.1 Checklist


Help & support

Accessibility Office Hours

Come learn more about accessibility, get feedback on design or development, test with users, set up a research session, and much more. There are office hours for different segments and different geographies.

Find an accessibility office hours slot


Quick help

Just need to get a question answered or get some quick feedback? Try one of these channels.

Slack: #cmty-accessibility
Jive: in/accessibility

Recruit and Test Users

Submit a specific request for accessibility testing through the Intuit Research Studio: Customer Connect


  • Was this Helpful?