Understandable
Last modified on Mon 17 Mar 2025

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

Guideline 3.1 - Readable

Make text content readable and understandable. - WCAG2.2

Success Criterion 3.1.2 - Language of Parts

Sometimes there is a need for a page to show the content in multiple languages. In such cases, it is important to mark those parts so that assistive technologies can present the information according to the presentation and pronunciation rules for that language.

Most professions require frequent use of technical terms which may originate from a foreign language. Such terms are usually translated only into some languages. The universal nature of technical terms also facilitates communication between professionals – examples: Homo sapiens, Alpha Centauri, hertz, and habeas corpus.

To better explain what needs to be marked as a different language and what does not, WCAG prepared three examples:

  1. A German phrase in an English sentence.

He maintained that the DDR (German Democratic Republic) was just a 'Treppenwitz der Weltgeschichte'

German phrase inside '' is marked as a German

<p>
 He maintained that the DDR (German Democratic Republic) was just a
 <span lang="de">'Treppenwitz der Weltgeschichte'</span>
</p>
  1. Alternative language links

When a page includes links to versions of the page in other languages, the text is the name of the language, in that language. The language of each link is indicated via a lang attribute.

<ul id="language-menu" role="menu">
 <li lang="de" role="menuitem">
   <a href="/de/page" title="German">
     <bdi>Deutsch</bdi>
   </a>
 </li>
 <li lang="es" role="menuitem">
   <a href="/es/page" title="Spanish">
     <bdi>Español</bdi>
   </a>
 </li>
 <li lang="fr" role="menuitem">
   <a href="/fr/page" title="French">
     <bdi>Français</bdi>
   </a>
 </li>
</ul>

Note: the bdi element used in the example above is the bidirectional isolate element, which tells the browser's directionality algorithm to treat the text it contains in isolation and is useful when content might change direction. Find out more on MDN

  1. "Podcast" used in a French sentence.

À l'occasion de l'exposition "Energie éternelle. 1500 ans d'art indien", le Palais des Beaux-Arts de Bruxelles a lancé son premier podcast. Vous pouvez télécharger ce podcast au format M4A et MP3

The word podcast is not marked as French.

Check out more examples

Guideline 3.2 - Predictable

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

Success Criterion 3.2.3 - Consistent Navigation

Consistent navigation is something that most users, even those without disabilities, rely on. When browsing a set of pages, the user can spot useful information quickly and easily. Presenting repeated content in the same order is also important for visually-oriented users who use spatial memory or visual cues within the design to locate repeated content.

It is important to note that the phrase "same order" in this section does not mean to imply that subnavigation menus cannot be used or that blocks of secondary navigation or page structure cannot be used. Instead, this is intended to assist users who interact with repeated content across Web pages to predict the location of the content they are looking for and find it more quickly when they encounter it again.

This helps users with cognitive limitations, users with low vision, users with intellectual disabilities, and also those who are blind

Examples of consistent navigation are:

WordPress Use or extend the header and footer components from the Eightshift Development Kit to provide consistent navigation.

Success Criterion 3.2.4 - Consistent Identification

To provide users with a better experience and simplify the usage of the web page, it's important to consistently identify functional components. A strategy that people who use screen readers use when operating a Web site is to rely heavily on their familiarity with functions. If identical functions have different labels, the site is more difficult to use.

This consistency extends to the text alternatives. If icons or other non-text items have the same functionality, then their text alternatives should also be consistent. A list of examples can be found at Understanding Success Criterion 3.2.4.

While it is desirable and best practice always to be consistent within a single web page, this Success Criterion only addresses consistency within a set of web pages where something is repeated on more than one page in the set.

WordPress Use blocks and components to provide consistent identification.

Guideline 3.3 - Input Assistance

Help users avoid and correct mistakes. - WCAG2.2

Success Criterion 3.3.3 - Error Suggestion

In case an error is detected and the correction(s) are known, suggestions should be provided to the user as a guide on how to fix the error. This can be omitted if it jeopardizes the content’s security or purpose, e.g., login credentials or CAPTCHA.

If a mandatory field contains no information, the message should explain that the field is required. To implement this, aria-required can signal this information to assistive technologies.

<p>
 <label for="username">Login name: </label>
 <input type="text" name="username" id="username" aria-required="true" />
</p>

If the information for a field is required to be in a specific data format (e.g., date or phone number) or one of a limited set of values (e.g., the month of a year or country name), the validation can be triggered on the client to improve the experience. Show an alert dialog with a description of what caused the error and, if applicable, tell the user what is correct input.

React

Check out useForm implementation of error handling

WordPress Eightshift Forms provides validation and error suggestion features out of the box.

This success criterion intends to help people with disabilities avoid serious consequences as a result of accidental mistakes when performing an action that cannot be reversed, e.g.:

E.g., when buying stocks, a user might unintentionally input a number higher than anticipated. Users with disabilities may be more likely to make mistakes. People with reading disabilities may transpose numbers and letters, and those with motor disabilities may hit keys by mistake.

Providing the ability to reverse actions allows users to correct a mistake that could result in serious consequences. The ability to review and correct information allows the user to detect a mistake before taking action with serious consequences.

Most often, a simple "review" view will do the trick. In case of legal transactions, such as online payments or submitting an income tax return, online services should provide the user with the ability to review (and change) the answers before submitting. If an action causes information to be deleted, a confirmation should be requested from a user or an undo mechanism should be provided. An alternative approach could be to place a checkbox next to the submit button that the user should press and, with that, the user confirms that the inputs have been reviewed.

Other options include (but aren't restricted to):

Success Criterion 3.3.8 - Accessible Authentication (Minimum)

To make authentication possible with less mental effort, we shouldn't make people solve, recall, or transcribe something to log in. This makes the authentication process more accessible for users that cannot solve puzzles, or have a harder time memorizing their username and password. This also covers users who have a hard time retyping one-time passcodes.

The authentication flow should provide at least one of: - An alternative authentication method that does not rely on a cognitive function test. This could mean biometric authentication or a login link via user email. - A mechanism to assist the user to complete the cognitive function test. This means that the use of password managers must be enabled and the password field should not block the clipboard actions. - The cognitive function test that is present, should have a goal of object recognition. This may be images, video, or audio. An example of that would be a flow, where the user needs to upload a picture of themselves as part of a registration process. Then the user should select that picture within a selection of images. - The cognitive function test that is present is focused on identifying non-text content that the user provided to the website. To expand the example from the previous point, the flow should be limited to media elements. Text input would breach WCAG standards, as the user would have to recall their previous input, and not rely on recognition of the information.

The definition of a cognitive function test is remembering the password. Such tests are known to be problematic for many people with cognitive disabilities.

One of the possible failures of this criterion would be a common 2FA flow, where the password/code is often split up into many inputs, per individual character. The user should be able to paste and fill all inputs when this action is performed on the first input element. Having the option to autofill this code (either on mobile from a direct message or with a magic link) is also a good way how to make the authentication login both easier for the users and more secure.

To meet this criterion, we need to provide the user with alternative means of authentication, make sure that the user can interact with the page with their password manager and that clipboard actions are enabled on the authentication fields. Always think about the implementation of SSO, passkeys, or other types of authentication alternatives.

It is not clearly specified, but wording in the documentation does imply that not including the ability to show hidden characters ("show password" feature) would also be a breach of the criterion. This increases the cognitive load on the user. Including this feature greatly increases the chance of success for the users that have difficulties with accurately typing.