Perceivable

Include a text equivalent for non-text content to ensure that it serves the same purpose for everyone because not all individuals can perceive images or multimedia content similarly.

Various methods can be employed to accomplish this:

• Add a text alternative to all images describing the image (alt=“description”).
• Include an aria-label or visually-hidden text for icons without accompanying text.
• Provide a short description for videos and audio, but ideally, provide a transcript (aria-describedby=“description id”).
• Add a name for non-text controls or input fields (class=“visually-hidden” or an aria-label).

What makes good alt text

The precedence for calculating a text alternative should be:

1. aria-labelledby
2. aria-label
3. alt
4. title

In cases where two or more of the above are used, whatever is highest in that list becomes what gets used.

Examples:

<button type="button">
  <span>
    <i class="icon-calendar" aria-hidden="true"></i>
    Start a check-in
  </span>
</button>

<a href="">
  <i aria-hidden="true" class="icon-user"></i>
  <span class="visually-hidden">Administration centre</span>
</a>

<button type="button" aria-label="Close">
  <i aria-hidden="true" class="icon-close"></i>
</button>

<a href="" aria-current="page" title="Appraisd dashboard">
  <img src="https://cdn.appraisd.com/assets/branding/appraisd-logo-pink.svg" alt="Appraisd" class="logo">
  <span class="visually-hidden">Dashboard</span>
</a>

Understanding 1.1.1: Non-text content

Providing an alternative is crucial to ensure that video-only and audio-only content is accessible to all users.

Simply offering a text transcript that conveys the same information as the audio-only content can make a significant difference.

When it comes to video-only content, you have two options. You can provide a text transcript that conveys the same information or offer an audio track that delivers the same content as the video.

By doing so, you're helping users with disabilities to access and understand the content, providing a better user experience for everyone.

Understanding 1.2.1: Audio only and video only prerecorded

• Include captions (subtitles) for all videos that have audio.
• Ensure all spoken words in videos have captions.
• Identify each speaker in turn.
• Provide captions for all non-speech elements, such as significant sound effects.

Understanding 1.2.2: Captions prerecorded

Provide an audio description or text transcript to make videos with sound accessible.

If an interview is face-to-face, providing an audio description may not be required.

To ensure accessibility, you should provide a full-text transcript of the video.

Understanding 1.2.3: Audio description or media alternative prerecorded

All live audio content in synchronised media must have captions provided.

Understanding 1.2.4

To ensure that videos with sound are accessible to everyone, provide a full-text transcript of the video, or offer a version with an audio description.

By doing so, individuals who may have difficulty hearing or seeing the video content can still access the information provided.

Understanding 1.2.5: Audio description prerecorded

Ensure that information, structure, and relationships conveyed through the presentation can be programmatically determined and available in a text format to ensure accessibility.

• To create a structured and labelled webpage, use landmarks such as HTML elements nav, main, header, footer, or ARIA roles navigation, main, banner, contentinfo, etc.
• Label landmarks with aria-label or aria-labelledby if there is more than one with the same role on the page.
• Use HTML headings h1 – h6 whenever possible. If not, use role="heading" and aria-level="[1, 2, 3, 4, 5, 6]".
• For form controls, use either fieldset and legend or role="group" and aria-labelledby="heading id". If additional information is required, include aria-describedby="description id".
• Provide a label for every input control to describe its purpose.
• Use tables for data layout only, and include a caption and scoped table headings (th).
• Use lists where appropriate to organise content.
• Use buttons for actions (do this) and links for navigation (go there).

Understanding 1.3.1: Info and Relationships

Ensure the code presents elements in a logical reading order so that screen-reader users also experience the content in a meaningful order.

If CSS is used to arrange a navigation bar, a main story, and a side story on a web page, it's possible that the visual order doesn't match the logical order of the content. However, this is irrelevant as long as the meaning of the page remains unaffected by that order.

Understanding 1.3.2: Meaningful sequence

Avoid using sensory characteristics, like colour, shape, visual position, orientation, or sound, to imply meaning. Instead, use clear and concise language to convey the intended message.

For instance, avoid phrases like “Instructions are to the left” or “Click the round green icon to continue.”

Understanding 1.3.3: Sensory characteristics

Ensure the webpage can be viewed in portrait and landscape modes by not restricting the page orientation.

<meta name="viewport" content="width=device-width, initial-scale=1">

It may be judicious to prevent font-size glitches on mobile devices too.

body {
  -moz-text-size-adjust: none;
  -webkit-text-size-adjust: none;
  text-size-adjust: none;
}

Understanding 1.3.4: Orientation

