Design
Provide proper text and multi-media content.
Level 1 - core
Blind users rely heavily on clear, properly structured headings to understand and navigate content (via a screen reader). The heading structure provides an outline so blind users can quickly understand the organization and contents of the page.
What to do
- Accurately describe content with succinct headings
- Indicate heading levels; avoid skipping a level
- Use only one H1 per page
Annotate headings in wireframes, and use only one H1 per page, which is typically the page title.
Don't use unclear headings, use headings out of order, or have multiple H1s on one page.
Resources
- Headings, W3C web accessibility tutorials
Requirements
- 2.4.6 Headings and Labels, IBM accessibility requirements
- 1.3.1 Info and Relationships, IBM accessibility requirements
Providing proper alternative text for implementation allows blind users to perceive any meaningful visuals on a page (via a screen reader).
What to do
- Identify and annotate decorative images
- Provide alternative text for meaningful images, including logos and icons
- Ensure the alternative text describes the purpose, not the image
- Provide both a short and a more detailed description for complex visuals
Annotate an image as decorative (or alt=“”) if it provides no meaningful info, only for visual formatting, or has a caption providing context. Copyright IBM; all rights reserved.
Provide specific and concise alt text that describes the meaning of the image. Copyright IBM; all rights reserved.
Describe the purpose instead of the images used to represent controls (such as these icons).
For screenshots, the alternative text should list relevant text on the screen as well as provide critical visual information. Here, a caption adds some context. More details could be provided in the nearby text, including a link to the page.
For this complex visual, a caption provides the key takeaway, a title provides context, and the alt text provides a summary. Depending on context, more detailed information on the chart could be provided in a spreadsheet.
Resources
- G73: Providing a long description in another location with a link to it that is immediately adjacent to the non-text content, WCAG 2 technique
- G94: Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content, WCAG 2 technique
- G100: Providing a short text alternative which is the accepted name or a descriptive name of the non-text content, WCAG 2 technique
- G196: Using a text alternative on one item within a group of images that describes all items in the group, WCAG 2 technique
- An alt decision tree, W3C web accessibility tutorials
- Decorative images, W3C web accessibility tutorials
- Functional images, W3C web accessibility tutorials
- Complex images, W3C web accessibility tutorials
- Images of text alternative, Princeton University digital accessibility
- Icon usability, Nielsen Norman Group
- Alternative text, decorative images, WebAIM®
Requirements
- 1.1.1 Non-text content, IBM accessibility requirements
- 1.4.5 Images of Text, IBM accessibility requirements
Related toolkit topics
- Give decorative images an ALT attribute with an empty string (alt=""), Develop – Non-text content
- Images of text, this page
- Implement text alternatives for meaningful images, sound, and visual data, Develop – Non-text content
- Use HTML, ARIA, or technology-specific techniques to add short text alternatives, Develop – Non-text content
Properly written and positioned input labels helps users with cognitive disabilities or have low vision. When low vision users zoom to navigate a page, labels positioned far from its input may get lost in the process.
What to do
- Provide clear and concise labels for every input element
- Consistently locate labels near inputs
- Persistently display labels
- Annotate labels for inputs without visible labels
Provide clear and concise labels so users know what kind of input is needed.
Don't use unclear labels or rely on placeholder text without labels.
For radio buttons and checkboxes, place the text label immediately to the right of the icon.
Don’t place labels in inconsistent locations, which will confuse the association with the user input.
Annotate any labels that apply to more than one input field, and annotate hidden aria labels where each input lacks a unique label.
Resources
- G131: Providing descriptive labels, WCAG 2 technique
- G162: Positioning labels to maximize predictability of relationships, WCAG 2 technique
- Placeholder text, W3C web accessibility tutorials
- Text input accessibility, Carbon design system
- Form accessibility, Carbon design system
- Yes, icons need text labels, Nielsen Norman Group
- Text input guidelines, Balsamiq wireframing academy
Requirements
- 1.3.1 Info and Relationships, IBM accessibility requirements
- 2.4.6 Headings and Labels, IBM accessibility requirements
- 3.3.2 Labels or Instructions, IBM accessibility requirements
Vague errors are especially problematic for users with cognitive disabilities who may struggle to find, understand, and fix them.
What to do
- Identify and describe errors
- Suggest corrections, with enough context for blind users
Provide helpful feedback so users understand that either the username or password was entered incorrectly.
Don’t provide little or no guidance where users understand that they are unable to sign in but don't know why there is an error.
Provide suggestions so users know the proper format they need.
Don't provide ambiguous information in an error message that doesn't tell users how to fix it.
Resources
- G83: Providing text descriptions to identify required fields that were not completed, WCAG 2 technique
- Listing errors, User notifications, W3C web accessibility tutorials
- Give direction to the user, How to write good error messages, UX Design World
Requirements
- 3.3.1 Error Identification, IBM accessibility requirements
- 3.3.3 Error Suggestion, IBM accessibility requirements
There are two types of flashing content: general and red. General flashes refer to changes between contrasting brightness. Red flashes refer to changes that involve saturated red, which can be dangerous in triggering seizures.
What to do
- Avoid flashing content
- Any flashing content should flash slower than three times per second
- If flashing more than three times per second, reduce the size of flashing content
Decide if flashing content is really necessary, or if a static image is enough.
In this example, the background changes between highly contrasting colors less than three times. Copyright IBM; all rights reserved.
If flashing faster than three times per second, make sure the flashing content is smaller than 341 x 256 pixels, less than 10% of the central visual field, or less than 25% of screen area. Copyright IBM; all rights reserved.
Resources
- G176: Keeping the flashing area small enough, WCAG 2 technique
- Web accessibility for seizures and physical reactions, Mozilla Developer Network
Requirements
- 2.3.1 Three Flashes or Below Threshold, IBM accessibility requirements
Captions are critical to deaf and hard of hearing users, but are also valuable to hearing and second-language listeners. Ask your lead whether captioning will be automated, outsourced, or done in-house. Ensure your team is aware of the requirements for the media players to support captions.
What to do
- Provide captions for spoken content in videos
For videos with audio content, captions should identify the speaker, include all spoken audio content and relevant non-spoken sounds. Here, captions include the spoken audio content. More details could be provided in the nearby text, including a link to the video transcript. Copyright IBM; all rights reserved.
Resources
- Captions and subtitles, W3C
- AI powered captions, IBM Watson captioning tool
- Audio alternatives, Carbon design system
- Making videos accessible through captions, IBM internal use only
Requirements
- 1.2.2 Captions (Prerecorded), IBM accessibility requirements
- 1.2.4 Captions (Live), IBM accessibility requirements
Related toolkit topics
- Text content for videos, this page
- Media players, UX design
- Implement text alternatives for meaningful images, sound, and visual data, Develop – Non-text content
Headings
Alternative text for visuals
Input labels
Error messages
Flashing content
Video captions
Level 2 - continued
Page titles should succinctly identify the topic and uniquely identify the page so that it provides context on a site map or search results. Page titles also often include information on the set of pages to which they belong. For example, a site selling apparel might have the page title “ No-name Brand Khakis – Shorts – Mens.” The unique string should be at the start of the title so that users see or hear the critical information first.
What to do
- In a set of pages, give each a unique title
- List the unique text string first in a concatenated title
Resources
- G88: Providing descriptive titles for Web pages, WCAG 2 technique
Requirements
- 2.4.2 Page Titled, IBM accessibility requirements
Users who are blind or have low vision use assistive technology to transform text into speech or into colors with higher contrast. Using images of text prevents these transformations from happening. Exceptions include when the text is integral to the image, such as a logo or a screenshot of an application.
What to do
- Don’t use images of text when text can be used
Resources
- C22: Using CSS to control visual presentation of text, WCAG 2 technique
- Images of text, W3C web accessibility tutorials
Requirements
- 1.4.5 Images of Text, IBM accessibility requirements
Moving content can distract users with cognitive disabilities from focusing on other parts of the page. Moving content includes videos, animations, carousels, or areas of content that blink, auto-update, or scroll. Autoplaying content can also interfere with screen readers by constantly resetting the focus or causing audio chatter.
What to do
- Avoid starting animations or videos automatically
- If autoplaying content is needed, ensure it lasts less than five seconds
- Provide a mechanism to pause, stop, or hide autoplaying content
Resources
- G4: Allowing the content to be paused and restarted from where it was paused, WCAG 2 technique
- G11: Creating content that blinks for less than 5 seconds, WCAG 2 technique
- G152: Setting animated gif images to stop blinking after n cycles (within 5 seconds), WCAG 2 technique
- G186: Using a control in the Web page that stops moving, blinking, or auto-updating content, WCAG 2 technique
- G187: Using a technology to include blinking content that can be turned off via the user agent, WCAG 2 technique
- G191: Providing a link, button, or other mechanism that reloads the page without any blinking content, WCAG 2 technique
- Animation and effects, Smashing magazine
- Designing with Reduced Motion for Motion Sensitivities, Smashing magazine
Requirements
- 1.4.2 Audio Control, IBM accessibility requirements
- 2.2.2 Pause, Stop, Hide, IBM accessibility requirements
Related toolkit topics
- Media players, UX design
For users with a hearing or visual disability, knowing whether the video contains accessibility considerations, such as closed captions or a video description is really helpful. This keeps them from wasting time trying to access content that they can’t fully consume.
What to do
- Give videos a title or brief description positioned near the video
- Inform users if the video contains captions, such as including “(CC)” in video titles
- Ensure captions are accurate, consumable, and complete
This example shows a brief description following each video shown.
Resources
- G68: Providing a short text alternative that describes the purpose of live audio-only and live video-only content, WCAG 2 technique
- G100: Providing a short text alternative which is the accepted name or a descriptive name of the non-text content, WCAG 2 technique
- Captions and subtitles, W3C
- 508 accessible videos - how to caption videos, digital.gov
- AI powered captions, IBM Watson captioning tool
- Audio alternatives, Carbon design system
- How to write the best YouTube descriptions: Tips and examples, Hootsuite blog
- Subtitle guidelines, BBC
Requirements
- 1.1.1 Non-text content, IBM accessibility requirements
- 1.2.2 Captions (Prerecorded), IBM accessibility requirements
- 1.2.4 Captions (Live), IBM accessibility requirements
Related toolkit topics
- Video captions, this page
- Video transcripts, this page
- Visual content in videos
- Embed multimedia content that supports closed captions, Develop – Non-text content
Screen readers generate a list of all the links on a page for blind users to efficiently navigate to desired content. In this context, multiple “read more” links on a page will only confuse users. Meaningful stand-alone link text is also helpful for users with cognitive disabilities.
What to do
- Provide clear, concise, and unique link text
- Contextualize generic links such as “read more”
- If using generic links, annotate the connection with text that provides context
Provide clear and concise link text that can be understood out of context, as in this screen reader dialog box listing links.
Annotate the connection between generic links and text that gives context for implementation.
Don’t use generic or ambiguous links when it is possible to provide the user with more context.
Resources
- G53: Identifying the purpose of a link using link text combined with the text of the enclosing sentence, WCAG 2 technique
- G91: Providing link text that describes the purpose of a link, WCAG 2 technique
- Screen reader users sometimes obtain an alphabetically-organized list of links, WebAIM
- Screen reader users often navigate from link to link, skipping the text in between, WebAIM
- “Learn more” links: you can do better, Nielsen Norman Group
Requirements
- 2.4.4 Link Purpose (In Context), IBM accessibility requirements
Screen reader users navigating form inputs will only hear instructions (and labels) directly associated with the inputs. Users with cognitive disabilities need relevant guidance located near the input field to reduce the amount of short-term memory required to recall and act on the instructions. If instructions are located far from the input, users with low vision will also miss it when they zoom in to navigate the page.
What to do
- Include instructions near the input when a particular data format is expected
- Make sure instructions are associated with the input for implementation
Provide instructions near the input when a specific format is required.
Resources
- G89: Providing expected data format and example, WCAG 2 technique
- G184: Providing text instructions at the beginning of a form or set of fields that describes the necessary input, WCAG 2 technique
- Form instructions, W3C web accessibility tutorials
- Password creation: 3 ways to make it easier, Nielsen Norman Group
- Form field usability: Consider using localized input masks for ‘Phone’ and other restricted inputs (64% don’t), Baymard Institute
Requirements
- 3.3.2 Labels or Instructions, IBM accessibility requirements
Related toolkit topics
- Placeholder text, this page
Placeholder text should not be the only place where relevant guidance to the input exists. Placeholder text disappears once the user starts typing, rendering any pertaining guidance useless, which is problematic for users with cognitive disabilities and can’t remember the placeholder text. It’s also problematic for users with screen readers that skip over placeholder text.
What to do
- Ensure labels and instructions persist when placeholder text is no longer visible
Keep labels and important instructions visible so user guidance is consistent.
Don't use placeholders in place of labels or critical instructions.
Resources
- Headings, W3C web accessibility tutorials
Requirements
- 1.4.3 Contrast (Minimum), IBM accessibility requirements
- 3.3.2 Labels or Instructions, IBM accessibility requirements
Related toolkit topics
- Input labels, this page
- Input components, UX design
- Associate labels with inputs, Develop – User guidance
Page Titles
Images of text
Autoplaying content
Text content for videos
Link text
Data format for inputs
Placeholder text
Level 3 - complete
When meaningful information is shown through visual content, a text or audio equivalent must be available to users who are blind. Visual content can be conveyed as a part of the video through commentary that describes the important images and animations so listeners can understand.
What to do
- Describe meaningful visual content in videos
- Consider adding a description of meaningful visuals to audio track or transcript
Resources
- G8: Providing a movie with extended audio descriptions, WCAG 2 technique
- G58: Placing a link to the alternative for time-based media immediately next to the non-text content, WCAG 2 technique
- G69: Providing an alternative for time based media, WCAG 2 technique
- G78: Providing a second, user-selectable, audio track that includes audio descriptions, WCAG 2 technique
- G159: Providing an alternative for time-based media for video-only content, WCAG 2 technique
- G166: Providing audio that describes the important video content and describing it as such, WCAG 2 technique
- G173: Providing a version of a movie with audio descriptions, WCAG 2 technique
- Transcripts, W3C
- Understanding 1.2.8 Media Alternative (Prerecorded), WCAG 2 (level AAA)
Requirements
- 1.2.1 Audio-only and Video-only (Prerecorded), IBM accessibility requirements
- 1.2.3 Audio Description or Media Alternative (Prerecorded), IBM accessibility requirements
- 1.2.5 Audio Description (Prerecorded) (Level AA), IBM accessibility requirements
Full text transcripts are vital to users who are deaf-blind. They are also useful for users with visual or cognitive disabilities. A text transcript is similar to a screenplay, where names of speakers, dialog, and important audio cues are described. This is only required for audio-only content, but is highly recommended for videos.
What to do
- Consider providing a transcript of all spoken content
Resources
- G69: Providing an alternative for time based media, WCAG 2 technique
- Transcripts, W3C
- Understanding 1.2.8 Media Alternative (Prerecorded), WCAG 2 (level AAA)
- Audio description flowcharts, Vision Australia
Requirements
- 1.2.1 Audio-only and Video-only (Prerecorded), IBM accessibility requirements
Table captions are basically headings for tables, while figure captions normally appear beneath the relevant images. Captions are especially helpful for users with assistive technology.
What to do
- Annotate any figure and table captions for implementation
- Use figure captions to enhance alternative text
Resources
- Naming tables and figures with captions, ARIA authoring practices
Requirements
- 1.1.1 Non-text content, IBM accessibility requirements
- 1.3.1 Info and Relationships, IBM accessibility requirements
Annotating your wireframes for foreign languages will inform implementation to code the language of each phrase so that assistive technology can translate it properly.
What to do
- Annotate occurrences of foreign language
- Exclude proper names, technical terms, and words of indeterminate language
- Exclude words or phrases that have become part of the vernacular of the page
Requirements
- 3.1.2 Language of Parts, IBM accessibility requirements
Where similar content appears across multiple pages, provide consistency of experience so users can more easily locate and understand content.
What to do
Provide help mechanisms in the same location on all pages where they appear (WCAG 2.2 only)
Provide navigation mechanisms in the same order on all pages
Across related content, use the same labels and icons to represent the same functions
Resources
- G61: Presenting repeated components in the same relative order each time they appear, WCAG 2 technique
- G197: Using labels, names, and text alternatives consistently for content that has the same functionality, WCAG 2 technique
- G220: Provide a contact-us link in a consistent location, WCAG 2.2 technique
Requirements
- 3.2.3 Consistent Navigation, IBM accessibility requirements
- 3.2.4 Consistent Identification, IBM accessibility requirements
- 3.2.6 Consistent Help, IBM accessibility requirements (7.3 only)