Understanding WCAG: The Foundation of Web Accessibility

What WCAG represents

WCAG is a collection of principles, guidelines, and testable success criteria for accessible web content. It addresses websites, web applications, documents delivered through the web, multimedia, and many of the interface components people use to complete digital tasks.

The guidelines account for a broad range of access needs associated with vision, hearing, mobility, speech, cognition, language, learning, and neurological differences. They also recognize that people may use the web through keyboards, screen readers, voice input, screen magnification, switch devices, captions, customized display settings, or combinations of technologies.

The framework is designed to be relatively independent of a particular browser, device, or programming language. That allows its central principles to remain useful even as individual technologies change.

WCAG does not prescribe one visual style or require every website to behave identically. Instead, it identifies outcomes that accessible content should support. Designers and developers can meet those outcomes in different ways, provided the result remains available to users.

Why accessibility standards exist

Websites can create barriers without intending to. A form field may lack a programmatic label. A menu may work with a mouse but not a keyboard. A video may communicate important information without captions. Low-contrast text may become unreadable when viewed in bright light or through a low-quality display.

Without shared standards, accessibility decisions can become inconsistent and difficult to evaluate. WCAG gives organizations a common vocabulary for identifying barriers, defining accessible outcomes, and testing whether those outcomes have been achieved.

Accessibility standards also help distribute responsibility across a project. Accessibility is not solely the work of a developer or a final quality assurance reviewer. It is affected by:

• content strategy and information architecture;
• visual and interaction design;
• HTML structure and application behavior;
• images, audio, video, and document formats;
• content management practices;
• testing methods and editorial maintenance.

When accessibility is considered from the beginning, many barriers can be avoided rather than repaired later.

A brief history of WCAG

The World Wide Web Consortium, commonly known as the W3C, published WCAG 1.0 in 1999. That early standard reflected the web technologies and publishing practices of its time.

WCAG 2.0, published in 2008, introduced a more technology-neutral structure organized around four foundational principles. Later WCAG 2.x releases extended that foundation with additional success criteria addressing areas such as mobile interaction, low vision, cognitive accessibility, and accessible authentication.

The WCAG 2.x series is designed so that later versions retain the requirements of earlier versions while adding new criteria. This supports continuity for organizations that have already built policies, testing methods, and procurement requirements around WCAG.

The W3C continues to develop accessibility guidance as the web evolves. The current standards and supporting documents are available through the W3C Web Accessibility Initiative.

The four POUR principles

WCAG is organized around four principles: Perceivable, Operable, Understandable, and Robust. Together, these principles are often abbreviated as POUR.

Perceivable

Information and interface components must be presented in ways users can perceive. Important content should not depend entirely on one sense or one method of presentation.

Examples include:

• providing useful text alternatives for meaningful images;
• adding captions to prerecorded video with speech;
• maintaining sufficient contrast between text and its background;
• allowing content to adapt when text is enlarged or the viewport changes;
• using structure that assistive technologies can identify programmatically.

Perceivable does not mean that every user must experience content in the same way. It means that important information remains available through an appropriate form.

Operable

Users must be able to operate controls, navigation, and interactive components. An interface that can only be used with precise mouse movements excludes people who rely on keyboards, voice commands, switches, or other input methods.

Operable experiences commonly include:

• complete keyboard access;
• a visible indication of keyboard focus;
• logical navigation and focus order;
• descriptive page titles and headings;
• alternatives to gestures that depend on complex movement;
• controls that do not impose unnecessary time limits.

Understandable

Content and controls should be understandable in both language and behavior. People benefit when navigation is consistent, instructions are clear, and forms explain errors in a usable way.

This principle includes practices such as:

• identifying the primary language of a page;
• using clear labels and instructions;
• making repeated navigation patterns consistent;
• helping users identify and correct input errors;
• avoiding unexpected changes when a control receives focus.

Understandability does not require oversimplifying every subject. Complex information can remain complex while being organized, labeled, and explained clearly.

Robust

Content should be built so that browsers and assistive technologies can interpret it reliably. Robustness depends on valid relationships, meaningful controls, appropriate names, and states that can be exposed programmatically.

Standards-based HTML is central to this principle. Native elements such as buttons, links, headings, lists, labels, and form controls already contain semantics that browsers and assistive technologies understand. Custom components require additional care to provide comparable meaning and behavior.

WCAG conformance levels

WCAG success criteria are assigned to three conformance levels: A, AA, and AAA. The levels describe groups of requirements; they should not be interpreted as simple quality scores.

Level A

Addresses foundational barriers that can prevent people from accessing or operating content.

Level AA

Adds requirements that address a wider range of common accessibility barriers. Level AA is frequently referenced in organizational policies, procurement standards, and legal or regulatory contexts.

Level AAA

Includes additional criteria that may improve access for particular users and contexts. Some Level AAA criteria cannot reasonably apply to every type of content, so WCAG does not recommend requiring AAA conformance as a general policy for an entire website.

