WCAG 2.0

The Web Content Accessibility Guidelines 2.0, commonly known as WCAG 2.0,
provide testable requirements for making websites and web applications more
accessible to people with disabilities.

WCAG 2.0 was published by the World Wide Web Consortium as a W3C
Recommendation on December 11, 2008. It established the structure that is
still used by later WCAG 2 versions: four accessibility principles,
guidelines, success criteria and three conformance levels.

WCAG 2.0 remains an existing accessibility standard. It has not been
cancelled by WCAG 2.1 or WCAG 2.2. However, organisations beginning new
accessibility work should generally use the latest WCAG version unless a
law, contract or procurement requirement specifically references WCAG 2.0.

What is WCAG 2.0?

WCAG 2.0 is a technology-neutral standard for making web content more
accessible to people with visual, auditory, physical, speech, cognitive,
language, learning and neurological disabilities.

Web content can include:

• Text and headings.
• Images and graphics.
• Audio and video.
• Forms.
• Navigation.
• Interactive components.
• Web applications.
• Code that defines structure, presentation and behaviour.

WCAG is intended for developers, designers, content authors, product teams,
quality-assurance teams, accessibility specialists, procurement teams and
organisations defining digital-accessibility requirements.

How WCAG 2.0 is organised

WCAG 2.0 contains several layers of guidance.

The success criteria are the normative requirements used for conformance.
Supporting techniques are valuable implementation guidance, but a specific
technique is not mandatory when another valid method satisfies the same
success criterion.

The four WCAG principles

The four principles are commonly abbreviated as POUR.

Principle 1: Perceivable

Users must be able to perceive the information presented on the page.
Important content cannot be available through only one sensory method.

Guideline 1.1: Text alternatives

Non-text content should have an appropriate text alternative so that its
purpose or meaning can be communicated in another form.

This may apply to:

• Informative images.
• Icons.
• Charts and diagrams.
• Image-based controls.
• CAPTCHA alternatives.
• Audio and video content.

Decorative images should normally be hidden from assistive technologies
rather than described unnecessarily.

Guideline 1.2: Time-based media

Audio and video content may require alternatives such as:

• Captions.
• Transcripts.
• Audio description.
• Media alternatives.
• Sign-language interpretation at higher conformance levels.

The applicable requirement depends on whether the content is prerecorded,
live, audio-only, video-only or synchronised multimedia.

Guideline 1.3: Adaptable

Information, structure and relationships should be available
programmatically so that content can be presented in different ways without
losing meaning.

Examples include:

• Using real headings rather than visually enlarged text.
• Associating form labels with their inputs.
• Marking table headers correctly.
• Using lists for groups of related items.
• Maintaining a meaningful reading sequence.
• Not relying only on shape, size, colour or visual location.

Guideline 1.4: Distinguishable

Users should be able to distinguish foreground content from its background.

Relevant requirements include:

• Not using colour as the only way to communicate information.
• Providing audio controls where sound plays automatically.
• Maintaining sufficient text contrast.
• Allowing text to be enlarged.
• Avoiding images of text where real text can be used.

Principle 2: Operable

Interface components and navigation must be operable by people using
different input methods and assistive technologies.

Guideline 2.1: Keyboard accessible

Website functionality should be operable through a keyboard interface,
except where the underlying function genuinely requires a path-dependent
input method.

Keyboard users must be able to:

• Reach links, buttons and form controls.
• Open and close menus.
• Operate dialogs.
• Submit forms.
• Move into and out of interactive components.
• Complete important user journeys without a mouse.

Keyboard focus must not become trapped inside a component.

Guideline 2.2: Enough time

Users may need additional time to read content, enter information or
complete a task.

Where time limits exist, users may need the ability to:

• Turn off the time limit.
• Adjust it.
• Extend it before it expires.
• Pause moving or automatically updating content.

Exceptions exist when timing is essential or required by a real-time event.

Guideline 2.3: Seizures

Content must not flash in a way that is known to cause seizures or serious
physical reactions.

Teams should review animation, video, advertisements and game-like content
for flashes that exceed the defined thresholds.

Guideline 2.4: Navigable

Users should be able to find content, understand where they are and move
through the interface efficiently.

Relevant requirements include:

• A mechanism to bypass repeated blocks.
• Meaningful page titles.
• Logical focus order.
• Descriptive link purpose.
• Multiple methods for locating pages.
• Clear headings and labels.
• Visible keyboard focus.

Read the practical guide to

ARIA and keyboard accessibility
.

Principle 3: Understandable

Users must be able to understand both the content and the operation of the
interface.

Guideline 3.1: Readable

The language of the page should be programmatically identified so assistive
technologies can pronounce and interpret content correctly.

At higher conformance levels, requirements also address:

