This article provides practical advice on how to write your web content so that it conforms to the success criteria outlined in the Understandable principle of the Web Content Accessibility Guidelines (WCAG) 2.0 and 2.1. Understandable states that information and the operation of user interface must be understandable.

Note: To read the W3C definitions for Understandable and its guidelines and success criteria, see Principle 3: Understandable — Information and the operation of user interface must be understandable.

Guideline 3.1 — Readable: Make text content readable and understandable

This guideline focuses on making text content as understandable as possible.

Success criteria How to conform to the criteria Practical resource
3.1.1 Language of Page (A) The default human language of each web page should be detectable via code. This is essential for purposes like making sure the reader has arrived at a page written in a language suitable for them. The simplest way to achieve this is to set the lang attribute on the page's <html> element, giving it a value equal to the language code that best represents the language the page is written in. See Setting the primary language of the document.
3.1.2 Language of Parts (AA)

In cases where the content of a page includes words or phrases that are in a different language to the primary language, use the lang attribute on an element wrapped around the term in question (e.g. a <span> if no semantic element is available) to set an appropriate language for it.

You don't need to set a different language for words or phrases that are the same regardless of language (for example proper names, technical terms that aren't part of a specific language).

3.1.3 Unusual Words (AAA) Where technical terms, jargon, or idioms/slang are used, definitions should be provided for such phrases/words. Your site should provide a glossary that contains definitions of such words/terms that you can then link to when they appear, or at the very least provide definitions somewhere in the surrounding text, or in a description list at the bottom of the page.
3.1.4 Abbreviations (AAA)

Where abbreviations are used, you should provide an expansion of them, or a definition as required.

The <abbr> element is often thought of as the preferred way to provide an expansion for an abbreviation — it takes a title attribute that contains the expansion, and this appears when the acronym is moused over. However, the title contents are not accessible via keyboard, nor are they reliably read out by screen readers. A better way to handle this is to again provide links to glossary pages containing the acronym expansion and explanation, or at the very least include them in the surrounding text in context.

See Abbreviations.
3.1.5 Reading Level (AAA)

If text is provided that requires a higher reading level that lower secondary education level (typically children around 11-14 years old), provide supplementary explainer material to help people who can't read it, or provide an alternative version that is written at lower secondary level.

This doesn't mean that all subject matter should be understood by everyone, but that the style of writing should be accessible by everyone. It is better to just write all content at lower secondary level, even technical documentation like programming tutorials, unless there is a good reason not to (e.g. an alternative style for poetic effect), or they have to be written in a strict style (e.g. W3C specs).

3.1.6 Pronunciation (AAA)

A mechanism should be provided to give users access to pronunciation of words where they are is needed to understand the content fully.

The HTML <audio> element can be used to create a control that allows the reader to play back an audio file containing the correct pronunciation, and it also makes sense to include a textual pronunciation guide after difficult words, in the same way that you find in dictionary entries.

See Video and audio content, and Pronunciation Guide for English Dictionary

Guideline 3.2 — Predictable: Make Web pages appear and operate in predictable ways

This guideline focuses on making user interfaces intuitive and understandable.

Success criteria How to conform to the criteria Practical resource
3.2.1 On Focus (A)

When a control or other page feature receives focus, it should not change the context in a way that may confuse or disorientate the user.

This is a matter of sensible design — people don't want interfaces to surprise them; they want things to be intuitive and behave as expected. For example, focusing a navigation menu option should not change the displayed page — it should be activated before the display changes.

Element.focus_event contains some useful information. Also see Building keyboard accessibility back in for some useful implementation ideas.
3.2.2 On Input (A)

When data is inputted into a control, or a setting is changed, context should not be changed unexpectedly. The user should be warned/advised of the impending change before it occurs.

Again, sensible design should be implemented. For example, if pressing a button causes the application to exit the current view, the user should be asked to confirm this action, save their work if appropriate, etc.

The input event is useful here.
3.2.3 Consistent Navigation (AA)

Navigation menu/control style and positioning should be consistent between different pages or views of a web page, and the existing items should appear in the same order, even if for example new items are added. If the user has initiated a change, e.g. choosing a different color scheme or position for the navigation, their choice should be respected across all pages.

Again, sensible design — make the navigation controls the same across all pages or views.

See Page layouts for information on modern markup for layouts. See also Styling links as buttons for a useful accessible navigation menu example.
3.2.4 Consistent Identification (AA)

Controls or components that have the same functionality should be identified in the same way across different pages or views. A currency converter appearing on every page of a world travel site for example should be exactly the same, semantically and in terms of labels.

Again, sensible design!

"Labels" can refer to descriptive information in text content, or HTML form labels. See Meaningful text labels for more information.
3.2.5 Change on Request (AAA)

Changes in context that could possibly confuse or disorient users should only occur only when requested by the user, OR the user should be able to turn them off.

