Content related WCAG 2.1 A and AA Success Criteria

Welcome to UserWay University!

The fastest way to learn the underlying technical requirements of WCAG 2.1

Content related WCAG 2.1 A and AA Success Criteria

Here are the details of the success criteria that are related to content.

Perceivable

1.1 Text Alternatives

1.1.1 Non-text content (A)

All non-text content like images, charts, icons and infographics, must have an appropriate text equivalent. This ensures that information conveyed by non-text content is available to people who cannot see it, like screen reader users.

Requirements / What to do?
  • Images (like logos and icons) that communicate information have short text descriptions;
  • Editorial images that support the text around them have short descriptions;
  • Images (like infographics, charts and diagrams) that communicate complex information also have longer text descriptions within the same page;
  • Decorative images have empty text descriptions.
Common mistakes
  • The image communicates information but does not have a text description;
  • The text description does not communicate the same information as the image;
  • The image has a text description but, like a placeholder or file name, it does not communicate the information in the image;
  • The image has a text description that is an exact duplication of content elsewhere on the page.
Useful resources

1.2 Time-based Media

1.2.1 Audio-only and video-only (A)

All content that is audio-only like a podcast, or video-only like a silent movie, must have a text description or an audio description. This ensures that information communicated for sight and sound is available to people who cannot see or hear.

Requirements / What to do?
  • Audio only content that communicates information (like a podcast) has a text transcript;
  • Video-only content that communicates information (like a silent movie) has a text transcript that describes the video or a audio description.
Common mistakes
  • Audio-only content that communicates information does not have a text transcript;
  • Video-only content that communicates information does not have a text transcript or an audio description;
  • The text transcript for audio-only content does not include all spoken dialogue and sound effects;
  • The text transcript for video-only content does not include descriptions of all important visual information;
  • The text transcript for audio-only or video-only content is not clearly labelled as such.
  • The audio description for video-only content does not include descriptions of all important visual information;
Useful resources

1.2.2 Captions (prerecorded) (A)

Video content like instructional videos, promotions and interviews, must have captions that are synchronised with the audio content of the video. This ensures that the information communicated by the audio part of the video is available to people who cannot hear it.

Requirements / What to do?
  • All video content has captions that are synchronised with the audio content of the video;
  • Captions include all the spoken dialogue and important sound effects from the audio part of the video.
Common mistakes
  • The video does not have synchronised captions;
  • The video has captions but they do not include all the spoken dialogue and important sound effects from the audio content of the video;
  • The video has captions but they are not synchronised with the audio content of the video.
Useful resources

1.2.3 Audio description or media alternative (A)

Video content like instructional videos must have audio description, unless it already has a text alternative. This ensures that information communicated visually in the video is available to people who cannot see it.

Requirements / What to do?
  • Video content is audio described, or has a text alternative that describes the visual content of the video.
Common mistakes
  • The video does not have audio description or a text alternative;
  • The audio description does not describe important information communicated visually in the video;
  • The text alternative does not describe important information communicated visually in the video;
  • The audio description is not synchronised to complement the audio content of the video.
Useful resources

1.2.4 Captions (live) (AA)

Live broadcast video must have captions that are synchronised with the audio content of the video. This ensures that the information communicated by the audio part of the video is available to people who cannot hear it.

Requirements / What to do?
  • All live video content has captions that are synchronised with the audio content of the video.
Common mistakes
  • The live video does not have synchronised captions;
  • The live video has captions but they are not synchronised with the audio content of the video.
Useful resources

1.2.5 Audio description (pre-recorded) (AA)

Video content like instructional videos must have audio description. This ensures that information communicated visually in the video is available to people who cannot see it.

Requirements / What to do?
  • Video that includes important visual information has audio description;
Common mistakes
  • A video includes important visual information but does not have audio description;
  • The audio description does not describe important information communicated visually in the video;
  • The audio description is not synchronised to complement the audio content of the video.
Useful resources

1.3 Adaptable

1.3.1 Info and relationships (A)

When content structures like tables, lists and headings are communicated visually, they must also be communicated in ways that assistive technologies can understand. This ensures that content structures are available to screen reader, screen magnifier and speech recognition tool users.

Requirements / What to do?
  • Tabular data is presented using proper HTML markup (<table>, <tr>, <th>, and <td> elements);
  • Lists of items are presented using proper HTML markup (<ul>, <ol>, and <li> elements);
  • Headings are presented using proper HTML markup (<h1> through <h6> elements);
  • Form fields have properly associated <label> elements;
  • Sets of radio buttons or checkboxes have a <fieldset> element to group them together, and a <legend> element to provide a label for the group;
  • Form fields with format requirements or other additional information have properly associated hints.