• Language changes within a page.
• Unusual words.
• Abbreviations.
• Reading level.
• Pronunciation where meaning is ambiguous.

Guideline 3.2: Predictable

Websites should behave consistently and should not create unexpected
changes merely because an element receives focus or a user enters data.

Predictable experiences include:

• Consistent navigation across related pages.
• Consistent identification of repeated controls.
• No unexpected page change when a field receives focus.
• Advance warning when changing a setting will change the context.

Guideline 3.3: Input assistance

Users should receive help avoiding, identifying and correcting mistakes.

Accessible forms may require:

• Clear error identification.
• Visible and programmatically associated labels.
• Instructions where needed.
• Suggestions for correcting errors.
• Error prevention for legal, financial and data-related transactions.
• Review, confirmation or reversal before important submissions.

Principle 4: Robust

Content should be implemented so that browsers and assistive technologies
can interpret it reliably.

Guideline 4.1: Compatible

Interface elements must expose accurate information to assistive
technologies.

This includes:

• Valid relationships between elements.
• Unique identifiers where required.
• Programmatic names for controls.
• Accurate roles.
• Current states and values.
• Notification of changes that users need to understand.

Native HTML elements should be preferred when they provide the required
semantics and behaviour. ARIA does not automatically create keyboard
interaction or repair an incorrectly implemented component.

The 12 WCAG 2.0 guidelines

1. Provide text alternatives for non-text content.
2. Provide alternatives for time-based media.
3. Create content that can be presented in different ways.
4. Make content easier to see and hear.
5. Make all functionality available from a keyboard.
6. Give users enough time to read and use content.
7. Do not design content in a way known to cause seizures.
8. Help users navigate, find content and determine where they are.
9. Make text readable and understandable.
10. Make pages appear and operate predictably.
11. Help users avoid and correct mistakes.
12. Maximise compatibility with user agents and assistive technologies.

WCAG 2.0 conformance levels

A claim of Level AA conformance requires all applicable Level A and Level AA
success criteria to be satisfied.

W3C does not recommend requiring Level AAA conformance as a general policy
for complete websites because some content cannot satisfy every Level AAA
criterion.

What is required for WCAG conformance?

Passing selected automated tests is not sufficient to claim WCAG
conformance.

WCAG 2.0 includes five conformance requirements.

1. Conformance level

All success criteria at the claimed level and all lower levels must be
satisfied.

2. Full pages

Conformance applies to complete web pages. A page does not conform when only
selected sections or components pass.

3. Complete processes

When a web page is part of a process, all pages required to complete that
process must conform at the claimed level.

Examples include:

• Account registration.
• Checkout and payment.
• Booking.
• Job applications.
• Submitting a government form.
• Password recovery.

4. Accessibility-supported technologies

Technologies relied upon to meet WCAG must work with the browsers,
assistive technologies and user agents available to the intended audience.

5. Non-interference

Content that does not conform must not prevent users from accessing the rest
of the page.

This requirement is particularly relevant to keyboard traps, flashing
content, automatic audio and content that interferes with pausing or
navigation.

What should a conformance claim contain?

A WCAG conformance claim is optional, but when one is made it should identify:

• The date of the claim.
• The WCAG version used.
• The conformance level achieved.
• The exact pages or scope covered.
• The web technologies relied upon.

A general statement that a website is “ADA compliant” or “WCAG certified”
should not replace a clearly scoped and evidence-based assessment.

Common WCAG 2.0 accessibility barriers

• Images without appropriate alternative text.
• Videos without captions.
• Headings used only for visual styling.
• Insufficient text contrast.
• Links identified only through colour.
• Forms without labels.
• Error messages that do not identify the affected field.
• Menus that cannot be operated with a keyboard.
• Missing visible focus indicators.
• Dialogs that trap keyboard focus.
• Unclear page titles.
• Repeated navigation without a bypass mechanism.
• Controls without accessible names.
• Unexpected context changes.

Automated testing and WCAG 2.0

Automated tools can identify many repeatable technical findings, including:

• Missing attributes.
• Some contrast failures.
• Duplicate identifiers.
• Some missing form labels.
• Invalid ARIA.
• Some structural errors.

Automated testing cannot establish complete WCAG conformance.

Human review is needed to determine:

• Whether alternative text communicates the correct meaning.
• Whether keyboard focus follows a logical path.
• Whether an interaction is predictable.
• Whether form instructions are understandable.
• Whether captions accurately represent the audio.
• Whether assistive-technology users can complete a full process.

How to test a website against WCAG 2.0

1. Define the scope:
   identify templates, pages, components, documents and complete user
   journeys.
2. Run automated scans:
   detect repeatable technical findings across representative content.
3. Test keyboard access:
   operate navigation, forms, menus and dialogs without a mouse.
