WCAG basics – making your website perceivable, operable, understandable, and robust

WCAG basics – making your website perceivable, operable, understandable, and robust

WCAG is shorthand for the Web Content Accessibility Guidelines, and at its heart are four principles you can remember as POUR: perceivable, operable, understandable and robust. If you want a practical starting point in Spanish, this resource can be useful: https://estandaresyaccesibilidad.com/. These guidelines set expectations for how content should behave so people with a wide range of abilities can use the web more easily.

What the four principles actually mean

Each POUR principle frames accessibility from a different angle. Perceivable means users can sense the content through sight, hearing or touch; operable means users can navigate and interact regardless of input device; understandable asks that content and controls make sense; robust means content works across different agents and future technologies. Together these principles guide specific success criteria at three levels of conformance: A, AA and AAA. Most public-facing sites aim for AA as a realistic baseline.

Perceivable

Perceivable covers things like text alternatives for images, captions and transcripts for audio and video, sufficient color contrast, and flexible layouts that work with zoom and large text. In practice, that means adding alt attributes to informative images, providing captions for videos and avoiding color alone to convey meaning. It also means ensuring text can be resized and that content does not disappear or become unreadable at higher zoom levels.

Common, fixable issues

• Missing alt text on decorative and informative images.
• Videos without captions or transcripts.
• Low contrast between text and background.
• Content that relies solely on color to indicate state or error.

Operable

Operable focuses on interaction. A site must work with a keyboard, give users enough time for actions, avoid content that can cause seizures, and provide clear navigation. Keyboard accessibility is essential: all interactive controls must be reachable and usable without a mouse. Focus order should match visual order, and focus indicators must be visible so keyboard users know where they are.

Things to check

• Tab through your pages to ensure all links and buttons are reachable.
• Test modal dialogs and overlays for proper focus trapping and escape keys.
• Avoid automatic moves, like content that shifts while a user reads it.

Understandable

Understandable means content and operation are clear. Use plain language where possible, write predictable labels and provide instructions when forms ask for unusual input. Error messages should clearly explain what went wrong and how to fix it. Consistent navigation and layout across pages reduce cognitive load and help people with learning disabilities or limited short-term memory.

Practical tips

• Provide clear field labels and examples in forms.
• Prefer simple language and offer summaries for long pages.
• Keep interactive behavior consistent; avoid reusing the same control for different actions.

Robust

Robustness is about compatibility. Use semantic HTML so assistive technologies can interpret your markup. ARIA is powerful, but it should complement native elements rather than replace them. Validate your HTML and test in real assistive technologies like screen readers and voice input systems. Robust content degrades gracefully on older browsers and remains usable as technologies evolve.

Key robust practices

• Prefer semantic elements such as <button>, <nav>, and <header>.
• Use ARIA roles and properties only when native markup cannot provide the necessary semantics.
• Keep HTML valid and avoid nesting errors that confuse parsers.

How to get started: an approachable checklist

1. Run an automated scanner to find obvious issues, but treat results as a first pass, not a verdict.
2. Manually test keyboard navigation and screen reader basics on a few pages.
3. Fix high-impact items first: alt text, captions, keyboard operability, and contrast.
4. Use semantic HTML and refactor components so they expose correct roles.
5. Document accessibility features and include them in your QA process for future releases.

Common pitfalls and realistic expectations

Avoid thinking of accessibility as a one-time checklist. It is an ongoing design and development concern. Some issues, like cognitive accessibility or low-vision readability, require subjective judgment and user testing. Also, resist over-reliance on ARIA or automated tools: they help, but do not replace human testing with people who use assistive technologies.

WCAG provides a structured way to think about inclusion. By breaking work into perceivable, operable, understandable and robust, teams can prioritize fixes, measure progress and make the web more useful to more people. Small, steady improvements pay off: a clearer form label, visible focus indicators, or a captioned video can make a big difference.