Web Accessibility Principles
W3C logo
The Web Accessibility Initiative opens in a new window at the World Wide Web Consortium opens in a new window defines four key principles of accessible web content in the Web Content Accessibility Guidelines (WCAG) 2.1 opens in a new window. To be accessible, content must be Perceivable, Operable, Understandable, and Robust.
The first letters of these principles spell POUR, which can help you remember them. While WCAG 2.2 opens in a new window is the latest version with additional guidance, most organizations still base their accessibility practices on WCAG 2.1.
The 13 guidelines under the 4 principles are:
Perceivable:
Provide text alternatives for non-text content.
Provide captions and other alternatives for multimedia.
Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
Make it easier for users to see and hear content.
Operable:
Make all functionality available from a keyboard.
Give users enough time to read and use content.
Do not use content that causes seizures or physical reactions.
Help users navigate and find content.
Make it easier to use inputs other than a keyboard.
Understandable:
Make text readable and understandable.
Make content appear and operate in predictable ways.
Help users avoid and correct mistakes.
Robust:
Maximize compatibility with current and future user tools.
Learning Goals of This Section
To prepare for the web accessibility portion of the exam, be sure you can:
Name the four main principles of web accessibility.
Describe how each principle is applied to web design and development.
In This Section:
Perceivable
Operable
Understandable
Robust
Perceivable
Defining Perceivability
Perceivability is about making the output of web content available through multiple sensory modalities.
Biological Pathways to Perception
For web content to be accessible, it must be perceivable through at least one of your biological senses. As a reminder, these are the five senses:
Sight
Sound
Touch
Taste
Smell
Of these, web accessibility primarily focuses on the first three: sight, sound, and touch. While someday someone might find a way to taste or smell the web, for now we don’t need to worry about the flavor or scent of our pages.
Seeing Web Content
Most people perceive web pages visually. The eyes capture information, which the brain then interprets. This works well for those with good vision, but not for everyone. Many web developers and designers are young and able-bodied, so they naturally create content that works for people like themselves. As a result, alternative ways to perceive content are often overlooked in web design.
Hearing Web Content
People who are partially or completely blind need alternative ways to access web content. For most, sound is the most effective method. Screen reader software converts text into synthesized speech, allowing blind users to listen to web content. Listening is a different experience from looking, like hearing someone describe an event instead of watching it. But “different” doesn’t mean worse. For people who are blind, listening is a natural and effective way to navigate the web.
Feeling Web Content
For people who cannot see or hear well enough to access web content, touch provides another option. Digital text can be converted into braille, allowing users to feel the content with their hands. Traditional braille is printed on raised dots, while modern refreshable braille devices display one line of text at a time, letting users read digitally without paper. The software that converts text to braille works much like a screen reader, offering nearly identical functionality, but through touch instead of sound. For individuals who are both deaf and blind, tactile output is the only way to access web content.
Why Perceivability Matters
If you can’t perceive web content, it might as well not exist.
For users who are blind, all visual information (images, animations, color, background, layout, and visual positioning) is inaccessible unless a digital text alternative is provided so screen readers can convert it to speech or braille. The same principle applies, to varying degrees, for users with low vision or color blindness.
For users who are deaf or hard of hearing, audio content is inaccessible. Multimedia content, such as video with sound, is significantly less usable unless a text alternative is available in the form of captions or a transcript.
The good news is that you don’t have to cure blindness or deafness to make images or sounds accessible to people with sensory disabilities. You just have to provide an acceptable alternative that works for their available sensory modalities. To make an image accessible, provide a digital text description. Screen readers can convert this text description into speech or braille to make it available by sound or touch. To make an audio recording accessible, provide a digital text transcript that deaf people can see with their eyes, and that people who are both deaf and blind can feel with their fingers when it is converted into braille. Web accessibility can get more complicated than these simple examples, but the principles are still the same. Everything has to be perceivable to be at all useful.
The Universal Format: Digital Text
Digital text addresses the perceivability barrier for people who are blind, deaf, or both. It is the most universally accessible format because it can be converted into other sensory formats, including speech and braille. Keep this in mind as you study web accessibility.
Most digital text is visible on the screen, making basic perceivability easy to assess. If text is visible (and it is real text, not an image of text), screen readers can generally access it. This is a simplification, as other factors can interfere, but it’s a reliable starting point for typical web content.
However, not all digital text needs to be visible. For example, sighted users can see images and typically do not need a written description displayed on the page. In these cases, the appropriate approach is to provide a text alternative for screen reader users while keeping it hidden visually. In HTML, this is done by placing the description in the alt attribute of the img element. Sighted users do not see this text, but screen readers announce it to blind users.
Similarly, users who can hear may not need captions displayed at all times or full transcripts embedded directly in the page. It is often appropriate to allow users to toggle captions on or off and to provide a link to a transcript rather than displaying it inline.
That said, making text alternatives, captions, or transcripts visible to everyone is also acceptable. Accessibility guidelines do not prohibit universal visibility; the key is ensuring equivalent access.
Making Dynamic Content Perceivable
Think about how interactive today’s websites are. You click something, and something changes — sections expand, messages appear, content updates instantly. Web pages don’t just sit there like pages in a book.
Dynamic interactions can be made accessible through digital text and ARIA (Accessible Rich Internet Applications) to communicate changes in state, for example, whether a tab is “expanded” or “collapsed.” ARIA is a way to add invisible labels and signals to a website so assistive technologies, like screen readers, can understand and announce what’s happening on the screen.
An ARIA live region can announce new content as it is inserted into the DOM (Document Object Model). This is essential. Blind users will not know when a tab expands or collapses unless the change of state is programmatically conveyed. Likewise, when new content, such as an error message or confirmation message, is injected into the page, screen reader users must be notified.
You can accomplish this by using an ARIA live region or by moving keyboard focus to the updated content so the screen reader announces it. Either technique can be appropriate, depending on the context and overall interface behavior.
Note: The CPACC exam doesn’t focus on technical subjects like ARIA and DOM, but it’s good to be familiar with these accessibility terms in general.
Make Sure Users Know What’s on the Web Page
Perceivability starts with awareness: users can’t access content they don’t know exists. Make sure everything on the page (content and functionality) is available through sight, sound, and touch. Digital text, whether visible or hidden using proper accessibility techniques, is the most universal way to ensure broad perceivability.
Operable
Defining Operability: A Declaration of (Device) Independence
Operability is about making the input methods of web content functionally available to a wide range of input devices, including:
mouse or touchpad
keyboard
touchscreen
voice recognition software
other specialized input devices (most of which emulate the keyboard or mouse)
Everyone Uses Technology Differently
Some people navigate the web with a mouse or touchpad, but these tools require fine motor control and aren’t accessible to everyone. Likewise, not everyone can use a keyboard. Some rely on assistive devices that track eye movement, detect small muscle gestures, or interpret speech commands.
a student with no hands, studying on his laptop with a concentrated facial expression
Everything Has to Work
Operability ensures that every web component functions, no matter how someone interacts with it. Navigation, dynamic elements, and interactive features must all be usable with any input device. If a feature can’t be accessed through a user’s device, it’s effectively broken for them, even if it works for others.
Navigating Web Components: In, Within, Through, and Out
Web components must be fully operable with any input device. Users need to be able to navigate into a component, use the features within it, move through it, and navigate out again. If any of these steps fail for a particular device, some users can’t access the component at all.
For example:
Keyboard users must be able to open a drop-down menu, select a link inside, and move past it without a mouse.
Keyboard users must also be able to navigate into a video player, operate all controls (play, pause, volume, captions, full screen, and others) and exit the player without a mouse.
Touchscreen users must be able to trigger functionality that normally responds to mouse hover, even though touchscreens don’t have a hover state.
Scripting for Device Independence
Basic web content, like standard links and forms, usually works on any device without extra effort. Click a link, fill out a form, and it just works.
Things get more complicated when you add interactive features, like menus that open and close, slideshows, or custom buttons. These features often rely on scripts (small pieces of code) to work. Scripts give you a lot of flexibility (you can create custom behaviors or new components), but they also create a risk: if not designed carefully, your feature might only work with a mouse or touch, leaving some users unable to use it.
To avoid problems, use device-independent actions whenever possible. For example, actions triggered when a component is focused, selected, or blurred usually work across keyboards, touchscreens, and other devices. Sometimes you may need to provide multiple ways to do the same thing, like one action for a mouse click and another for a keyboard press. And always test on different devices, including touchscreens, to make sure it works for everyone.
A group of people working in a communal space, each of them on a different device - laptop, smartphone, desktop, and tablet.
Control the Focus
When building interactive features, it’s important to control where the user’s focus goes. Focus is essentially what element is “active” on the page and ready to receive input, usually highlighted by a glowing or dotted outline.
For example, if a popup dialog appears, the focus should automatically move into that dialog. When the user closes it, the focus should return to where it was before. Losing focus can be frustrating: if it jumps to the top of the page, the user has to navigate back to their previous spot, wasting time and effort.
G-mail sign in page, with the Forgot Email button outlined in a glowing blue outline
Timing
Users also need enough time to interact with content. Some tasks, like filling out a detailed form for a mortgage, college application, or taxes, can take a long time. You wouldn’t want a session to automatically expire in the middle, risking the loss of all the information a user has entered.
Session timeouts are fine, as long as users get clear, accessible warnings, like a popup notification, that they have time to save or finish their work. Make sure the notification itself is easy to access and navigate. Users should be able to enter it, interact with it, and exit it smoothly.
Keyboards: The (Almost) Universal Input Device
Making web content keyboard-accessible gets you close to universal operability. Keyboards are widely used by people with and without disabilities, including those who are blind, have low vision, or have motor disabilities. If you can’t reliably use a mouse or see a pointer on the screen, the keyboard becomes essential.
Many assistive technologies also rely on keyboard commands. Onscreen keyboards, alternative keyboards, switch devices, eye-tracking systems, and other tools often translate user input into keystrokes to move through content and activate controls. When a site works well with a keyboard, it typically works well with these technologies too.
That said, keyboard access doesn’t replace mouse or touch support. Content should still work with a mouse, touchscreen, or other input method. The point isn’t to prioritize one device over another; it’s that strong keyboard support usually creates a solid foundation for broad accessibility. If something works smoothly with both a keyboard and a mouse, it’s likely to work with most other input technologies as well, with only rare exceptions.
Understandable
Defining Understandability
Understandability is about making content and interfaces that people can comprehend.
Understandable Content
Specify the Language
Screen readers turn digital text into speech or braille so users can access web content. For this to work correctly, the page’s language needs to be specified in the code.
If no language is defined, the screen reader uses the language set in the user’s preferences. That may work in some cases, but for people who move between websites in different languages, it creates problems. The screen reader won’t automatically switch pronunciation rules unless the page clearly identifies the language. When the wrong language is applied, the result can be confusing or impossible to understand.
Developers can prevent this simply by declaring the page’s primary language. It’s also possible to identify specific words or passages that use a different language, so they’re pronounced correctly as well.
A woman typing. Next to her is a container with small flags of different countries.
Simplify the Reading Level
Reading can be challenging for many people, including those with reading disabilities. Writing more clearly and simply takes effort, but it makes content easier for everyone to understand.
Challenging content includes:
Long or unfamiliar words
Long sentences
Complicated sentence structure
Vague or unclear wording
Dense blocks of text (break content into headings, short paragraphs, and lists)
Lines that are spaced too closely together (add adequate spacing for readability)
Avoid Unfamiliar or Complex Terms
Technical jargon, slang, or culturally specific words can confuse many readers. Without the right background or experience, people may misunderstand or miss the meaning entirely. Some people with cognitive disabilities find complex ideas and abstract concepts especially hard to follow. The simpler and clearer the content, the more accessible it becomes for everyone.
Provide Supplemental Formats
Some people can’t read at all, so simplifying the words isn’t enough. For these users, offering alternative formats, like images, audio, or video, helps make the content understandable. These alternatives should be clear, direct, and as simple as possible.
Creating every possible alternative for all content can be a lot of work. For most general audiences, it isn’t required by accessibility guidelines, and it may be unrealistic for many organizations. But the principle is important: providing supplemental formats can help people with different learning styles or cognitive needs.
People process information in different ways:
Verbal learners often understand text best.
Visual learners benefit from pictures, diagrams, or videos.
Auditory learners gain most from audio or multimedia presentations.
Even offering a few alternative formats can make content more accessible and easier to understand for a wider range of users.
A healthy eating guide represented in text, image, and audio formats.
Understandable Interfaces and Interactivity
Consistency and Predictability
Websites should feel familiar and predictable across pages or views. Layouts, reading order, and navigation should stay consistent so users know what to expect. Main navigation links should generally remain the same, and link text should be clear and consistent.
Form fields, custom controls, and interactive widgets should work in familiar ways, following standard conventions. Creating completely new interaction patterns is usually risky (unless there’s a strong reason or it’s experimental) because users may struggle to figure out how to use them. If you do try something new, provide clear instructions so people can understand the interaction.
Assistance: Error Prevention and Correction
Provide Instructions, Hints, and Contextual Help
When asking for user input, it’s helpful to give instructions at the start, like at the top of a form, explaining what the user is doing and what’s expected.
If a field has special requirements, make them visible and accessible to everyone, including screen reader users. Examples of common constraints include:
The field is required
A button or field is read-only or disabled
Data must follow a specific format
Passwords must meet rules, such as a minimum length, including numbers, letters, uppercase letters, or special characters
Input cannot exceed a certain number of characters
Clear instructions and guidance help users complete forms successfully and reduce errors.
Provide Feedback with Confirmation and Error Messages
When a user submits a form or interacts with a component that sends data to a server, provide clear feedback that the action happened and whether it was successful.
Make sure confirmation and error messages are accessible to everyone, including screen reader users. In most cases, the message should be announced immediately so users don’t have to search for it or navigate through other content. This can be done by moving the focus to the message or placing it in an alert dialog.
Robust
Defining Robustness
Robustness is about ensuring compatibility with a broad range of user agents, including assistive technologies.
Different browsers and devices handle web content in different ways. Behavior can vary across platforms like Windows, Mac, iOS, Android, or Linux, and even between different versions of the same browser. Screen readers also vary by version, with newer ones supporting technologies like ARIA better than older versions. Because there are so many combinations of browsers, devices, and assistive technologies, it’s impossible to support them all. You need to set practical limits, such as supporting a browser only back to a certain version, or decide not to support a browser that has a very small user base or lacks the features needed for good accessibility.
Multiple devices show the same webpage, connected with icons for screen reader, braille, keyboard, and visual accessibility tools
Use Standard Markup
One of the best ways to make your web content robust across different browsers and devices is to use standard, valid markup. You can check your code with validators: HTML (W3C HTML validator opens in a new window), CSS (W3C CSS validator opens in a new window), and JavaScript (tools like JSLint opens in a new window).
Valid markup doesn’t automatically make a site accessible, and accessibility doesn’t always require perfectly valid code. Still, using valid code reduces the chance of errors that cause problems in different browsers or assistive technologies, making it easier to identify and fix potential accessibility issues.
Use ARIA (or Other Means) to Indicate the Name, Role, and Value of Interactive Components
Early web pages were mostly static, with little interactivity. Today, websites are often highly dynamic, using scripts and custom widgets to create interactive features and live updates.
This interactivity requires careful markup so that assistive technologies can understand what’s happening. For example, screen reader users need to know if an item is expandable and whether it’s currently open or closed, or which tab is selected. These states must be updated in real time as users interact with the page.
ARIA opens in a new window (Accessible Rich Internet Applications) provides tools to communicate these dynamic changes effectively. Learning and applying ARIA is essential for making modern interactive content accessible.