What WCAG is for
The Web Content Accessibility Guidelines, or WCAG, provide a shared way to think about whether web content can be used by people with different disabilities. They are useful to anyone who writes, designs, builds or maintains a website. Instead of asking whether a site simply “looks accessible,” WCAG sets out testable requirements called success criteria.
Think of a community workshop registration page. A visitor might use a screen reader, enlarge the text, navigate with a keyboard or need captions for an introductory video. Accessibility is not one feature added at the end of the project. It depends on choices throughout the page, from headings and form labels to colour and error messages.
The four principles: perceivable, operable, understandable and robust
WCAG groups its guidance under four principles, often shortened to POUR. Perceivable means people need a way to take in the information. For example, a meaningful image needs a text alternative for someone who cannot see it, and spoken information in a video needs an accessible alternative such as captions. Text should also remain usable when enlarged.
Operable means people need a way to use the interface. A visitor should be able to reach and activate controls with a keyboard, see where keyboard focus is, and have enough opportunity to complete a task. On the workshop page, someone should be able to move through the form, choose an option and submit it without relying on a mouse.
Understandable means the content and controls should make sense. Clear instructions, descriptive labels and helpful error messages reduce guesswork. If a required email field is left blank, an error that identifies the field and explains what to fix is more useful than a message saying only “Invalid input.”
Robust means content should be built so a range of browsers and assistive technologies can interpret it. Using appropriate HTML elements for headings, buttons and form fields helps communicate what each part does. These principles work together: a button that is easy to see but cannot be reached with a keyboard is still a barrier.
What Levels A, AA and AAA mean
WCAG success criteria are assigned to three conformance levels. Level A covers foundational requirements. Level AA includes Level A and adds further requirements that address common barriers. Level AAA includes criteria from all three levels and represents the most demanding set. The levels are cumulative: meeting AA means meeting the applicable A and AA criteria, not choosing between them.
A level is not a score or a promise that every person will have the same experience. Some accessibility needs extend beyond what a checklist can capture. Level AAA is also not a practical blanket target for every kind of content; a site may still adopt individual AAA practices where they make sense. When someone says a page “meets WCAG,” it is worth asking which WCAG version and conformance level they mean.
How conformance applies to a real website
Conformance is assessed against the applicable success criteria for a specified WCAG version and level. It concerns full web pages, not just a few polished components. If the workshop form is accessible but its confirmation page is not, the visitor may still be unable to finish the registration process. Likewise, a third-party booking tool can create a barrier even when the surrounding page is carefully designed.
This is why a claim about conformance needs a clear scope. It should identify what was assessed rather than imply that every page and future update has been checked. Passing a test at one point also does not guarantee that new content will remain accessible. A replacement image without useful alternative text or a newly added control that traps keyboard focus can introduce a problem.
A practical way to begin
Start with a task visitors need to complete, such as finding the workshop details and registering. Follow that task using only a keyboard. Check whether the focus indicator is visible, the order makes sense and every control works. Then review the page at a larger text size and look for content that becomes hidden or difficult to read. These checks do not establish conformance, but they can reveal barriers quickly.
Next, examine the content itself. Use headings that describe each section, give links names that make sense out of context, and write text alternatives that convey an image’s purpose rather than merely naming its appearance. Check captions, form labels and error messages. Automated tools can help flag some issues, but human review is needed to judge meaning and test complete tasks.
Treat WCAG as a framework for ongoing decisions, not a one-time badge. Choose a version and target level, review the relevant success criteria, record what you find and fix barriers before adding more features. Returning to the same visitor tasks after each significant change helps keep accessibility connected to the people who use the site.
