Perceivable (In Depth)

Perceivable is the first of the four POUR principles, and it's probably the most intuitive: if a user can't perceive your content, they can't use it. The web delivers information through a mix of text, images, audio, and video. Not everyone can access all of those channels. If information only exists in one form, users who can't access that form are locked out.

The fix for this isn't "make everything work for everyone in every way." It's "don't lock information behind a single channel without a path to an alternative."

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 — Perceivable has every criterion with context and examples.

---

Guideline 1.1 — Text Alternatives

Every non-text element needs a text alternative that serves the same purpose. This is where alt text lives.

The reason is simple: if someone cannot perceive visible content, they typically use a screen reader. Screen readers read text content. They can't interpret an image, a chart, a button with only an icon, or a CAPTCHA without a text equivalent. When you write alt text, you're giving those tools something to work with.

What good alt text looks like depends on what the image is for. A photo that's purely decorative gets an empty alt attribute (alt="") — that signals to assistive tech to skip it. An image that conveys information needs alt text that conveys that same information. A chart needs a text summary of its data. An icon button needs a text label for what it does, not what it looks like.

There's a separate standard for complex images — graphs, diagrams, infographics — where alt text alone may not be sufficient. Long descriptions and data tables are the usual solutions.

Need help telling if your image needs alt text? WAI made an alt Decision Tree guide to figuring out what kind of alt text an image needs.

This guideline also covers non-text form inputs, CAPTCHAs (which need an audio alternative or an alternate method), and any content that's text-like but delivered as an image. If it communicates something, it needs a text equivalent.

---

Guideline 1.2 — Time-based Media

"Time-based media" refers to audio and video content. The specific requirements you need to pay attention to here depend on what kind of content you have and whether it's live or prerecorded.

If a video is purely decorative or doesn't communicate any information beyond what's in the surrounding text, the requirements are lighter. But if you're demonstrating anything meaningful through a video, assume someone watching it can't hear it, and someone listening to it can't see it.

Pre-recorded content

• For prerecorded audio (like a podcast), you need a text transcript.
• For prerecorded video with audio (like a video lecture), you need captions.
• For prerecorded video without audio (like a silent how-to), you need an audio description track — narration that describes what's happening visually.

Extended audio description tracks on videos with other audio are a AAA requirement. They are fantastic but often involve pausing the video to fit longer narration. An experienced professional is often needed to do them well. However, you can make your own video's audio more useful even without a description track if you are recording a video yourself. If you know a visual component is important, imagine your user is listening to the audio only and describe what you are doing or displaying as it shows on screen.

If you are using someone else's video and it lacks captions (or the captions are really bad), consider making and including a transcript beside the video. That will meaningfully reduce the barrier to access for the video, even if it doesn't technically satisfy 1.2.2.

Live content

Live audio and video have their own requirements, though they're a little lighter. Live audio that's synchronized with visual presentation needs real-time captions, but the bar for those is lower than for prerecorded captions (since perfect accuracy in real time isn't realistic). Check your streaming software or platform for plugins that can help you add captions to your content.

---

Guideline 1.3 — Adaptable

Content needs to be presentable in different ways without losing information or structure. If a user strips away your visual presentation, does the structure and meaning survive?

Sighted users infer a lot from layout: a heading looks bigger, a list looks like a list, a table looks organized. Screen readers don't see that layout. They work from the HTML structure instead. For example: if your heading is just big bold text styled with CSS rather than an actual <h2>, a screen reader has no idea it's a heading and can't relay that information.

This guideline also covers the information conveyed by position, shape, or color alone. If you reference "the green button" or "the items in the left column" without any other identifier, users who can't perceive those visual cues are lost. Instructions need to work without those references.

A newer addition to this guideline addresses orientation: your content shouldn't be locked to a single screen orientation or size. Think about the experience going from a desktop computer to a mobile phone. Some people have their device oriented in a fixed position and can't rotate it to correct for layout issues. Portrait-only and landscape-only restrictions create real barriers for those users.^[1]

---

Guideline 1.4 — Distinguishable

Users need to be able to see and hear content clearly. This guideline handles contrast, color, audio control, text sizing, and a handful of specific visual presentation requirements.

Color contrast is the big one. Text needs to have enough contrast against its background to be readable. WCAG 2.2 sets specific ratios: for AA, you need 4.5:1 for "normal" text and 3:1 for large text (roughly 18pt or 14pt bold). Low-contrast text is one of the most common accessibility failures on the web, and also one of the easiest to check.

Need help testing color contrast? Try Contrast Checker (WebAIM) — paste in hex values to get the ratio and a pass/fail verdict.

Color isn't just a contrast issue — information can't be conveyed by color alone. If error fields are marked only by turning red, colorblind users may not get the signal. Pair color indicators with icons, labels, or other non-color cues.

There are several other requirements here worth knowing:

• Audio that plays automatically for more than 3 seconds needs to be stoppable, or have volume control independent of system volume. (People using screen readers need to be able to hear their reader over your content's audio.)
• Text needs to be resizable up to 200% without loss of content or functionality. Absolute font sizes set in pixels that don't scale are a common issue here.
• Images of text should be avoided where real text can do the same job. CSS is powerful. Don't bake text into images when you can layer it on top.
• A newer criterion, Reflow (1.4.10), requires that content can be viewed in a single column without horizontal scrolling at up to 320px width. This is about zoom support, not just mobile responsiveness, though the two often overlap.
• Text spacing (1.4.12) requires that content doesn't break when users override your letter spacing, line height, and paragraph spacing to something that works for them.

---

The throughline

The four guidelines here are covering the same underlying concern from different angles. Text alternatives, captions, semantic structure, contrast, resize support — all of these exist because information locked into a single modality or a specific visual presentation excludes people. Users are coming to your site with different bodies, different assistive tools, and different browser configurations. Perceivable is asking you to design for that variance instead of assuming a single way of receiving your content.

---

Going Deeper

• Perceivable — Understanding WCAG 2.2 — W3C's full explanations for every Perceivable criterion
• How to Meet WCAG — Perceivable — filterable checklist of criteria, techniques, and known failures
• An alt Decision Tree — WAI's guide to figuring out what kind of alt text (or no alt text) an image needs
• Contrast Checker (WebAIM) — paste in hex values, get the ratio and pass/fail verdict

---

Sources

1. W3C. "Understanding Success Criterion 1.3.4: Orientation." WCAG 2.2. https://www.w3.org/WAI/WCAG22/Understanding/orientation.html (accessed May 2026) ↩