WCAG Principles (POUR)

WCAG organizes accessibility requirements around four principles: content should be perceivable, operable, understandable, and robust. For a frontend engineer, POUR provides a high-level framework for identifying accessibility problems before choosing specific implementation techniques.

Perceivable means users must be able to obtain information through at least one available sensory channel. Common frontend concerns include text alternatives for meaningful images, captions for video, sufficient color contrast, and content that can be presented in different ways without losing meaning.

Operable means users can interact with controls and navigation. Interfaces should support keyboard operation, provide enough time for interactions when needed, avoid problematic flashing, and make navigation and focus behavior usable. A control that works only with a mouse is a common violation of this principle.

Understandable means both the information and the interface behavior should be predictable and comprehensible. Clear labels, useful error messages, consistent navigation, appropriate language declarations, and predictable changes help users complete tasks without unnecessary confusion.

Robust means content should work reliably across different user agents and assistive technologies. In frontend development, this strongly relates to semantic HTML, valid document structure, correct element states, and exposing controls and relationships through platform accessibility APIs.

POUR is a set of principles rather than a complete implementation checklist. Specific WCAG success criteria and techniques provide the detailed requirements and implementation guidance, so an engineer should use POUR to categorize an issue and then consult the applicable criterion.

Key points

• Perceivable: users can access information through available sensory modalities.
• Operable: users can navigate and control the interface, including with a keyboard.
• Understandable: content, controls, and behavior are clear and predictable.
• Robust: content interoperates with browsers, assistive technologies, and other user agents.
• POUR provides the conceptual structure; individual WCAG success criteria define specific requirements.

Interview questions

What does POUR stand for in WCAG?

POUR stands for Perceivable, Operable, Understandable, and Robust. These are the four principles that organize WCAG accessibility requirements. Perceivable concerns access to information, Operable concerns interaction and navigation, Understandable concerns clarity and predictability, and Robust concerns compatibility with user agents and assistive technologies.

How would you make a frontend component more operable?

I would first verify that all interactive functionality can be completed with a keyboard. I would use native controls where possible, ensure visible focus is available, and make focus movement predictable. I would also check that timing and motion do not prevent users from completing the interaction.

What does robust mean in practical frontend development?

Robustness means the interface exposes its structure and state in ways that browsers and assistive technologies can interpret reliably. Semantic HTML is a strong starting point because native elements carry established semantics and interaction behavior. For custom widgets, correctly implemented ARIA can supplement those semantics when necessary.

How would you distinguish perceivable from understandable?

Perceivable asks whether users can access the information at all through available presentation channels. Understandable asks whether users can comprehend the information and interface behavior once they can access it. For example, an image may need a text alternative to be perceivable to a screen-reader user, while a confusing form error message is primarily an understandability problem.

Why is semantic HTML important to WCAG's robust principle?

Semantic HTML gives browsers established information about the purpose and behavior of elements. Assistive technologies can use those platform semantics instead of depending on fragile, application-specific conventions. It also provides built-in keyboard behavior for many controls, reducing the amount of custom accessibility code required. Custom components can still be accessible, but they require the developer to reproduce the relevant semantics, states, and interaction behavior correctly.