Understandable
Last modified on Fri 21 Feb 2025

Information and the operation of user interface must be understandable. - WCAG2.2

Guideline 3.1 - Readable

Make text content readable and understandable. - WCAG2.2

Success Criterion 3.1.1 - Language of Page

The language of the page should be programmatically determinable in order to give users the best experience and enable user agents to present text and other content correctly. With this, both assistive technologies and conventional user agents can present the text more accurately, e.g., screen readers can read the page with correct pronunciation, visual browsers can display characters correctly, etc. As a result, users with disabilities will be better able to understand the content.

The Using the language attribute on the HTML element technique says to specify the language as an attribute on the root html element.

<html lang="fr">
 <head>
   <title>document écrit en français</title>
   <meta charset="utf-8" />
 </head>
 <body>
   ...document écrit en français...
 </body>
</html>

Guideline 3.2 - Predictable

Make Web pages appear and operate in predictable ways. - WCAG2.2

Any change of context should always be an expected action to help people with visual disabilities, cognitive limitations, and motor impairments.

Success Criterion 3.2.1 - On Focus

Any element that can trigger an event when it receives focus must not change the context to keep the functionality predictable. Examples of context changes on focus:

Focus may be changed using a keyboard or the mouse. An important thing to mention is that hovering over an element does not change the focus (unless scripting implements this behavior).

To satisfy this Success Criterion, do not use the onfocus event or change the context on focus.

Success Criterion 3.2.2 - On Input

When a user enters data or selects a form control, the effects of such actions should be predictable. Changing a setting on a webpage should not cause a change of context, such as opening a popup window or refreshing content. In addition, users should not be taken away from a webpage when changing something without warning.

Examples:

The simplest solution to satisfy this is to provide a submit button. More info can be found in the following techniques: Providing a submit button to initiate a change of context and Providing submit buttons.

Success Criterion 3.2.6 - Consistent Help

To support people finding help more easily, it has to be in the same location, if it is present on different pages throughout the portal.

Under 'help', we consider: - Human contact details (ex. a phone number and/or email address for customer support, a live chat agent); - Human contact mechanism (ex. a 'Contact us' form, a support ticket system, a callback request action); - Self-help option (an FAQ page, a help center); - A fully automated contact mechanism (a chatbot, an interactive troubleshooting tool);

This criterion doesn't check for the presence of help, but is focused on how the access to help is implemented. So when the portal offers help (for example, a contact link) across multiple pages, it has to be rendered on a consistent location. An example of that would be that we have contact information for support in the footer (which should contain the same content on all pages). This way, the user doesn't have to search for help, but can rely that if the help is offered, it will be always in the same location.

If the page has several different help mechanisms (live chat, support links, contact information), they should appear in the same order relative to other page content. This means that semantically these mechanisms should be ordered in the same way, per page variation. If the user initiates a change (page zoom, orientation), this would be considered a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (same zoom level and orientation).

Guideline 3.3 - Input Assistance

Help users avoid and correct mistakes. - WCAG2.2

Success Criterion 3.3.1 - Error Identification

Make sure users know that an error has occurred and that they can determine what is wrong. For that reason, the message should be as specific as possible. In addition to the text description, it is perfectly acceptable to indicate the error in other ways, such as image, color, etc.

Please note that NIST recommendation for error messages regarding the email/username and password fields should not be specific to each field. For example, "Email does not exist", but rather a general message regarding the combination of two, e.g., "Credentials are incorrect" to prevent leaking additional information to attackers.

In case of an error when submitting a form, re-displaying the form and indicating the fields in error is insufficient for some users. Screen reader users, e.g., will not know there was an error until they encounter one of the indicators. As a result, they may abandon the form before encountering the error indicator.

Per the definition in WCAG 2.0, an "input error" is information provided by the user that is not accepted. This includes:

  • information that is required by the web page but omitted by the user, or
  • information that is provided by the user but that falls outside the required data format or allowed values.

If fields that require user input were not completed by the user or are provided in an incorrect form, then the error should be shown to the user. This error can be client-side validation or server-side validation. In combination with an error, one more sufficient technique is to use the aria-invalid property on fields.

<div class="control">
 <p>
   <label for="email">Email address: [*]</label>
   <input name="email" id="email" aria-invalid="true" aria-describedby="err_1" required />
 </p>
 <span id="err_1">Error: Data is missing</span>
</div>

Notice that the aria-describedby is used to programmatically connect the field to an error message.

Sometimes, an error might be connected to two or more fields. In such cases, alert dialogs or live regions can be used.

Find more about WCAG sufficient techniques.

WordPress Eightshift Forms provides validation and useful error messages out of the box.

Success Criterion 3.3.2 - Labels or Instructions

When a user lands on a page with form controls, content authors should present information and/or labels that identify them. This way, the user knows what input data is expected from them. The idea is not to clutter the page with a ton of information - as too much can be just as harmful as too little.

The goal is to ensure enough information is provided for the user to accomplish the task without undue confusion or navigation.

This can be accomplished by providing a label to a form control.

<div>
 <label for="firstname">First name</label>
 <input type="text" name="firstname" id="firstname" />
</div>

WordPress Blocks and components from the Eightshift Development Kit provide attributes for setting labels and aria-labels where applicable. Eightshift Forms provides labels for form fields out of the box.

Success Criterion 3.3.7 - Redundant Entry

To make it easier for users to complete multi-step processes, the flow shouldn't ask them to input the same information twice in the same session. This criterion is focused on helping people with cognitive and motor disabilities. They could have problems remembering their previous inputs, or redundancy could make the process longer and more taxing without a good reason.

An example of this flow would be during a purchase flow, where the user has to input a billing address and a delivery address. Most often, this is the same information, and has to be present in the form twice. Without having an option to auto-populate the second set of inputs, the flow would breach this criterion. In this scenario, this can be achieved with a checkbox "Shipping address is the same as billing address" or by offering a pre-population of the repeated fields through a dropdown option.

This criterion does not require storing information between sessions but focuses on a single process. However, if a process runs across different domains (for instance, a check-out process with a third-party payment provider), that would be within the scope of this criterion.

Exceptions: - Essential uses of input re-entry for things like memory games, which would be invalidated if the previous answers were supplied. - Security measures such as preventing a password string from being shown or copied. When creating a password, it should be a unique and complex string. If the system required the user to manually create a password that is not displayed, having users re-validate the new string is allowed as an exception. - When the previously entered information is no longer valid.

When implementing techniques such as auto-population, we should ensure data protection when storing information even temporarily during a process. Is is possible to eliminate redundant entry in ways that do not introduce additional privacy risks, but it is also possible that a poor implementation for meeting this criterion could leak private information, so this topic should be approached carefully.