Product Design: Accessibility & Inclusivity Checklist

• Design with people who are colorblind in mind.

• Different types of colorblindness prevent 3 million or 4.5% of people from using colors as key indicators for a message.

1.4.1 Use of Color (A) (2.0)

• When the color of words, backgrounds, or other content is used to convey information, also include the information in text.

• Links should always be easily identifiable through non-color means, including both default and hover states. The easiest and most conventional way to signify links is underlining.

• Required fields and fields with errors must include some non-color way to identify them.

• Design with users of screen readers and people with low vision in mind.

• If you want to use images that convey meaning, make sure they have parsable text alternatives or captions.

1.1.1 Non-text Content (A) (2.0)

• All img tags must have alt attributes. 

• If short alt text is sufficient to describe an image, provide the short text via the image's alt attribute.

•  If a short text alternative is not sufficient to describe an image (such as in a chart, graph, or diagram), provide short text via the image's alt attribute, and include a long description in nearby text.

• If an image or icon is used as a button or link, the image has a text alternative sufficient to describe the purpose of the button or link.

• Images that are decorative, used for formatting, or contain content already conveyed in text have a null alt attribute or are implemented as CSS background images.

• Frames and iframes have descriptive titles.

• Minimize the number of adjacent links to the same destination by combining adjacent images and text into a single link, rather than creating a separate link for each element.

1.4.5 Images of Text (AA) (2.0)

• Avoid images of text, except in cases such as logos.

2.4.2 Page Titled (A) (2.0)

• Make sure each web page has a title tag that is descriptive, informative, and unique.

2.4.4 Link Purpose (In Context) (A) (2.0)

• If the visible text alone is not sufficient to convey meaning, use advanced techniques to provide additional meaning, such as ARIA attributes, screen reader only text, or the title attribute.

• The purpose of each link can be determined from the link text alone, or from the link text and the containing paragraph, list item, or table cell, or the link text and the title attribute.

2.5.3 Label in Name (A) (2.1)

• The accessible name for a UI element must contain any visual label for the element. Accessible names for UI elements should match visual labels as closely as possible.

3.1.1 Language of Page (AA) (2.0)

• When a visual label is present for an interactive element (e.g. link or form control), the accessible name of the element should contain the visual label.

• Provide a lang attribute on the page's html element.

3.1.2 Language of Parts (AA) (2.0)

• If a portion of the page is in a different language, use the lang attribute on that part.

3.3.2 Labels or Instructions (A) (2.0)

• Use semantic, descriptive labels for inputs. Visually position labels in a consistent way that makes associating labels with form controls easy. Do not rely on placeholder text in lieu of an HTML label.

• Provide text instructions at the beginning of a form or set of fields that describes the necessary input.

• When providing inline help text, use aria-describedby to associate the help text with the input.

4.1.1 Parsing (A) (2.0)

• Validate all page HTML, and avoid significant validation / parsing errors.

4.1.3 Status Messages (AA) (2.1)

• When conveying a status message, use ARIA live regions or ARIA alerts to announce the message to screen reader users.

• Design with people who are deaf or hard of hearing in mind.

• Provide closed captioning or transcripts for audio clips or video so audio is required to understand the content. Closed captioning for both audio and video content is required for users who are deafblind.

1.2.1 Audio-only and Video-only (Prerecorded) (A) (2.0)

• For pre-recorded audio (without video), provide a descriptive transcript that includes dialogue and all other meaningful sound.

• For pre-recorded video (without audio), provided a text alternative or audio descriptions that provide the same information presented.

1.2.2 Captions (Prerecorded) (A) (2.0)

• Provide captions for prerecorded audio content in non-live synchronized media.

1.2.3 Audio Description or Media Alternative (Prerecorded) (A) (2.0)

• For non-live video, provide a descriptive transcript or an audio description.

1.2.4 Captions (Live) (AA) (2.0)

• Provide captions for live audio and video.

1.2.5 Audio Description (Prerecorded) (AA) (2.0)

• Videos should include "radio style" narration so that content makes sense if someone is consuming just the audio track. Include any text elements in the narration.

1.4.2 Audio Control (A) (2.0)

• Do not have audio that plays automatically on the page. When providing audio, also provide an easy way to disable the audio and adjust the volume.

• Design with people with low vision and users of screen readers in mind.

• Text should accompany visual error indicators like color or images.