If you need to have something that significantly changes the current view (e.g. content or controls), let the user control when they want that change to occur (e.g. what page to show, when to advance to the next photo in the gallery...)

If you need to have something like a carousel on a page, provide an option to stop it automatically advancing. Better to avoid such functionality if possible.

3.2.6 Consistent help (A)

Web pages that contain help mechanisms, including self-help options and human contact details, that are repeated on multiple web pages, need to place those mechanisms in the same order on all pages, unless a change is initiated by the user.

Check out the consistent help documentation for this standard to learn more.

Guideline 3.3 — Input Assistance: Help users avoid and correct mistakes

This guideline centers around helping users enter correct information when required with the minimum of mistakes.

Success criteria How to conform to the criteria Practical resource
3.3.1 Error Identification (A)

When a user is filling out a form or choosing between options, any error that is detected should be clearly reported to the user, along with the form control that the error relates to.

It is advisable to implement client-side error detection and handling, via HTML form validation features, and/or JavaScript, whatever is best for your situation. When an error is detected, an intuitive error message should be shown next to the form input that is at fault to help the user correct their inputs. For screen reader users, you can use aria live regions to alert the user to a change on the page.

Note: Server-side validation should *always* be used alongside client-side validation. Client-side validation is too easy to turn off or otherwise get around, so it can't be relied on alone.

See Form data validation for comprehensive validation information, and WAI-ARIA: Dynamic content updates for information on live regions.
3.3.2 Labels or Instructions (A)

Clear instructions should be provided when data input is required. When a simple instruction or prompt is required, you can use <label> elements for single inputs like name or age, a combination or <label>s and <fieldset>s/<legend>s for multiple inputs that go together (like the elements of a date of birth or postal address).

When more complex explanation is required, you can always include explanatory paragraphs too, or maybe you need to try to make your forms more intuitive.

3.3.3 Error Suggestion (AA)

When an error is detected and suggestions for correction are known, provide these to the user (e.g. suggesting alternatives when the user is choosing a user name and has selected one that is already taken), unless doing so would cause a security issue (e.g. when entering a password) or context problem (e.g. they are trying to answer a question in a quiz app).

In such cases, when this is appropriate, you'll probably use a combination of JavaScript and server-side functionality to check if the entry is correct, and if not, what viable suggestions can be given to the user. Such suggestions should be displayed usefully in context, just like error messages (see 3.3.1).

No tutorial suggestions yet.
3.3.4 Error Prevention (Legal, Financial, Data) (AA)

In the case of forms involved with entry of sensitive data (such as legal agreements, e-commerce transactions, or personal data), at least one of the following should be true:

  • Submissions are reversible.
  • Data is checked for errors, and the user is given an opportunity to correct them.
  • A mechanism is available for confirming and correcting information before final submission.

Reversible — for any view where data can be entered, provide an equivalent view that allows you to edit or even delete an entry, as appropriate (for example, see Django web framework).

Checking data — as covered in 3.3.1, a combination of client-side and server-side validation should be used to detect errors and display helpful messages to the user to allow them to correct their inputs.

Confirm and correct — where appropriate, after filling in a series of form fields to perform a task (such as buying a product), the user should be shown a confirmation screen where they can review their inputs and correct anything that doesn't look right. This pattern is commonly used on e-commerce sites like Amazon.

3.3.5 Context-sensitive help is available (AAA) Provide instructions and other appropriate cues in context to aid form completion and submission. This really just builds on 3.3.1 and other similar criteria but requires more thorough contextual help information and services, e.g. providing a dedicated link to a help page or service on each page, providing examples showing what successful completion should look like.
3.3.6 Error Prevention (All) (AAA) This principle builds on 3.3.4, extending its requirements to all user input situations, not just ones involving sensitive data. Again, see 3.3.4.
3.3.7 Redundant entry (A) Information that is required that was previously entered or provided by the user in the same process or user flow is either auto-populated or made selectable to the user from a list of options, unless re-entering the information is essential or required for security reasons, or if the information is no longer valid. Check out Understanding redundant entry to learn more.
3.3.8 Accessible authentication (Minimum) (AA) Cognitive function tests, like remembering a password, are not required for any step in an authentication process unless an alternative is provided, such as an object or personal content (e.g., images, videos, and audio) recognition, or a mechanism to assist (e.g., copy and paste and autosave passwords). Check out the accessible authentication documentation for this standard to learn more.
3.3.9 Accessible Authentication (Enhanced) (AAA) A cognitive function test, like remembering a password, must not be required for any step in an authentication process without providing an alternative that does not rely on a cognitive function test or provides a mechanism to assist the user in completing the cognitive function test. Authentication tests that require the user to recognize objects or identify non-text content the user provided to the website are allowed. Check out the enhanced accessible authentication documentation (AAA) to learn more.

See also