The Project | About Us | Contribute | Donations | License
HOME My courses Completed
◄ Previous
◄

Understandable: Information and Operation

Next ►
►

We already know that content must be perceived (03-01) and that the interface must be operated (03-02). But a website can be perceivable and operable and still be incomprehensible: undeclared language, behaviors that change without warning, or an enrollment form that rejects the data without explaining why. The third POUR principle, Understandable, requires that information and the operation of the interface be understandable. It is the principle that helps Hugo (dyslexia/ADHD) the most—for whom predictable text and well-explained errors make the difference between finishing enrollment or giving up—but it also benefits Marta, whose reader needs to know the language to pronounce things correctly.

Contents

  1. What the Understandable principle requires
  2. Guideline 3.1: Readable
  3. Guideline 3.2: Predictable
  4. Guideline 3.3: Input Assistance
  5. Success criteria summary table
  6. Common mistakes and tips
  7. Exercises
  8. Conclusion

What the Understandable principle requires

Understandable means the user can understand the information and understand how the interface works: no surprises, help when needed, and the ability to detect and correct their errors. Three guidelines structure it.

graph TD
    C[3. Understandable] --> A[3.1 Readable]
    C --> B[3.2 Predictable]
    C --> D[3.3 Input Assistance]

Guideline 3.1: Readable

Make text content readable and understandable, starting by telling the machine what language it is in.

  • 3.1.1 Language of Page (A): declare the primary language (<html lang="en">). Without it, Marta's reader may read English with the wrong phonetics, becoming unintelligible.
  • 3.1.2 Language of Parts (AA): fragments in another language are marked (lang). If a Cursalia lesson quotes a term in another language, that fragment is tagged so it is pronounced correctly.
<!-- Illustrative: language of the page and of a fragment -->
<html lang="en">
  ...
  <p>The principle is called <span lang="es">Robusto</span> in the Spanish original.</p>

The more advanced criteria on readability and translation (i18n) are revisited in Module 7: i18n.

Guideline 3.2: Predictable

Make pages appear and operate in predictable ways. Nothing should change context unexpectedly.

  • 3.2.1 On Focus (A): an element receiving focus must not trigger a change of context (opening a window, submitting a form). If tabbing to the filter's language selector reloads the page on its own, Lucía gets lost.
  • 3.2.2 On Input (A): changing a control's value (choosing an option from the dropdown) must not, on its own, change the context without warning. There should be an "Apply" button, or a warning about the behavior.
  • 3.2.3 Consistent Navigation (AA): repeated navigation elements appear in the same order on every page. Cursalia's header does not move between the catalog and a course page.
  • 3.2.4 Consistent Identification (AA): components with the same function are identified the same way across the site. The "search" icon cannot be called "Search" in one view and "Magnifier" in another.
  • 3.2.6 Consistent Help (A) — new in WCAG 2.2: if help mechanisms exist (contact, chat, FAQ), they appear in a consistent relative order across pages. Hugo always finds help in the same place.

Guideline 3.3: Input Assistance

Help users avoid and correct mistakes. This is the central guideline for the enrollment form.

  • 3.3.1 Error Identification (A): if an error is detected, it is identified and described in text (not just a red border). "The email is not valid" next to the field.
  • 3.3.2 Labels or Instructions (A): fields carry labels and instructions when needed ("Format: DD/MM/YYYY"). Without a label, Marta does not know what to type.
  • 3.3.3 Error Suggestion (AA): when the fix is known, the suggestion is offered. "The email must include @" helps more than "invalid field".
  • 3.3.4 Error Prevention (Legal, Financial, Data) (AA): in actions with consequences (a course payment, a legal commitment), the operation must be reversible, checked, or confirmed before it is executed.
  • 3.3.7 Redundant Entry (A) — new in 2.2: do not ask for the same information twice in the same process; reuse it or let the user pick it. If registration already asked for the email, the payment step does not require it again by hand. This eases Hugo's cognitive load.
  • 3.3.8 Accessible Authentication (Minimum) (AA) — new in 2.2: signing in must not depend on a cognitive test (remembering, transcribing, solving a puzzle) with no alternative. A distorted-text CAPTCHA with no accessible option fails; allowing the password to be pasted or a manager to be used does help.