1.3.3 Sensory Characteristics (A) (2.0)

• Do not identify content based on its color, size, shape, position, sound, or other sensory characteristics.

• Do not convey information solely through icons or symbols.

1.3.5 Identify Input Purpose (AA) (2.1)

• If a form field asks for information about the user and if there is an appropriate HTML autocomplete attribute, include that autocomplete attribute.

3.3.1 Error Identification (A) (2.0)

• Identify errors using aria-invalid.

• Programmatically indicate required fields using the required or aria-required attributes. Also, visually indicate required fields in the form's instructions or form labels. Do not indicate required fields for CSS alone.

•  Make errors easy to discover, identify, and correct.

3.3.3 Error Suggestion (AA) (2.0)

• If an input error is detected and if suggestions for correction are known, provide suggestions for fixing the submission.

• Design with people with low vision, users of screen readers, and people with photosensitive epilepsy in mind.

• Pages shouldn’t contain anything that flashes more than three times in any one second period or require animation for meaning.

2.3.1 Three Flashes or Below Threshold (a) (2.0)

• Do not provide any content that flashes more than three times in any 1-second period.

2.5.4 Motion Actuation (A) (2.1)

• Avoid activating functionality through motion (e.g. shaking a phone). If motion triggers functionality, provide a way to disable the motion trigger, and provide an alternative way to activate the functionality.

• Design with people with anxiety in mind.

• Give users an option to undo their mistakes without repercussions.

2.5.2 Pointer Cancellation (A) (2.1)

•  Avoid triggering functionality on down-events, such as onmousedown. Use events such as onclick instead.

•  If a function is triggered on an up-event (e.g. onmouseup), provide a way to abort or undo the function.

• Design with people with low vision in mind.

• Insufficient contrast between text and background colors makes content hard to read. Similarly, insufficient contrast between UI elements and backgrounds can be difficult to see.

• Try using Figma plugins such as Contrast or Stark that check contrast ratios in your designs.

1.4.3 Contrast (Minimum) (AA) (2.0)

•  Text (including images of text) have a contrast ratio of at least 4.5:1. For text and images of that is at least 24px and normal weight or 19px and bold, use a contrast ratio that is at least 3:1.

1.4.11 Non-text Contrast (AA) (2.1)

•  Color contrast for graphics and interactive UI components must be at least 3:1 so that different parts can be distinguished.

•  When providing custom states for elements (e.g. hover, active, focus), color contrast for those states should be at least 3:1.

• Design with people who are low vision, users of screen readers or those who are hard of hearing in mind.

• Ensure that if content is read through a screen reader, that it makes sense and is easy to follow. Use landmarks and headings.

1.3.1 Info and Relationship (A) (2.0)

•  Use semantic markup to designate headings, lists, figures, emphasized text, etc.

•  Organize pages using properly nested HTML headings.

•  Use ARIA landmarks and labels to identify regions of a page.

•  Reserve tables for tabular data, use table headers appropriately, and use table captions.

•  When the appearance of text conveys meaning, also use appropriate semantic markup.

•  Avoid emulating links and buttons. Use the a and button tags appropriately. Avoid using a tags for buttons. Avoid using div, span, etc. tags for links or buttons.

•  Avoid using whitespace characters for layout purposes.

1.3.2 Meaningful Sequence (A) (2.0)

•  Ensure that the source order presents content meaningfully. When the page is viewed without styles, all content on the page should still appear in a meaningful and logical order.

1.4.13 Content on Hover or Focus (AA) (2.1)

•  For tooltips, follow corresponding ARIA authoring practice.

•  For content that appears on hover and focus: the content should be dismissible with the escape key; the content itself can be hovered over; and the content remains available unless it is dismissed, it is no longer relevant, or the user removes hover and focus.

•  To the extent possible, content that appears on hover or focus should not obscure other content, unless it presents a form input error. or can be dismissed with the escape key.

2.4.3 Focus Order (A) (2.0)

•  Create a logical tab order through links, form controls, and interactive objects.

•  When inserting content into the DOM, insert the content immediately after the triggering element, or use scripting to manage focus in an intuitive way. When triggering dialogs and menus, make sure those elements follow their trigger in the focus order in an intuitive way. When content is dismissed or removed, place focus back on the trigger.

•  Avoid using tab index values greater than 0.