4. Review visual presentation:
   test contrast, enlargement, colour use and visible focus.
5. Review structure:
   assess headings, landmarks, lists, tables and reading sequence.
6. Test forms:
   review labels, instructions, errors and submission confirmation.
7. Review multimedia:
   assess captions, transcripts and audio alternatives.
8. Use assistive technologies:
   test representative journeys with screen readers and other relevant
   tools.
9. Document findings:
   record user impact, affected elements and applicable success criteria.
10. Verify corrections:
    retest each resolved issue before closing it.

Does WCAG 2.0 create a legal obligation?

WCAG 2.0 is a technical accessibility standard, not a law by itself.

It may become legally or contractually relevant when referenced by:

• National or regional legislation.
• Government regulations.
• Public procurement requirements.
• Contracts.
• Settlement agreements.
• Internal accessibility policies.

The applicable legal requirement depends on the country, jurisdiction,
organisation, service and relevant version of WCAG.

Meeting WCAG can provide evidence of a structured technical accessibility
process, but it does not automatically settle every legal question.

WCAG 2.0, WCAG 2.1 and WCAG 2.2

WCAG 2.1 adds requirements addressing mobile use, low vision and cognitive
or learning disabilities.

WCAG 2.2 adds further requirements involving keyboard focus, dragging,
target size, consistent help, repeated data entry and accessible
authentication.

Later WCAG 2 versions preserve the earlier success criteria, with one main
exception: Success Criterion 4.1.1 Parsing is obsolete and is not included
in WCAG 2.2.

WCAG 2.0, WCAG 2.1 and WCAG 2.2 remain existing W3C standards. Later
versions do not formally deprecate the earlier versions.

For new work, W3C encourages use of the latest WCAG version. A website that
conforms to WCAG 2.2 also satisfies WCAG 2.1 and WCAG 2.0 at the equivalent
level, subject to the complete conformance requirements.

Read more about
WCAG 2.1 accessibility guidelines.

Why a few code changes are not enough

Website accessibility cannot usually be achieved by inserting a script or
making a small number of generic code changes.

WCAG conformance can involve:

• Content meaning.
• HTML structure.
• Visual design.
• Keyboard behaviour.
• Focus management.
• Forms and validation.
• Media alternatives.
• Dynamic interfaces.
• Third-party components.
• Complete user journeys.

Some findings can be corrected automatically or through shared components.
Others require human judgement, development changes and verification with
assistive technologies.

Prioritising remediation

Organisations should prioritise findings according to user impact,
frequency and the importance of the affected task.

High-priority areas commonly include:

• Primary navigation.
• Account creation.
• Login and password recovery.
• Search.
• Forms.
• Checkout and payment.
• Booking.
• Essential documents.
• Customer support.

Repeated issues in shared templates and components should often be corrected
before isolated page-level findings.

Maintaining accessibility

A website that meets an accessibility baseline today can develop new
barriers after:

• A redesign.
• A content update.
• A plugin or framework upgrade.
• A new form.
• A third-party integration.
• A document upload.
• A change to a shared component.

Accessibility should therefore be integrated into design, development,
content publishing, quality assurance, procurement and release management.

How Pluro supports WCAG accessibility workflows

Pluro is an accessibility workflow platform that helps organisations manage
findings from detection through verified remediation.

Teams can use Pluro to:

• Centralise automated and manual findings.
• Connect findings to relevant WCAG criteria.
• Capture keyboard and behavioural evidence.
• Assign responsibility to development, design, content or QA.
• Provide remediation guidance.
• Track correction status.
• Verify completed fixes.
• Maintain a history of accessibility work.
• Monitor websites after future changes.

Pluro is not an overlay or a one-click compliance solution. It supports the
operational process required to identify barriers, coordinate remediation
and verify that corrections work.

WCAG 2.0 checklist

• Define the required WCAG version and conformance level.
• Include complete pages and user processes in the scope.
• Provide alternatives for images, audio and video.
• Use semantic structure and meaningful relationships.
• Maintain sufficient contrast.
• Make functionality keyboard accessible.
• Provide visible keyboard focus.
• Give users enough time to complete tasks.
• Avoid harmful flashing content.
• Provide clear navigation, titles, headings and labels.
• Make forms predictable and errors understandable.
• Expose accurate names, roles and states.
• Combine automated and manual testing.
• Verify remediation before closing findings.
• Retest after content and product changes.

Important notice

This page provides general information and does not constitute legal advice
or a formal WCAG conformance assessment. Applicable requirements depend on
the website, jurisdiction, legislation, contract and assessment scope.

Review the official

Web Content Accessibility Guidelines 2.0
.

Review the

W3C overview of WCAG versions
.

See how Pluro manages accessibility workflows
or
start a 14-day free trial
with no credit card required.