Conformance is cumulative. A page conforming at Level AA must satisfy all applicable Level A and Level AA success criteria. Level AAA includes the requirements at all three levels.

Formal conformance also concerns complete pages and complete processes. For example, it is not enough for a shopping cart page to be accessible if an essential payment step cannot be completed with a keyboard.

Passing an automated scan does not establish WCAG conformance. Many requirements need human judgment, interaction testing, or evaluation with assistive technology.

Semantic HTML provides an accessibility foundation

HTML communicates more than visual presentation. Semantic elements describe the purpose and relationships of content so that browsers, search systems, and assistive technologies can interpret the page structure.

Useful semantic foundations include:

• one coherent heading hierarchy;
• real lists for grouped items;
• native links for navigation;
• native buttons for actions;
• labels associated with form controls;
• table headers for tabular data;
• landmarks such as <header>, <nav>, <main>, and <footer>;
• language attributes that identify the language of a document or passage.

A page can look organized visually while exposing little meaningful structure to assistive technology. Conversely, well-structured HTML creates a reliable foundation that can be styled in many different ways.

ARIA can supplement HTML when native elements cannot express the necessary role, state, or relationship. It should not be used to recreate behavior that native HTML already provides. The article Understanding ARIA: Accessible Rich Internet Applications explains this relationship in greater depth.

The browser converts HTML and related information into an accessibility representation used by assistive technology. Understanding the accessibility tree can help teams see why source structure, accessible names, roles, and states matter.

Assistive technologies and WCAG

Assistive technology helps people perceive, navigate, or operate digital content in ways suited to their needs. Examples include:

• screen readers that present text and interface information through synthesized speech or braille;
• screen magnification and visual customization software;
• speech recognition and voice control systems;
• switch devices and alternative keyboards;
• captioning, transcription, and hearing-support technologies;
• browser settings that modify type size, spacing, color, or contrast.

WCAG does not require authors to make every page work identically with every possible combination of browser and assistive technology. It does require accessible outcomes supported by the web technologies being used.

Testing with assistive technology is valuable, but it should be informed by real usage patterns. Briefly opening a screen reader does not reproduce the experience of an experienced screen reader user. Whenever possible, technical evaluation should be complemented by usability testing involving people with disabilities.

WCAG and Section 508

WCAG is a technical accessibility standard. Section 508 is part of United States federal law and applies to information and communication technology developed, procured, maintained, or used by federal agencies.

The revised Section 508 standards incorporate WCAG 2.0 Level A and Level AA success criteria and conformance requirements by reference for covered web and non-web electronic content. This relationship is one reason WCAG terminology appears frequently in government procurement and accessibility evaluations.

WCAG and Section 508 should not be treated as interchangeable. Their scope, legal authority, exceptions, and application differ. Section 508 compliance provides additional context for organizations working with federal accessibility requirements.

Other countries, states, industries, and organizations may reference different WCAG versions or impose additional obligations. WCAG conformance is valuable evidence of accessibility work, but it does not automatically resolve every legal question. Organizations needing legal interpretation should consult qualified counsel familiar with the relevant jurisdiction.

Accessibility and user experience reinforce one another

Accessibility is not identical to general usability, but the two disciplines overlap. Clear navigation, readable text, consistent controls, understandable error messages, and flexible layouts can support people across a wide range of circumstances.

Accessible practices may also help users who are:

• working with a small screen or enlarged text;
• watching video in a noisy or quiet environment;
• using a device with a damaged mouse or touchscreen;
• experiencing temporary injury or fatigue;
• reading in a second language;
• using a slow connection or older device;
• navigating in bright sunlight or low light.

These broader benefits should not obscure the central purpose of accessibility: removing barriers experienced by people with disabilities. They show why inclusive design often produces more adaptable systems rather than serving only a narrow edge case.

Accessibility also has a meaningful relationship with information architecture and technical SEO. Semantic headings, descriptive links, clear page titles, structured content, and resilient HTML can improve interpretation across multiple systems. However, accessibility and SEO are not substitutes for one another. A page may be easy for a search engine to crawl while remaining difficult or impossible for a person to use.

Common accessibility improvements

Accessibility work varies by website, but many projects benefit from several recurring improvements.

Use meaningful page structure

Organize content with headings, lists, landmarks, and other elements that reflect actual relationships. Do not select heading levels solely for their default visual size.

Provide text alternatives for images

Meaningful images need alternatives that communicate their purpose in context. Decorative images generally need a null alternative so assistive technologies can ignore them. More guidance is available in Accessible Images and Alternative Text.

Support keyboard interaction

All essential controls should be reachable and usable without a mouse. Focus should remain visible, move in a logical order, and return to an appropriate location after dialogs or temporary interfaces close.

Label forms clearly

Inputs need persistent, programmatically associated labels. Instructions should identify required formats before errors occur, and error messages should explain what needs correction.

Maintain readable contrast and flexible presentation

Text and meaningful graphical elements need sufficient contrast. Layouts should remain usable when users enlarge text, increase spacing, zoom the page, or view content at narrow widths.

