The Four Principles of WCAG: What POUR Means in Plain Language
By Kalin Schoephoerster | KShep Creative
This is the fourth post in a six-part series on WCAG for K–12 districts. Previous posts cover what WCAG is →, what the conformance levels mean →, and the difference between WCAG 2.1 and 2.2 →.
WCAG 2.2 has 87 success criteria. Encountered as a list, that number can feel overwhelming — especially for district leaders who aren't web developers and didn't sign up to become accessibility specialists.
But those 87 criteria aren't a random collection of requirements. They're organized around four core principles that reflect how people actually experience digital content. Understanding those principles makes the individual criteria easier to navigate and helps districts see the logic behind the standard rather than just a checklist to get through.
The four principles form the acronym POUR: Perceivable, Operable, Understandable, and Robust. Every WCAG success criterion maps to one of these four principles. Once you understand what each one means, you have a framework for thinking about accessibility that applies beyond any specific criterion or version — and that's useful whether you're reviewing a new piece of content, evaluating a vendor, or trying to prioritize a backlog of remediation work.
Perceivable: can everyone access the information?
Perceivable means that information and content must be presented in ways that users can perceive — regardless of their sensory abilities. Content that can only be accessed one way creates barriers for users who can't access it that way.
The core question for this principle: if a user can't see, hear, or process content in its default format, is there an alternative?
Some examples that K–12 district leaders will recognize:
An image on the district website with no alt text is not perceivable to a screen reader user. The image simply doesn't exist for them — there's no information, no context, nothing. A video without captions is not perceivable to a staff member who is Deaf or hard of hearing. A PDF created by scanning a physical document has no text layer, which means assistive technology can't read it at all. A chart that uses red and green to indicate status, with no text labels, is not perceivable to someone with color blindness.
The fix in each case isn't to remove the image, the video, or the color. It's to provide an alternative that serves the same purpose. Alt text. Captions. A real text layer. Labels alongside the colors. Perceivability is about redundancy: making sure information is available through more than one channel so that no single sensory barrier cuts a user off entirely.
For more on accessible document design specifically, see PDF Accessibility for K–12 Districts →.
Operable: can everyone navigate and interact?
Operable means that users must be able to navigate and interact with content — regardless of how they're accessing it. Not everyone uses a mouse. Not everyone uses a touchscreen. Not everyone can complete a task under time pressure.
The core question for this principle: if a user can't use a mouse or needs more time, can they still do everything the content requires?
Some examples that K–12 district leaders will recognize:
A registration form that can only be completed with a mouse is not operable for a staff member who navigates by keyboard. A slideshow that automatically advances and can't be paused is not operable for someone who needs more time to read each slide. A link that says "click here" with no surrounding context is not operable for a screen reader user navigating by links — they hear "click here" with no indication of where the link goes. A dropdown menu that disappears when a user moves their cursor slightly off target is not operable for someone with limited motor control.
Operability is about ensuring that every function — every form, every navigation element, every interactive component — works for users who engage with digital content differently than the person who designed it assumed. The mouse is not a universal input device, and designing as if it is excludes a meaningful portion of users.
Understandable: can everyone make sense of it?
Understandable means that both the content and the way it works must be clear and predictable. Even if a user can perceive the content and operate the interface, they still need to be able to make sense of what they're encountering.
The core question for this principle: even if a user can access and interact with the content, can they actually understand it?
Some examples that K–12 district leaders will recognize:
A form that uses technical jargon without explanation is not understandable for a family navigating the enrollment process for the first time. An error message that says "invalid input" without identifying what was wrong or how to fix it leaves the user stuck. A website where the navigation menu is organized differently on every page is not understandable — users can't build a reliable mental model of how it works. Instructions that say "use the button on the right" without naming or describing the button are not understandable for someone using a screen reader who can't see which button is on the right.
Understandability is about respecting cognitive diversity. Plain language, consistent navigation, helpful error messages, and clear instructions don't just benefit users with cognitive disabilities — they make content better for everyone who encounters it. This is also where WCAG and Universal Design for Learning overlap most directly: both frameworks call for content that works across a range of learners and users without requiring special accommodations after the fact. For more on that connection, see What Is UDL — And What Does It Have to Do With K–12 Staff Training? →.
Robust: does it work with the technology people actually use?
Robust means that content must be built in a way that can be reliably interpreted by a wide variety of assistive technologies — now and as those technologies evolve.
The core question for this principle: is the content built on solid enough technical foundations that screen readers, voice control software, and other assistive tools can understand and communicate it correctly?
Some examples that K–12 district leaders will recognize:
A form built with non-standard HTML that a screen reader can't interpret correctly is not robust — the user may be unable to tell what the form field is asking for or whether they've filled it in correctly. A custom interactive element that looks like a button but has no underlying accessibility metadata is not robust — assistive technology can't identify what it is, what it does, or how to activate it. A website that works perfectly in a standard browser but breaks when accessed through a screen reader is not robust.
Robustness is the most technical of the four principles, but the practical implication for districts is straightforward. Content should be built using standard, well-structured code and tested with real assistive technology — not just visually reviewed in a browser. Automated accessibility scanners catch some robustness issues, but many require manual testing to surface. This is one of the key reasons an automated scan alone isn't sufficient for a genuine accessibility evaluation.
Why POUR matters beyond the individual criteria
POUR's value isn't just organizational. It gives districts a framework for thinking about accessibility that applies even when they don't know the specific WCAG criterion number.
When reviewing a new page, document, or video before it goes live, a staff member who understands POUR can ask four questions: can everyone perceive this? Can everyone interact with it? Can everyone understand it? Will it work with assistive technology? Those four questions surface most accessibility problems before they become compliance issues — and they don't require technical expertise to ask.
POUR also helps districts make sense of audit findings. When an accessibility audit returns a long list of issues, the list can feel unmanageable without a way to think about what matters most. Knowing which principle a failure maps to helps teams understand its impact. A Perceivable failure often means content is completely invisible to some users. An Operable failure may mean a required task is impossible to complete. An Understandable failure may mean a family can't successfully navigate an enrollment process. That context shapes how a district prioritizes remediation work.
An accessibility audit organized around POUR principles gives districts a structured way to understand not just what's broken, but why it matters and where to focus first. Learn more about accessibility audits →
What comes next
The next post in this series brings everything together — what WCAG compliance actually requires of K–12 districts in practice, what the compliance timeline looks like, and the most common misconceptions that get in the way of making progress.
[What WCAG Compliance Actually Requires of K–12 Districts → coming soon]
POUR turns a standard into a way of thinking
Knowing that WCAG has 87 criteria is useful. Understanding that those criteria are organized around four human-centered principles — can people perceive it, operate it, understand it, and rely on it — is what makes the standard navigable.
POUR doesn't replace the specific criteria. It gives you a way to think about accessibility that goes beyond any individual requirement and applies to every piece of digital content your district creates or publishes.
If you're ready to understand how your district's current content measures up against each of these four principles, that's exactly what an accessibility audit is designed to tell you.
Book a free 30-minute intro call →
Or explore accessibility audit and remediation services → to see what a WCAG evaluation looks like in practice.
Kalin Schoephoerster is a CPACC-certified instructional designer and accessibility consultant based in St. Paul, MN. KShep Creative partners with K–12 districts, higher education institutions, and EdTech organizations to develop accessible eLearning, instructor-led training, curriculum, SOPs, and website accessibility audits aligned with WCAG 2.2 and ADA Title II requirements.