2.4.6 Headings and Labels (AA) (2.0)

•  Ensure that on each page, headings, landmark labels, and form labels are unique unless the structure provides adequate differentiation between them.

3.2.3 Consistent Navigation (AA) (2.0)

•  When components are repeated across web page, they should appear in the same relative order with regard to other repeated components on each web page where they appear.

•  When a navigation menu is presented on multiple pages, the links should appear in the same order on each page.

• Design with people with low vision in mind.

• Screen magnification can help optimize the visual experience for people who have low vision.

• Magnification softwares like ZoomText and MAGic can also help users adjust color schemes if they experience difficulty, or even pain, from viewing bright lights.

• Designing with people with low vision, users of screen readers, or those who are hard of hearing in mind.

• Ensure that content read through a screen reader makes sense and is easy to follow. Use landmarks and headings.

• Design with people with motor disabilities or people using touch screens in mind.

• Users may not always experience your products on the device you expect.

• Add alternatives to hover states to convey information.

• Give interactive elements enough space for someone to click. Design for keyboard or speech-use-only use.

• Provide shortcuts to avoid a lot of typing or scrolling.

1.4.4 Resize text (AA) (2.0)

• Ensure that there is no loss of content or functionality when text resizes.

• Define texts and text containers in relative units (percents, ems, rems) rather than in pixels.

1.4.10 Reflow (AA) (2.1)

• Provide responsive stylesheets such that content can be displayed at 320px wide without horizontal scrolling. (Content which must be displayed in two dimensions, such as maps and data tables, may have horizontal scrolling.)

2.5.1 Pointer Gestures (A) (2.1)

• Do not require multipoint or path-based gestures (e.g. pinching, swiping, dragging) for functionality unless the gesture is essential to the functionality.

3.2.1 On Focus (A) (2.0)

• When the focus change, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user.

3.2.2 On Input (A) (2.0)

• When a user inputs information or interacts with a control, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user. If an input causes such a change, the user must be informed ahead of time.

• Design with people who are dyslexic in mind.

• Using large blocks of text can be difficult to scan.

• Design with people who are on the autism spectrum in mind.

• Removing unnecessary words, using bulleted lists, and avoiding bright colors can be less easier to take in.

• Design with people with anxiety or ADHD in mind.

• Provide closed captioning or transcripts for audio clips or video so audio is required to understand the content. Closed captioning for both audio and video content is required for users who are deafblind.

• Design with people with dyslexia or limited attention in mind.

• Use a consistent layout with left aligned text, or right aligned text for languages that use right-to-left scripts.

1.4.12 Text Spacing (AA) (2.1)

• Avoid using pixels for defining the height and spacing (e.g. height, line height, etc) of text boxes.

2.4.1 Bypass Blocks (A) (2.0)

• Provide a link to skip to the main content as the first focusable link on the page.

• Design with people with dyslexia in mind.

• Underlines, italics, or uppercase can be hard to read.

• Design with people with autism, limited attention, or those who may face negative stereotypes in mind.

• Avoid figures of speech, idioms, hidden messages, or acronyms.

• Design with people with anxiety in mind.

• Include next steps and timeframes to explain what happens after a task.

• Design with people with anxiety or limited attention in mind.

• Avoid leaving users questioning what answers they gave.

3.3.4 Error Prevention (Legal, Financial, Data) (AA) (2.0)

• • Provide easy ways to confirm, correct, or reverse a user action where a mistake would cause a serious real-world consequence (e.g. submitting financial data, entering into a legal agreement, submitting test data, or making a transaction).

• Design with people with autism, limited attention, or those who may face negative stereotypes in mind.

• Users might feel uncertain about the consequences of their actions if labels aren’t clear.

3.2.4 Consistent Identification (AA) (2.0)

• When components have the same functionality across several web pages, the components are labeled consistently on each page.

• Design with people with anxiety, dyslexia, motor disabilities, or limited attention in mind.

• Give users enough time to complete an action. Avoid time limits, and be clear about how long a task will take to give people a better opportunity to complete the action. If sessions time-out, warn users before time expires with the option to extend time.

2.2.1 Timing Adjustable (A) (2.0)

• Do not require time limits to complete tasks unless absolutely necessary. If a time limit is necessary, the time limit should be at least 20 hours, or it can be extended, adjusted, or disabled.

• Design with people with physical disabilities or anxiety in mind.

