Perceivable
Last modified on Fri 17 Mar 2023

Information and user interface components must be presentable to users in ways they can perceive. - WCAG2.1

Time-based Media

"Provide alternatives for time-based media." - WCAG2.1

Captions (Live)

Deaf people and people with hearing issues should be able to participate in real-time presentations. To make this possible, any real-time presentation, e.g., video live-stream, should have captions. Captions provide an alternative for the audio part of the presentation. They include more than just the dialogue but also identify who is speaking and notate sound effects and other significant audio.

To implement this success criterion, captions should be created for live synchronized media and presented to the user.

Audio Description (Prerecorded)

Blind and visually impaired people should be able to access the visual information in a prerecorded synchronized media presentation. To make this possible, an audio description can be provided. The audio description augments the audio portion of the presentation with the information needed when the video portion is unavailable. During existing pauses in dialogue, audio descriptions provide information about actions, characters, scene changes, and on-screen text that are important and are not described or spoken in the main soundtrack.

This audio track can be the main track of the video, or it can be presented to a user as a second, user-selectable audio track.

Adaptable

Create content that can be presented differently (for example, a simpler layout) without losing information or structure. - WCAG2.1

Orientation

Content should allow its view and operation to various display orientations, such as portrait or landscape. To make this possible, the content should adapt to the device's orientation. Some users have their devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair); therefore, an application needs to be adaptable.

The exception for essential screen orientations is aimed at situations where the content would only be understandable in a particular orientation or where the technology restricts the possible orientations, e.g. TV has a fixed landscape orientation. Technologies such as virtual reality use screens within goggles that cannot change orientation relative to the user's eyes. A piano app is also an exception, as the piano app in portrait orientation would have too small or too few keys in portrait orientation. CSS orientation media query

body {
 display: flex;
}


@media (orientation: landscape) {
 body {
   flex-direction: row;
 }
}


@media (orientation: portrait) {
 body {
   flex-direction: column;
 }
}

Identify Input Purpose

The purpose of any field that requires input from the user should be programmatically determinable. To explain this, we'll cover an example.

See Understanding Success Criterion 1.3.5: Identify Input Purpose for more information.

Let's say we have a simple form for collecting user data:

<form>
 <p><label for="first-name">First name: </label><input id="first-name" /></p>
 <p><label for="last-name">Last name: </label><input id="last-name" /></p>
 <p><label for="postal">Postal code: </label><input id="postal" type="number" /></p>
 <p><label for="bday">Date of birth: </label><input id="bday" type="date" /></p>
 <p><label for="phone">Phone number: </label><input id="phone" type="tel" /></p>
 <p><label for="mobile">Mobile phone number: </label><input id="mobile" type="tel" /></p>


 <button type="submit">Submit</button>
</form>

At first sight, we notice that each field has a unique identifier and a label, which should be enough. Even though this might be "good enough", every input can take an autocomplete prop that will simplify the user interaction. The complete list of autocomplete values can be found in the WHATWG Standard.

With autofill, this form looks like the following:

<form>
 <p><label for="first-name">First name: </label><input id="first-name" autofill="given-name" /></p>
 <p><label for="last-name">Last name: </label><input id="last-name" autofill="family-name" /></p>
 <p>
   <label for="postal">Postal code: </label
   ><input id="postal" type="number" autofill="postal-code" />
 </p>
 <p><label for="bday">Date of birth: </label><input id="bday" type="date" autofill="bday" /></p>
 <p>
   <label for="phone">Phone number: </label><input id="phone" type="tel" autofill="home tel" />
 </p>
 <p>
   <label for="mobile">Mobile phone number: </label
   ><input id="mobile" type="tel" autofill="mobile tel" />
 </p>


 <button type="submit">Submit</button>
</form>

Distinguishable

Make it easier for users to see and hear content, including separating foreground from background. - WCAG2.1

Contrast (Minimum)

Whenever there is text on a web page, it is recommended to provide enough contrast between the text and its background. This is needed so people with moderately low vision, who do not use contrast-enhancing assistive technology, can read it.

For people without color deficiencies, hue and saturation have minimal or no effect on legibility as assessed by reading performance (Knoblauch et al., 1991).

With the following in mind, it is recommended to calculate the contrast so that color is not a key factor.

One exception is the text used for decoration, e.g., words as background.

