Content design - Text meaning
Content writers can help give users more context. Note any text on the page which has special meaning or purpose. Things to flag include headings, titles, links, table headers, foreign words, and abbreviations. Properly flagging such text to developers allows them to build it accessibly.
Level 1
Write descriptive, organized headings
What to do
Blind users rely heavily on clear, properly structured headings to understand and navigate content (via a screen reader). Keep headings clear and brief. Avoid beginning different headings with the same words or phrases, since users have to read (or listen to) more information to differentiate between topics.
Give a section of text a clear and succinct heading to quickly inform users what they are about to read.
Don't use wordy and unclear headings. Headings should be short and informative and clearly placed in relationship to the part of design it refers to.
Resources
- Headings, W3C web accessibility tutorials
Requirements
- 2.4.6 Headings and Labels, IBM accessibility requirements
What to do
The heading structure provides an outline so blind users can quickly understand the organization and contents of the page. Content writers should indicate the hierarchy of the headings in the wireframes. This ensures they are properly implemented by developers. In most situations, the main topic or section of the page should be a level one heading (H1, in HTML). A logical heading structure normally increments by only one level as it descends. For example, an H4 should follow an H3, not an H2. Skipping a level can cause users to wonder if the H2 content is hidden or intentionally not included on the page.
Indicate appropriate heading levels to display your information in an organized hierarchy.
Don't use headings out of order, and avoid skipping a level.
Resources
- Headings, W3C web accessibility tutorials
Requirements
- 1.3.1 Info and Relationships, IBM accessibility requirements
What to do
Strive to have a single top-level heading (
H1
, in HTML) per page, as users typically think of anH1
heading as the main topic. The text of theH1
heading frequently matches the page title. Sometimes the heading may be a shortened form of the title. Note: There are rare circumstances where more than oneH1
heading may exist on a page, such as when a web portal embeds many articles within a single page of content.Use a single top level H1 heading to quickly inform readers where the main topic begins; the next heading will normally be an H2.
Avoid using multiple H1 headings on one page. This can confuse users navigating by heading level.
Resources
- Headings, W3C web accessibility tutorials
Requirements
- 1.3.1 Info and Relationships, IBM accessibility requirements
Accurately describe content with succinct headings
Indicate heading levels; avoid skipping a level
Use only one H1 per page, which typically matches the page title
Level 2
Uniquely title page
What to do
On HTML pages, the text within the
title
element appears as the window title on most browsers. Since the title is not part of the designed UI, it should be specifically called out in the wireframes so it is properly coded by developers. The title should succinctly identify the topic and uniquely identify the page, so that it provides context on a site map or search results.Resources
- G88: Providing descriptive titles for Web pages, WCAG 2.1 technique
Requirements
- 2.4.2 Page Titled, IBM accessibility requirements
What to do
Page titles will often include information on the set of pages to which they belong. A site selling clothing may have pages where each title consists of the item, the kind of clothing it is, and the target audience. For example “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.
Requirements
- 2.4.2 Page Titled, IBM accessibility requirements
In a set of pages, give each a unique title
List the unique text string first in a concatenated title
Confirm link text make sense
What to do
Screen readers can generate an alphabetical list of links on a page, which lets blind users quickly navigate to linked content. If the link text isn’t descriptive or if there are several links with the same text, such as “Read more,” the links can’t be understood out of context. Good link text can help prevent time lost from navigating to irrelevant content. Meaningful, stand-alone link text is also useful to someone with a cognitive disability.
Good link text
- is clear and as brief as possible
- is unique for each link on a page that navigates to a different place
- avoids including the word “link” in the link text, which is redundant
Provide clear and concise link text that can be understood out of context, as in this screen reader dialog box listing links.
Resources
- “Learn more” links: you can do better, Nielsen Norman Group
- Screen reader users sometimes obtain an alphabetically-organized list of links, WebAIM
- G91: Providing link text that describes the purpose of a link, WCAG 2.1 technique
Requirements
- 2.4.4 Link Purpose (In Context), IBM accessibility requirements
Related toolkit topics
- Contextualize generic links such as “Read more”, this section
What to do
Sometimes a design includes generic links, such as “Read more,” “Help,” or “Click here”. It’s a technique used to conserve space or provide a consistent and predictable visual presentation of links in the content. The accessibility issue with such links is that someone who cannot see the context of its use may not know where the link will take them. Screen reader users sometimes use a short-cut function that navigates from link to link, skipping the surrounding text that provides the link context. The user must use additional screen reader functions to read the text before and after the link to find out what they might “Read more” about or get “Help” for. It may take a few tries to find the right link, leading to a frustrating experience.
First, consider whether the design could change to give the links a unique name. If not, be sure to annotate the connection between the link and the text that gives the additional context. Development can implement this association so that a screen reader announces the additional information along with the generic link text. The association gives clarity for a user who cannot see the surrounding text that provides an obvious context for sighted users.
Annotate the connection between the link and the text that gives the additional context.
Don’t use generic or ambiguous links when it is possible to provide the user with more context.
Resources
- Screen reader users often navigate from link to link, skipping the text in between, WebAIM
- G53: Identifying the purpose of a link using link text combined with the text of the enclosing sentence, WCAG 2.1 technique
Requirements
- 2.4.4 Link Purpose (In Context), IBM accessibility requirements
Related toolkit topics
- Compose stand-alone link text where possible, this section
Compose stand-alone link text where possible
Contextualize generic links such as “Read more”
Flag table headers
What to do
The first cells in rows and columns often form the equivalent of a label for the table’s contents. Blind users or those who cannot see the whole table at the same time benefit greatly from this information, but only if it is coded properly. Where row or column headers exist, content designers should mark them in the wireframes so that developers can properly implement them. Only mark headers where the cell actually provides a header role; especially for rows, the first cell may not perform any function.
Annotate any row or column headers in your wireframes.
Resources
- Table concepts, W3C web accessibility tutorials
- Tables with one header, W3C web accessibility tutorials
- Tables with two headers, W3C web accessibility tutorials
Requirements
- 1.3.1 Info and Relationships, IBM accessibility requirements
What to do
When you need to design complex data tables that have more than one level of row or column heading, or column and row headings that span multiple columns or multiple rows, make an explicit note of the levels or spans in the design. In many cases it is worth restructuring the information or splitting complex tables into smaller more simple tables.
Resources
- Table concepts, W3C web accessibility tutorials
- Tables with irregular headers, W3C web accessibility tutorials
- Tables with multi-level headers, W3C web accessibility tutorials
- H43: Using id and headers attributes to associate data cells with header cells in data tables, WCAG 2.1 technique
Requirements
- 1.3.1 Info and Relationships, IBM accessibility requirements
Notate cells that serve as row or column headers
Properly notate nested table headers in complex tables
Level 3
Flag foreign words and abbreviations
What to do
In the wireframes, note each occurrence of phrases or passages that are in a different human language than the rest of the page. Your notation will inform the developer to code the language of each phrase in the content so that assistive technologies (AT) will present or speak it correctly.
Do Not topics
Do not flag proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the page or topic.
Requirements
- 3.1.2 Language of Parts, IBM accessibility requirements
What to do
As is common with most editorial standards, you should spell out the first use of a term, with the abbreviation or acronym appearing in parentheses. However, there may be situations where spelling out the phrase is not practical, such as when table headers are heavily abbreviated to fit a small cell space. In such cases, flag the abbreviation to developers, along with the spelled out text, so that they can programmatically incorporate it. There is a simple HTML technique that allows users and assistive technologies to expand abbreviations. Note that using this technique is not required at level AA of WCAG.
Resources
- G97: Providing the first use of an abbreviation immediately before or after the expanded form, WCAG 2.1 technique
- 3.1.4 Abbreviations, WCAG 2.1 (Level AAA)
Notate occurrences of foreign language
Spell out abbreviations with first use or flag for developer incorporation
Properly title figures and table
What to do
Table captions are basically headings for tables, while figure captions normally appear beneath the images they explain. Captions help all users better understand the figures and tables, but are especially helpful to users of assistive technology (AT). Note in your wireframes and designs where you use such captions so that developers can properly code them.
Resources
- Naming tables and figures with captions, ARIA authoring practices
- Understanding 1.1.1 Non-text Content, WCAG
Requirements
- 1.3.1 Info and Relationships, IBM accessibility requirements
What to do
Figure captions, which typically appear beneath and describe an image, help all users better understand the image but can be especially helpful to users of assistive technology (AT). In most situations, figure captions can supplement the alternative text for an image. For instance, the caption may tell all users what an image is, why it is there, or an important thing about it. In such cases, the alternative text for the image can often be kept to just one or two words.
Resources
- Naming tables and figures with captions, ARIA authoring practices
Requirements
- 1.1.1 Non-text content, IBM accessibility requirements
Flag figure and table captions, where used
Use figure captions to enhance alternative text
Flag reading order considerations
What to do
Refer to the resources and requirements below.
Resources
- G57: Ordering the content in a meaningful sequence, WCAG 2.1 technique
Requirements
- 1.3.2 Meaningful Sequence, IBM accessibility requirements