• Let users ask for their preferred communication to complete a task. Make alternative support easy to access.

2.2.2 Pause, Stop, Hide (A) (2.0)

• Items on the page should not automatically move, blink, scroll, or update, including carousels. If content does automatically move, blink, scroll, or update, provide a way to pause, stop, or hide the moving, blinking, scrolling, or updating.

2.4.5 Multiple Ways (AA) (2.0)

• Each website should include at least two of the following: a list of related pages; table of contents; site map; search; or list of all pages.

2.4.7 Focus Visible (AA) (2.0)

• Provide keyboard focus styles that are highly visible, and make sure that a visible element has focus at all times when using a keyboard. Do not rely on browser default focus styles.

4.1.2 Name, Role, Value (A) (2.0)

• Avoid creating custom widgets when HTML elements already exist. For example, use a and button tags appropriately.

• When creating a custom interactive widget, consult the ARIA Authoring Practices Document. Use ARIA labels, descriptions, roles, states, and properties to expose information about the component.

• Use ARIA to enhance accessibility only when HTML is not sufficient. Use caution when providing ARIA roles, states, and properties.

• Designing with people with limited attention or dyslexia in mind.

• Like the usability heuristic, “Flexibility and Efficiency of Use,” accelerators like autocomplete can help people overcome barriers and save time.

• Prevent errors by prompting review and sending reminders to complete tasks.

• Design with people who may experience negative stereotypes in mind.

• Default content to be gender and ethnically neutral. Use “they” pronouns and multicultural names. Avoid heteronormative language and language that over-indexes on the status quo like “culture fit.”

• Incorporate imagery that centers people from a diverse set of backgrounds. Additionally, make sure roles are represented by counter-stereotypical identities based on their regions or job markets.

• Design with people who may experience negative stereotypes or anxiety in mind.

• Give users an option to undo their mistakes by submitting a new response.

• Give users options to recover instead of dead ends.

• Allow systems to accept responses past posted deadline in case the deadline is overlooked or missed.

• Design with people who may experience negative stereotypes in mind.

• Users might want this option for questions on topics connected to historical oppression or judgment. They may fear a negative impact for answering. Or they may not want to reveal—or think about—certain information about themselves.

• A user might wonder, “why do I need to know this information?” If there’s no good explanation, it may be a sign to remove the question.

• Avoid implementing access keys. When access keys and other keyboard shortcuts are implemented, they must not interfere with existing browser and screen reader provided shortcuts.

• All functionality should be available to a keyboard without requiring specific timing of keystrokes, unless the functionality cannot be provided by a keyboard alone.

• Avoid relying exclusively on pointer-driven events, such as onmouseover, to provide functionality when scripting. Generally, such functionality will also require scripting for keyboard operability.

• In general, avoid using scripts to remove focus from an element until the user moves focus manually.

2.1.4 Character Key Shortcuts (A) (2.1)

• If a keyboard shortcut uses only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then the user must be able to disable the shortcut, remap the shortcut, or limit the shortcut to only when a particular interactive element has focus.

• Check if users are able to complete workflows on older devices.

• Design experiences that can be resized to smaller laptops or tablets.

1.3.4 Orientation (AA) (2.1)

• • All content and functionality should be available regardless of whether a mobile device is oriented vertically or horizontally, unless the orientation of the device is absolutely essential.

• Use alternatives to content that might require a lot of data or a high internet speed.

• It is vital to test AI outputs with diverse user groups.

• Ensure conversational interfaces are accessible to users with speech impairments, cognitive disabilities, and hearing impairments.

• Ensure automatically generated content meets WCAG guidelines (e.g., proper heading structure, alternative text for images).

• As AI becomes more autonomous, it is very important that the AI provides clear explanations of its actions. 

Bias and Inclusivity

• Inclusivity requires careful consideration of diverse user needs during AI development and deployment.

• AI models can perpetuate and amplify existing biases, leading to discriminatory outcomes.

Transparency and Control

• Users should understand how AI and automation are being used.

• Provide users with control over automated processes, where possible.

• This is especially important for people with cognitive disabilities.

Conversational AI

• Provide alternative input methods (e.g., text input).

• Design for clear and concise language.

Automated Content Generation

• Provide mechanisms for users to correct or modify AI-generated content.

Agentic AI

• There must be ways for users to understand and interrupt the AI processes.