Understandable and Robust — WCAG Principles 3 and 4

Why it matters

Perceivable content and operable controls are necessary but not sufficient if the user cannot understand what is presented or what actions to take. And even comprehensible, operable content fails if the underlying code cannot be reliably interpreted by assistive technologies. Principles 3 and 4 address these higher-level requirements. (BoK p. 40)

Principle 3: Understandable

Guideline 3.1: Readable

Text content must be readable and understandable. The primary technical requirement is that the language of each page is programmatically determinable — enabling screen readers to apply the correct pronunciation rules and text-to-speech voices. Where passages in a different language appear within a page, the language of that passage must also be declared. (BoK p. 40)

Readability also encompasses the level of reading comprehension required. At Level AAA, content should be supplemented with simpler explanations when it requires a reading level above lower secondary education.

Guideline 3.2: Predictable

Pages and components must behave consistently and predictably. Users — especially those with cognitive disabilities, low vision, or who use screen readers — rely on consistent, anticipated behavior: (BoK p. 40)

• Receiving focus on a component must not trigger an automatic context change (navigating away, submitting a form, launching a popup) without warning.
• Changing a setting must not cause an automatic context change unless the user is warned in advance.
• Navigation across pages must be consistent — repeated nav menus must appear in the same location and in the same order.

Guideline 3.3: Input assistance

Forms must help users avoid and recover from errors: (BoK p. 40)

• If an error is detected, the field in error must be identified and the error described in text.
• If a field has a specific required format, it must be labeled or described before the user submits.
• For legal, financial, or data-deletion actions, users must be able to check, correct, or reverse their submission.

Error messages that only use color, only use an icon, or only say “Invalid input” without naming the field or explaining the fix are Understandable failures.

Principle 4: Robust

Guideline 4.1: Compatible

Content must be compatible with current and future user agents, including assistive technologies. The primary success criterion is: (BoK p. 40)

4.1.2 Name, Role, Value (Level A): For all UI components, the name (what it is called), role (what type of component it is), and value (its current state) must be programmatically determinable, and changes to these must be notified to AT. This enables screen readers to tell users “Submit button,” “checkbox, checked,” or “dialog, expanded” — rather than just reading unlabeled text.

4.1.3 Status Messages (Level AA, added in WCAG 2.1): Status messages (e.g., “Your form was submitted successfully,” “3 items added to cart”) must be programmatically determinable so AT can convey them to users who do not see the page change.

Real-world example

An insurance portal has several Understandable and Robust failures. The form for submitting a claim uses a dropdown that changes the page entirely when focused (3.2 violation — unexpected context change). Error messages after submission say only “Please correct the highlighted fields” with red highlighting but no field names (3.3 violation). A custom accordion widget built with <div> elements has no role, name, or aria-expanded attribute, so screen readers cannot determine it is a button or whether it is expanded (4.1.2 violation). Each violation is in a different principle but all contribute to a form that users with disabilities cannot reliably use.