Common mistakes
  • Tabular data is displayed using CSS to present the appearance of a table, but the proper HTML markup has not been used;
  • A list of items is presented using line breaks to separate each item, and the proper HTML markup has not been used;
  • Headings are text styled with CSS, and the proper HTML markup has not been used;
  • Headings use the proper HTML markup, but do not accurately represent the hierarchy of content on the page (starting with <h1>, then <h2> for each section, <h3> for each sub-section and so on);
  • Form fields do not have labels;
  • Form fields have labels but they are not properly associated with their corresponding fields;
  • Sets of radio buttons or checkboxes are not grouped inside a <fieldset> element, and do not have a <legend> element to provide a label for the group;
  • Form fields have format requirements or additional information, but it is not properly associated with the corresponding field.
Useful resources

1.3.3 Sensory characteristics (A)

Instructions must not depend on sensory characteristics like shape, size, colour, or location. This ensures that instructions can be understood by users who are unable to see or recognise information communicated using sensory characteristics.

Requirements / What to do?
  • Do not use shape, size, colour, or location to communicate instructions.
Common mistakes
  • An instruction tells users to “activate the green button”;
  • An instruction tells users to “use the menu on the left of the page”;
  • An instruction tells users they can “find more information in the square box”;
  • An instruction tells users to “follow the biggest link in the tag cloud”.

Operable

2.4 Navigable

2.4.2 Page title (A)

Each page must have a unique title that indicates its topic or purpose. This ensures that people with cognitive disabilities can quickly orientate themselves within the service and identify the purpose of the page without interpreting its entire contents.

Requirements / What to do?
  • Each page has a title that is unique within the service;
  • Each page has a title that indicates its topic or purpose.
Common mistakes
  • The page title is not unique within the service;
  • The page title does not indicate its topic or purpose;
  • The title does not indicate the page is part of a service on Gov.UK;
  • The page title does not change because the service is a Single Page Application (SPA).
Useful resources

The purpose of every link must be clear from its link text, or its link text plus associated content if assistive technologies recognise the association. This ensures that screen reader users can understand the purpose of links without reading nearby content, and that speech recognition users can target links accurately using voice commands.

Requirements / What to do?
  • Link text clearly indicates the purpose of the link;
  • Multiple links that point to the same destination have the same link text;
  • Links have accessible names.
Common mistakes
  • A link has text that does not indicate its purpose;
  • A link points to the same destination as another link, but uses different link text;
  • A link points to a unique destination, but uses the same text as other links;
  • A link has text that depends on nearby content to be understood, but that content is not automatically identified by assistive technologies;
  • A link uses a CSS background image, and has no visible accessible name.
Useful resources

2.4.6 Headings and labels (AA)

Headings must indicate the topic or purpose of the content in that section of the page, and labels must indicate the purpose of the field they relate to. This ensures people with reading difficulties can understand the purpose of content, and that screen reader users can easily navigate to relevant sections of content on the page.

Requirements / What to do?
  • Headings describe the purpose or topic of the content that follows;
  • Labels indicate the purpose of the fields they relate to.
Common mistakes
  • A heading does not indicate the purpose or topic of the content that follows;
  • A label does not indicate the purpose of the field it relates to.
Useful resources
  • TBC

2.5 Input Modalities

2.5.3 Label in Name (A)

For user interface components with labels that include text or images of text, the Accessible namecontains the text that is presented visually.

Why is this a problem?

The ‘name’ is text by which software can identify a component within Web content to the user. The ‘Accessible Name’ is text in the DOM that is understood by both the AT (like a screen reader) and the browser. This is often hidden in code.

These need to match so that:

  • Speech input users can activate controls on a page.
  • Text-to-speech users will have a better experience because the labels that they hear match the visible text labels that they see on the screen.
Requirements / What to do?

The accessible name can be the ‘label’ used on a form input. This can be provided by the label element in HTML or by an aria-label or similar. There are other ARIA and HTML elements that can provide the accessible name for a component.

Ensure that the:

  • Accessible name matches the visible label: The accessible name and visible label of a control match.
  • Accessible name starts with visible label: The accessible name of a “Start here” button begins with the same text as the visible label.
Common mistakes
  • The Accessible name does not contain the visible label text
  • The Accessible name contains the visible label text, but the words of the visible label are not in the same order.
  • The Accessible name contains the visible label text, but there are extra words in the label.
Resources

Understandable

3.1 Readable

3.1.1 Language of page (A)

The written language of the page must be identified in the code of the web page. This makes sure that screen readers automatically use the correct speech libraries for accent and pronunciation.

Requirements / What to do?
  • The language is identified using the lang attribute of the <span class="nt"><html</span> element.
Common mistakes
  • No lang attribute is present on the <span class="nt"><html></span> element.
  • The lang attribute is present on the <span class="nt"><html></span> element, but it incorrectly identifies the language of the page.
Useful resources

3.1.2 Language of parts (AA)

When content is displayed in a language that is different from the primary language of the page, it must be indicated in a way that assistive technologies understand. This ensures that screen readers switch to the appropriate accent and pronunciation for that language.

