Understandable (In Depth)

Understandable is the third POUR principle, and it shifts the focus from sensory access and physical operation of a site to comprehension. Even if a user can perceive all your content and operate all your controls, they're still stuck if the content is written in an undeclared language, the navigation changes unexpectedly, or error messages don't tell them what to fix.

Understandable is about the cognitive and communicative layer of accessibility: making sure content is readable, that interfaces behave predictably, and that when something goes wrong, users get useful help rather than a dead end.

A note on scope: this page covers the criteria most relevant to building a typical website. A handful of niche and AAA-only criteria aren't covered here — not because they don't matter, but because they apply to narrower situations or represent an aspirational bar rather than a baseline. If you want the full picture, W3C's Understanding WCAG 2.2 — Understandable has every criterion with context and examples.

Guideline 3.1 — Readable

Content needs to be readable and understandable. For WCAG purposes, this starts with something very specific and technical: the language of the page.

Language of Page (3.1.1) requires that the page's primary language is declared in the HTML. This is the lang attribute on the <html> element. Screen readers use this to determine which language pronunciation engine to use. Without it, the screen reader may try to pronounce English content with the wrong language's phonetic rules, and the output can be incomprehensible.[1]

lang="en" is the right attribute for English pages. If your content includes passages in other languages, Language of Parts (3.1.2, AA) requires that you mark those passages with their own lang attribute. For example: a Spanish quote embedded in an English page should have lang="es" so screen readers switch correctly.

Beyond language declaration, the higher-level criteria here (Level AAA) address reading level and unusual words. Those aren't AA requirements, but they're worth knowing: writing at a lower reading level and defining jargon improves comprehension for everyone. This isn't to say that websites whose audience is individuals already involved in a very technical field should "dumb down" their site language to work for everyone. But if your site is for everyone, using highly technical terms can be prohibitive to comprehension.

What success looks like

  • The primary language of the page is programmatically determined. (3.1.1 — Level A)
  • The language of passages or phrases that differ from the page language is identified. (3.1.2 — Level AA)

Guideline 3.2 — Predictable

Interfaces should behave the way users expect them to. This guideline targets two specific patterns where unexpected behavior tends to create real confusion.

On Focus (3.2.1): Focusing on a component shouldn't automatically trigger a context change. A context change here means something significant: a new window, form submission, a major shift in layout. If tabbing to a dropdown menu immediately submits a form or navigates to a new page — before the user has done anything — that's a surprise no one needed. This is separate from the component working; it's about not doing something drastic as a side effect of a user just moving focus there.

On Input (3.2.2): Changing the value of a UI component shouldn't automatically cause a context change unless the user has been informed that's going to happen. Custom <select> menus that navigate immediately on value change, or checkboxes that submit forms on click without a button — these patterns work fine if the behavior is disclosed, but they create disorientation when it's unexpected.

Consistent Navigation (3.2.3) and Consistent Identification (3.2.4) are both AA criteria about cross-page predictability. Navigation that appears in the same place on every page should stay in the same relative order. Components that do the same thing across pages should be labelled consistently. If "Search" is the label in one place and "Find" in another, that inconsistency can cause confusion. Consistent Help (3.2.6, A) applies the same concept to help mechanisms, such as contact info, a chat widget, or a support link. If that help mechanism appears across multiple pages, it should be in the same relative location on each, so the user knows where to find help when they need it.

What success looks like

  • Focus alone doesn't trigger a context change. (3.2.1 — Level A)
  • Changing a UI component's value doesn't trigger a context change without warning. (3.2.2 — Level A)
  • Repeated navigation components appear in the same order across pages. (3.2.3 — Level AA)
  • Components that do the same thing are identified consistently. (3.2.4 — Level AA)
  • Help mechanisms appear in the same relative location across pages. (3.2.6 — Level A, new in 2.2)

Guideline 3.3 — Input Assistance

This guideline is about error handling, specifically making it useful information rather than just present. When users make mistakes filling out forms or providing input, the interface should help them understand and correct those mistakes.

Error Identification (3.3.1): If an input error is detected automatically, the error needs to be described in text. "This field is required" is useful. A red border with no label is not. Someone using a screen reader would not see the color change and therefore may have no idea which field has a problem or what's wrong with it. Error text needs to be associated with the specific field that failed, not just announced in a generic banner.

Labels or Instructions (3.3.2): Form inputs need labels or instructions. Placeholder text is not a label; it disappears when users start typing and provides no context if they need to re-check what a field is asking for. Visible, persistent labels are the minimum. If a field has format requirements (like a date format), state them upfront rather than after the user submits.

Error Suggestion (3.3.3, AA): If an input error is detected and suggestions for correction are known, provide those suggestions. "Invalid date" is less helpful than "Enter a date in MM/DD/YYYY format." If there are valid options, say what they are. This doesn't apply when it would create a security risk (like confirming which part of a login is wrong), but it applies broadly to form validation.

Error Prevention (3.3.4, AA): For pages that cause legal or financial commitments, or delete data, at least one of three things should be true: the action is reversible, input is checked and the user can correct errors before submission, or the user has a chance to review and confirm before the action completes. You don't need all three — one is sufficient. But "an irreversible action with no review step" is the pattern this is guarding against.

Redundant Entry (3.3.7, A) requires that users aren't asked to enter the same information twice in the same session unless there's a good reason. If you already know someone's shipping address from step one, don't ask for it again on step three. Re-entering known information is frustrating and introduces risk of errors.

What success looks like

  • Input errors are identified and described in text. (3.3.1 — Level A)
  • Labels or instructions are provided for user input. (3.3.2 — Level A)
  • Suggestions for correcting input errors are provided when possible. (3.3.3 — Level AA)
  • Submissions that affect legal commitments or delete data are reversible, reviewable, or checkable. (3.3.4 — Level AA)
  • Users aren't asked to re-enter information they've already provided. (3.3.7 — Level A, new in 2.2)

The throughline

Perceivable and Operable handle whether users can access and interact with your content. Understandable handles whether those interactions make sense. Language, predictability, and error handling are all things that primarily affect people with cognitive disabilities, people using assistive technology, non-native language speakers, and honestly, anyone filling out a form on a bad day. These aren't edge cases; these guidelines help everyone regardless of situation.

A practical note: Understandable failures tend to show up in manual testing, not automated checks. They're often hard to catch by reading code. Tab through your own forms and see what happens. Bring someone unfamiliar with the site and watch where they get confused. A lot of what this guideline asks for comes down to communication and whether you've thought about your interface from an outside perspective.

Going Deeper

Sources

  1. W3C. "Understanding Success Criterion 3.1.1: Language of Page." WCAG 2.2. https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html (accessed May 2026) ↩