<!-- Illustrative: label + instruction + error in text -->
<label for="email">Email</label>
<input id="email" type="email" aria-describedby="email-help email-err">
<p id="email-help">We will use this email for your access.</p>
<p id="email-err">The email must include an @.</p>

The actual building of accessible forms (labels, aria-describedby, announcing errors) is Module 4: Accessible Forms.

Success criteria summary table

Criterion Level What it requires
3.1.1 Language of Page A Declare the primary language (lang)
3.1.2 Language of Parts AA Mark fragments in another language
3.2.1 On Focus A Focusing does not change the context
3.2.2 On Input A Changing a value does not change the context without warning
3.2.3 Consistent Navigation AA Repeated navigation in the same order
3.2.4 Consistent Identification AA Same function, same identification
3.2.6 Consistent Help A (2.2) Help mechanisms in a consistent order
3.3.1 Error Identification A Errors described in text
3.3.2 Labels or Instructions A Labels/instructions on the fields
3.3.3 Error Suggestion AA Offer how to fix the error
3.3.4 Error Prevention AA Reversible/checked/confirmed on critical actions
3.3.7 Redundant Entry A (2.2) Do not re-ask for data already provided
3.3.8 Accessible Authentication (Minimum) AA (2.2) Login without a mandatory cognitive test

Common Mistakes and Tips

  • Forgetting lang on the <html>. This is a very frequent, very easy-to-fix Level A failure; it affects all speech synthesis.
  • Flagging errors only with the color red. This violates 3.3.1 (and 1.4.1 from the Perceivable principle): the error must also be in text.
  • Auto-submitting the form when an option is chosen. This breaks 3.2.2; use an explicit button or warn about the change.
  • Cognitive CAPTCHAs with no alternative. With WCAG 2.2 and 3.3.8, requiring users to transcribe distorted text with no other path is a violation.
  • Asking for the same data at every checkout step. 3.3.7 asks you to reuse it; it also reduces abandonment.
  • Tip: for Hugo, consistency is as important as clarity. Keep labels, icons, and the location of help identical across all views of the SPA.

Exercises

Exercise 1. The enrollment form marks fields with errors only by painting their border red, with no text at all. State which criteria are violated and what each one requires.

Exercise 2. In the catalog, choosing a category in the filter dropdown reloads the page and jumps to another view without the user clicking anything. Which criterion is violated and what is the requirement?

Exercise 3. Access to Cursalia forces users to solve a CAPTCHA that asks them to transcribe distorted letters, with no alternative. Which WCAG 2.2 criterion applies and what does it require as a minimum?

Solutions

Solution 1. This violates 3.3.1 Error Identification (A) —the error must be described in text, not just with color— and, because it depends on color, also 1.4.1 Use of Color (A) from the Perceivable principle. Requirement: add a text message next to the field (ideally with a correction suggestion, 3.3.3). The implementation is covered in Module 4.

Solution 2. This violates 3.2.2 On Input (A): changing a control's value must not trigger an unexpected change of context. Requirement: apply the filter with an "Apply" button, or clearly warn that selecting will reload the view.

Solution 3. 3.3.8 Accessible Authentication (Minimum) (AA), new in WCAG 2.2 applies. It requires that an authentication method exist that does not require a cognitive test; as a minimum, offer an accessible alternative to the CAPTCHA (e.g. allowing password managers, not blocking pasting, or a different path).

Conclusion

The Understandable principle closes the "human" part of POUR: declared language, predictable and consistent behavior, and error handling that prevents, identifies, and suggests corrections. With Perceivable, Operable, and Understandable we cover what the person directly needs. What remains is the technical foundation that holds up everything else: that the code be robust, that assistive technologies interpret it reliably today and tomorrow. That is the fourth principle, and in lesson 03-04 Robust we will see what the accessibility tree requires so a custom component truly exists for Marta and her NVDA.

◄ Previous
◄
Next ►
►
The Project | About Us | Contribute | Donations | License
© Copyright 2026. All rights reserved