Requirements / What to do?
  • Content that is written in a different language from the primary language of the page, is identified using HTML (the lang attribute).
Common mistakes
  • Content uses a different language, but the change in language is not identified in the HTML;
  • Content uses a different language, and the wrong language is identified in the HTML.
Useful resources

3.2 Predictable

3.2.4 Consistent identification (AA)

When features with the same functionality are used in multiple places, they must be identified in a consistent way. This helps screen reader users correctly identify the type and purpose of the functionality.

Requirements / What to do?
  • An icon has the same alternative text wherever it is used;
  • Buttons for “Next”, “Previous”, and “Continue”, are labelled consistently wherever they are used;
  • Form fields with the same purpose are consistently labelled wherever they are used.
Common mistakes
  • An icon is used to denote a file download, but has a different alternate text whenever it is used;
  • A search facility is provided on every page, but the text field and button have different labels on each page.
Useful resources
  • TBC.

3.3 Input Assistance

3.3.1 Error identification (A)

When an error occurs the user is informed what caused the error, and the error is described in text. This ensures that the error is available to people who cannot see, distinguish colours, or understand icons and other visual cues.

Requirements / What to do?
  • Each error is described in text;
  • Each error is associated with the field it relates to;
  • Multiple errors are summarised at the top of the form.
Common mistakes
  • An error is only indicated by a red border around the field;
  • An error is only indicated by an icon near to the field;
  • An error is described in text, but it is not associated with the field it relates to;
  • Multiple errors occur, but no summary is provided.
  • An error summary is provided, but keyboard focus is not taken to it.
Useful resources
  • TBC

3.3.2 Labels or instructions (A)

When data must be entered in a specific format or in a particular way, clear instructions must be associated with the form field. This ensures that everyone understands any requirements for entering data, and does so in a way that ensures that people unable to see the information are made aware of it by their screen readers.

Requirements / What to do?
  • Instructions are provided for fields that require data to be entered in a specific format;
  • Instructions are properly associated with the relevant form field.
Common mistakes
  • Data is expected in a specific format, but no instructions have been provided;
  • Instructions have been provided, but they are not associated with the relevant field.
Useful resources

3.3.3 Error suggestion (AA)

When an error is detected, suggestions for correcting the issue must be provided unless the suggestion compromises security. This helps everyone resolve issues more easily, but especially people with cognitive disabilities who find processing information difficult.

Requirements / What to do?
  • When an error is detected, a suggestion is provided to help the user correct the issue.
Common mistakes
  • An error is detected and the user is notified, but no suggestion is given to help them resolve it; A login error is detected and a suggestion is provided, but it comprimises security by revelaing that a particular username exists.
Useful resources
  • TBC.

When completion of a form causes a legal commitment, triggers a financial transaction, or gives consent for personal data to be updated or changed, the user must be able to review, correct, and confirm that the information they have entered is correct, or they must be able to reverse the decision. This provides safeguards to prevent people with disabilities, and indeed all users, from making avoidable mistakes.

Requirements / What to do?
  • When data is submitted leading to a legal commitment, financial transaction, or an update to personal data, an interim page, alert or status message is presented that allows the user to review, correct, and confirm the information they have entered.
Common mistakes
  • An online shop where order or personal details are not displayed so the user can confirm them or make changes.
Useful resources

Robust

4.1.3 Status Messages

4.1.3 Status Messages (AA)

There are different situations where a status message needs to be shown in a way that assistive technologies understand. These messages need to be presented to the user without receiving focus themselves, or disturbing the user’s place in a page.

Why is this a problem?
  • A sighted person can quickly see status messages on a page, and them go back to what they were doing or reading. Moving focus to a message can be disruptive for screen reader users, users of speech recognition software and keyboard only users.
  • If focus is always moved to the message users with cognitive impairments may also be confused by unpredictable focus changes.
Requirements / What to do?

The following are different situations where you will need to cover.

When a status message tells the user something is successful

When a status message tells the user something is successful or is the results of an action. This can also be used for a state change when part of a page updates:

You can use these following techniques:

Use the ARIA role=status to present status messagesin combination with the technique Providing success feedback when data is submitted successfully.

If a status message conveys a suggestion, or a warning or error:

NOTE: There may be time when you do want to move focus to a message, such as an error, as a part of form validation etc.

Use the following techniques:

Use ARIA role=alert or Live Regions to Identify Errorsin combination with any of the following:

If a status message conveys information on the progress of a process:

The ARIA role="progressbar" can be used but may not be enough on its own (depending on AT and browser support). For some examples of progressbar role see:

You can use the following techniques:

Common mistakes
  • Status messages are not to be shown in a way that the AT understands or receive focus.
  • Using role="alert" or aria-live="assertive" on content which is not important.
  • On a page with ARIA live regions - if regions are hidden or not needed - always make sure to switch their active and inactive states accordingly.