Caption and describe multimedia

Video and audio may require captions, transcripts, or audio descriptions depending on the content and applicable success criteria. Automatically generated captions should be reviewed because errors can materially change meaning.

Give controls clear names

Links and buttons should communicate their destination or action. Repeated phrases such as “click here” provide little context, especially when users navigate through a list of links.

Avoid unnecessary motion and time pressure

People may need to pause movement, extend time limits, or avoid flashing content. Motion and timing should support the task rather than create an additional barrier.

A practical process for building accessibility into a website

Accessibility is most dependable when it is part of normal planning, design, development, publishing, and maintenance.

1. Define the applicable standard.
   Identify the WCAG version, conformance level, organizational policy, and legal requirements relevant to the project.
2. Start with accessible design patterns.
   Consider contrast, focus behavior, responsive reflow, input methods, error handling, and content hierarchy before development begins.
3. Use native HTML where possible.
   Native elements usually provide more reliable semantics and keyboard behavior than custom imitations.
4. Include accessibility in component requirements.
   Reusable menus, dialogs, accordions, forms, and other components should document their names, roles, states, keyboard behavior, and focus management.
5. Test during development.
   Early testing prevents inaccessible patterns from spreading through templates or component libraries.
6. Combine automated and manual evaluation.
   Automated tools can identify some code-level issues, while manual testing is needed for keyboard behavior, reading order, accessible names, instructions, and contextual meaning.
7. Include people with disabilities.
   User testing can reveal practical barriers that technical checks do not fully capture.
8. Document findings and decisions.
   Record the pages, components, browsers, assistive technologies, criteria, limitations, and remediation status covered by an evaluation.
9. Retest after changes.
   New content, design systems, plugins, and application features can introduce barriers into a previously reviewed website.

An accessibility statement, feedback method, and documented response process can also help organizations learn about barriers that were not found during testing. Feedback should lead to investigation and repair rather than functioning as a substitute for proactive accessibility work.

Common misconceptions about WCAG

“Accessibility is only for screen reader users”

Screen reader compatibility is important, but WCAG addresses many forms of access involving vision, hearing, movement, cognition, speech, language, and neurological differences.

“An automated scanner can certify a website”

Automated tools are useful for repeatable checks, but they cannot determine whether every alternative text description is meaningful, instructions are understandable, focus behavior is logical, or a complete task can be performed successfully.

“ARIA makes a website accessible”

ARIA communicates roles, names, properties, and states to assistive technology. It does not automatically provide keyboard behavior, visual focus, understandable instructions, or sound interaction design. Incorrect ARIA can make an interface less accessible.

“Accessibility can be added after launch”

Some barriers can be repaired later, but retrofitting may be expensive when inaccessible assumptions are embedded in templates, content models, design systems, or application architecture.

“WCAG conformance means every user will have the same experience”

Accessible experiences may be equivalent without being identical. A transcript, caption track, keyboard interaction, or text alternative may present information through a different form while preserving its purpose.

“Meeting WCAG once completes the work”

Websites change. Content editors, software updates, new components, and third-party integrations can introduce new barriers. Accessibility requires periodic review and ongoing responsibility.

Accessibility beyond compliance

Conformance provides a necessary shared baseline, but a technically conforming page can still be confusing, inefficient, or difficult to use. WCAG is strongest when combined with clear writing, inclusive research, thoughtful information architecture, and testing with users.

This distinction is not a reason to treat the success criteria as optional. It is a reminder that standards define important outcomes without describing every part of a good human experience.

A durable accessibility practice therefore asks two related questions:

• Does the content satisfy the applicable accessibility requirements?
• Can people understand and use it successfully in real conditions?

Holding both questions together helps prevent compliance work from becoming detached from the people it is intended to serve.

Frequently asked questions about WCAG

Who creates WCAG?

WCAG is developed through the World Wide Web Consortium’s Web Accessibility Initiative. Its development involves accessibility specialists, researchers, technology companies, disability organizations, government participants, and members of the public working through the W3C standards process.

Is WCAG legally required?

WCAG itself is a technical standard rather than a law. However, laws, regulations, contracts, procurement rules, and organizational policies may incorporate or reference a particular WCAG version and conformance level. The applicable obligation depends on the organization, jurisdiction, technology, and context.

What WCAG level should a website follow?

Level AA is a common target because it includes foundational Level A requirements and a broader set of Level AA protections. The correct target should be based on current legal requirements, contractual commitments, organizational policy, and user needs. Relevant Level AAA criteria can still be adopted even when full AAA conformance is not practical.

Can a WordPress website conform to WCAG?

WordPress can be used to build accessible websites, but conformance depends on the complete implementation. Themes, plugins, custom code, editorial practices, media, forms, and third-party services all affect the result. The content management system alone cannot guarantee conformance.

How often should accessibility be tested?

Testing should occur throughout design and development, before significant releases, and after meaningful changes. Periodic audits are also useful, especially for websites with frequent publishing, changing templates, or third-party integrations.