To ensure the purpose of input fields can be determined programmatically, follow these guidelines:

• Set the type attribute of input fields, such as telephone number (tel), email address (email), plain text, password, etc. Specifying the type attribute will ensure mobile devices display the most appropriate keyboard for each field. See MDN HTML5 input types.
• Use specific autocomplete values to allow the user's browser to autofill fields with relevant information based on the context. You can find a list of acceptable values on MDN HTML attribute: autocomplete.

Build a Better Mobile Input – An interactive tool to assist in visualisation and selection of the appropriate type, inputmode, and autocomplete attributes.

Understanding 1.3.5: Identify input purpose

One of the most critical aspects of providing accessible content is to ensure that instructions are clear and easy to follow.

Describing visual elements with colour-dependent language like "Click the green button" or "Required fields are red" creates unnecessary barriers for users with colour vision deficiencies.

To ensure that instructions are accessible, use additional identifying remarks in combination with colour-dependent language.

For instance, instead of "Click the green button", you could write "Click the green Submit button."

Refrain from using only a red border as a visual cue to signify an input is in an error state. Perhaps add a symbol too.

Remember that designing for accessibility is not just about accommodating people with disabilities but creating a better user experience for everyone.

Understanding 1.4.1: Use of color

Ensure any audio on a web page does not automatically start playing for more than 3 seconds without the option to pause, stop, or adjust the volume independently from the system volume.

Avoiding auto-playing audio content is a best practice and provides a better user experience.

Understanding 1.4.2: Audio control

Make sure there is sufficient contrast between the text and its background.

The contrast ratio should be at least 4.5:1 for "normal" text, and for both large text (24px) and bold text, the minimum contrast required is 3:1.

Colour contrast checker

Understanding 1.4.3: Contrast (minimum)

Except for captions and images of text (don't), the copy should be resizable up to 200% without using assistive technology while maintaining its content and functionality.

A common issue occurs when text block containers have a fixed pixel height, which is easily avoided using min-height instead of height in CSS.

Truncating copy is only acceptable if the full text is available when the element has focus.

Text resizing explained (YouTube – 2 min 14 secs)

Understanding 1.4.4: Resize text

Best practice suggests using actual text instead of images of text unless it is necessary.

Logos, however, are an exception to this guideline and may be presented as images.

Understanding 1.4.5: Images of text

Ensure users can access all content without scrolling horizontally, especially on small screens (320px).

Vertical scrolling is generally more user-friendly than horizontal scrolling, so avoid forcing users to scroll in two dimensions.

To check for compliance, adjust the browser width to 1280 pixels and enlarge the font size to 400%. The page should not require horizontal scrolling.

Exceptions

Multi-directional scrolling is acceptable when necessary for meaning or function, such as for images, maps, diagrams, games, and components that require toolbars to remain visible.

It's also acceptable on complex data tables because it is often necessary to view large amounts of information horizontally and vertically at the same time. This allows users to easily compare and analyze data in the table without having to navigate to different sections of the page.

Understanding 1.4.10: Reflow

Ensure a minimum of 3:1 contrast between interface components, graphics, and adjacent colours, including buttons, icons, and controls, as well as their hover and focus states.

Disabled buttons, logos, and screenshots are exempt from this requirement.

Colour contrast checker

Understanding 1.4.11: Non-text contrast

Users should be able to change text spacing without affecting the content or function.

Test the following spacing guidelines:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing between paragraphs to at least double the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

To ensure compliance with this guideline, a bookmarklet called Text-spacing Bookmarklet can be used to test pages and ensure that content is not lost when text spacing is changed.

Understanding 1.4.12: Text spacing

When designing hover or focus triggered content, it is essential to ensure that content is hoverable, persistent and dismissible.

While content of this type may enhance user experience, it is also challenging to implement effectively.

To make hover or focus triggered content accessible, it must have the following attributes:

• Dismissable: The user must be able to dismiss the content easily without having to move the cursor, or change the keyboard focus. Ideally, this may be accomplished via a close button, or keyboard shortcut that doesn't disrupt the user's flow.
• Hoverable: The user must be able to move the cursor over the additional content without disappearing. This enables users with fine motor or vision impairments to interact with the content effectively.
• Persistent: The new content should remain visible until the user moves the cursor or keyboard focus away from the triggering control, the new content is dismissed, or the new content is no longer relevant.

Best practice suggests to avoid using the Esc key to dismiss, as it causes issues with modals.

Exceptions to this guideline include:

• Where the content communicates an input error.
• Where the content doesn't obscure other content.

Understanding 1.4.13: Content on hover or focus