The required contrast is different for all font sizes. Larger font sizes are easier to read, therefore, can work with lower contrast. The threshold is 18pt for the regular font weight and 14pt for bold or heavier font weights. For large text, the minimum contrast ratio is 3:1, and for others is 4.5:1.

To check the contrast ratio, use one of the few options:

Resize text

The intent of this Success Criterion is to ensure that all text can be scaled successfully. This will help people with mild visual disabilities read the text without using assistive technology such as a screen magnifier.

Even though scaling is primarily a user agent's responsibility, the author's responsibility is to create Web content that allows the user agent to scale the content effectively.

The author cannot rely on the user agent to satisfy this Success Criterion for HTML content if users do not have access to a user agent with zoom support. For example, if they work in an environment that requires them to use IE 6.

In the case a user agent does not provide zoom support, the author is responsible for providing this type of functionality directly or providing content that works with the type of functionality provided by the user agent. E.g., if the user agent does not support zoom support but lets the user change the font size, the author is responsible for creating content that works with that.

The Success Criterion says that the content should be able to be zoomed in up to 200%, twice as large. If needed, the support could be more than 200%, but in such (extreme) cases, the words could be too long to fit in one line, or a simple layout could cause issues.

To create such content, an author could:

Images of Text

When an image is used to show text on the web page, such text won't be reliably presented and could collide with other Success Criteria, such as the previous one - Resize text. To avoid those cases, the author should use text to achieve the same visual effect if possible. If that is not possible, the image should have a text alternative.

Images are often used for logotypes, branding, etc., which is an exception to this Success Criterion.

Reflow

Supporting content reflow is also known as 'Responsive Web Design'.

The intent is to support people with low vision who need to enlarge text and read it in a single column. This is critical as it allows those users to read content on the webpage. To enlarge text, users will use the user agent zooming feature.

This Success Criterion can be interpreted in two (mostly equivalent) ways:

The value of 320 CSS pixels was chosen as a reasonable minimum size the authors can achieve. This value lines up with the reported viewport width of small displays of common mobile devices. The width of 320 CSS pixels exactly corresponds to a desktop browser window set to a width of 1280px and zoomed in to 400%.

Reflow is a way to display the page content in a single-column layout so users can read easier and the content of the page does not overflow the width of the screen. It is important to ensure that there is no horizontal scroll as this significantly increases the effort to read - unless the page requires a horizontal scroll to function properly, e.g., a spreadsheet application.

Reflow can be enabled using the following:

@media screen and (min-width: 320px) {
 /* ... */
}

.container {
 width: 100%;
 display: flex;
 flex-flow: row wrap; /* flex-direction: row; flex-wrap: wrap; */
}

.container {
 width: 100%;
 display: grid;
 grid-template-columns: repeat(auto-fit, minmax(320px, 1fr));
}

Sometimes, there will be words or links that will not fit in the reflowed layout. To fix this, developers can use the CSS property overflow-wrap.

Non-text Contrast

All non-text content, such as UI components and meaningful graphics, should be distinguishable by people with moderately low vision. Requirements are similar as for large text in Contrast (Minimum) section.

For active controls, any visual information necessary for a user to identify that control is present and how to operate it must have a minimum 3:1 contrast ratio with the adjacent colors. Also, any visual information necessary to indicate a state, such as whether a component is selected or focused, must ensure that the information used to identify the control in that state has a minimum 3:1 contrast ratio.

Find more examples and explanations on WCAG - Understanding Success Criterion 1.4.11: Non-text Contrast.

Text Spacing

To ensure that people with low vision, or people with dyslexia, are able to read the text content, the author should ensure that people can override the specified text spacing of the content.

Find common mistakes and solutions on WCAG - Understanding Success Criterion 1.4.12: Text Spacing.

Content on Hover or Focus

Additional content that appears and disappears in coordination with keyboard focus or pointer hover often leads to accessibility issues. There are 3 main reasons for such issues:

  1. the user may not have intended to trigger the interaction
  2. the user may not know new content has appeared
  3. the new content may interfere with a user's ability to do a task

Examples of such implementations are tooltips, submenus, and other non-modal popups.

Such interactions must be designed so users can:

and must meet these three conditions:

Find more examples and explanations on WCAG - Understanding Success Criterion 1.4.13: Content on Hover or Focus.