WAVE Accessibility Checker | Find and Fix Website Barriers Before They Exclude Your Visitors

A website can look attractive, load quickly, and contain

valuable information while still being difficult for some people to use.

A visitor may be unable to read text because of poor colour contrast. Someone navigating with a keyboard may get trapped in a menu. A screen reader user may encounter an image without a meaningful text alternative or a form field without an understandable label.

These are digital accessibility problems. They can prevent people with visual, hearing, motor, cognitive, or other disabilities from accessing information and completing tasks online.

For website owners, bloggers, developers, designers, and digital businesses, identifying these barriers is part of building a website that serves more people.

One practical starting point is WAVE, a web accessibility evaluation tool developed by WebAIM.

This chapter explains how to use WAVE to inspect a website, understand its findings, investigate common problems, and plan improvements. You will also learn why a clean automated report does not necessarily mean that a website is fully accessible.

1. What Is WAVE?

WAVE is a collection of web accessibility evaluation tools that helps people identify potential accessibility problems in web content.

Official website: https://wave.webaim.org/

WAVE can identify many issues associated with accessibility guidelines and display findings in the context of a webpage. This helps you investigate problems instead of relying entirely on a numerical score.

Its tools include:

• A free online checker that evaluates a webpage by its URL.
• Browser extensions for checking pages directly in the browser.
• Additional testing services and APIs for more advanced workflows.

The online checker is useful for inspecting publicly accessible pages. Browser extensions can be helpful when testing pages that require authentication, are stored locally, or contain dynamic content.

The available features and access conditions can vary by tool, so check the official WAVE website for current details.

Who can benefit from WAVE?

WAVE is useful for several groups.

Bloggers and publishers can investigate headings, images, links, and other elements that affect access to their content.

Website designers can identify potential problems with layout, colour contrast, and content structure.

Developers can investigate markup-related issues and improve how websites communicate information to assistive technologies.

Business owners can identify barriers that might prevent customers from reading product information, completing forms, or navigating a website.

Students and learners can use WAVE to understand how accessibility issues appear on real webpages.

You do not need to be an accessibility specialist to begin using the tool. However, interpreting the results correctly requires some understanding of the issues it identifies.

2. Understand What Website Accessibility Means

Web accessibility means designing and developing websites, applications, and digital content so that people with disabilities can perceive, understand, navigate, interact with, and contribute to them.

Accessibility also benefits people who do not identify as having a disability. Someone using a phone outdoors may struggle with low-contrast text. A person with a temporary hand injury may depend on keyboard navigation. A visitor with a slow connection may benefit from a simpler page that does not depend on unnecessary media.

Accessibility is therefore not merely a special feature for a small group. It is part of making digital services usable by a wider range of people and circumstances.

The Web Content Accessibility Guidelines (WCAG), maintained by the World Wide Web Consortium (W3C), organise accessibility requirements around four principles:

• Perceivable: Information and interface elements must be presentable in ways users can perceive.
• Operable: Users must be able to operate the interface.
• Understandable: Information and interface behaviour should be understandable.
• Robust: Content should work reliably with a range of user agents and assistive technologies.

These principles are often abbreviated as POUR.

WAVE helps investigate certain aspects of accessibility, but it does not independently determine whether a website satisfies every WCAG requirement.

You can learn more through the official W3C Web Accessibility Initiative.

3. Run Your First WAVE Check

Start with a webpage you own or are authorised to evaluate.

For example, you could inspect a published blog post, your website's homepage, or a public service page.

Step 1: Open the official tool

Visit:

https://wave.webaim.org/

Check the domain carefully before entering a website address. Use the official WAVE service rather than an unfamiliar website that imitates its name.

Step 2: Choose a webpage

Copy the complete URL of the page you want to inspect.

For a blog, this might be a published article rather than the homepage. Individual posts may contain different headings, images, links, forms, and embedded elements.

Step 3: Enter the URL

Use the address field on the WAVE website to enter the webpage URL and start the evaluation.

The service attempts to retrieve the page and display its findings.

If the page cannot be accessed, the tool may not be able to evaluate it through the online checker. The problem could involve network access, authentication, blocking, or another technical limitation. Do not interpret a failed scan as evidence that the page has no accessibility problems.

Step 4: Examine the results

WAVE displays findings alongside information about the page. Depending on the page and the tool's current interface, findings can include errors, alerts, structural information, contrast information, and other accessibility indicators.

Do not immediately focus on the total number of findings.

Instead, ask:

• What is the issue?
• Where does it appear?
• Which users might be affected?
• Does the finding indicate a confirmed problem or something that needs human review?
• What change would address the underlying cause?

This approach turns the report into an investigation rather than a score-chasing exercise.

4. Understand WAVE's Findings

One of the most important skills in accessibility testing is distinguishing between different types of findings.

Errors

Errors identify accessibility problems detected by the tool's rules.

For example, an image may be missing alternative text, or a form control may lack an accessible name.

An error should be investigated and corrected where appropriate. The exact fix depends on the element's purpose and how it is implemented.

Alerts

Alerts identify situations that may require further investigation.

An image may have alternative text, for example, but the text might be unhelpful. An alert can draw attention to a possible issue without proving that the content is wrong.

Read the explanation and inspect the actual page before deciding what to change.

Structural information

Structural indicators help you understand how a page is organised.

Headings, landmarks, lists, and other elements can reveal whether the content has a useful structure. A page may look visually organised while its underlying structure is confusing to someone navigating with assistive technology.

Contrast findings

Colour contrast affects whether text and other visual information can be distinguished from their backgrounds.

A colour combination that looks acceptable on your own screen may be difficult for another person to read.

Investigate the specific foreground and background colours and the relevant contrast requirements. Do not assume that making text bold or slightly larger automatically solves every contrast problem.

A crucial distinction

A finding is not always a final verdict, and the absence of a finding is not proof that everything is accessible.

WAVE helps you identify potential barriers. Your responsibility is to understand the issue, decide whether it is genuine, and verify the result after making changes.

5. Fix Common Accessibility Problems

The following examples illustrate how to turn findings into practical improvements.

Problem A: Images without meaningful alternative text

Alternative text provides a text equivalent for an image when the image conveys information that users need.

Imagine a blog article explaining a computer network with an important diagram. If the diagram has no appropriate text alternative, a visitor who cannot see it may miss the information it communicates.

A useful alternative describes the image's relevant purpose or information.

For example:

Weak alternative text: image123

More useful alternative text: Diagram showing a router connecting three computers to a local network

The second description communicates what the image illustrates.

However, not every image needs a descriptive alternative. Decorative images should generally be implemented so that assistive technologies can ignore them. An image that functions as a link should communicate the link's purpose where that purpose is not already clear.

Do not add lengthy descriptions to every image simply to remove a warning. Choose the alternative according to the image's function and context.

What to do: Inspect the image, determine its purpose, and add or correct the alternative text in the website's content editor or underlying markup.

Problem B: Poor colour contrast

Text needs sufficient contrast against its background to remain readable for people with different visual abilities.

A pale grey paragraph on a white background may be difficult to read. Some combinations of coloured text and backgrounds can also fail contrast requirements even when they look attractive.

For normal text, WCAG 2.2 Level AA generally requires a contrast ratio of at least 4.5:1. Large text generally requires at least 3:1, subject to the guideline's definitions and exceptions.

What to do:

1. Identify the text and background colours.
2. Use a suitable contrast checker to evaluate the combination.
3. Adjust the colours where necessary.
4. Recheck the combination after making the change.
5. Inspect the text in the actual page layout.

Do not rely on colour alone to communicate important information. For example, a form should not indicate an error only by turning a field border red; it should also provide a clear explanation.

Problem C: Confusing heading structure

Headings help readers understand the organisation of a page. They are especially useful for people who navigate through a document using heading lists.

A webpage might use large, bold text to imitate headings while the underlying HTML treats every line as an ordinary paragraph.

That can make the page less understandable to assistive technology.

What to do:

• Give the page a clear main heading.
• Use lower-level headings to organise sections.
• Keep heading levels meaningful and logically ordered.
• Avoid choosing a heading level solely because it produces the font size you want.

For example, an article could use a main heading for its title, second-level headings for major sections, and third-level headings for subsections.

A visually attractive hierarchy should also have a meaningful underlying structure.

Problem D: Links that do not explain their destination

A link labelled “click here” may make sense in its immediate paragraph but become confusing when someone encounters it in a list of links.

More descriptive text can communicate the destination or purpose.

For example:

Weak: Click here

More useful: Read the W3C guide to web accessibility evaluation

What to do: Review the surrounding context and write link text that communicates the destination or action. Avoid repeating excessively long URLs as link labels when a clear description would work better.

The right wording depends on context. A short label can be perfectly appropriate when its purpose is clear.

Problem E: Forms that are difficult to understand

Forms often contain several interacting accessibility requirements.

A visitor may need to understand what information belongs in each field, which fields are required, what went wrong after submission, and how to correct the problem.

A placeholder alone is not always a sufficient substitute for a proper field label.

What to do:

• Provide clear labels for form controls.
• Explain required information where necessary.
• Make validation errors understandable.
• Ensure users can identify and correct mistakes.
• Test the form using keyboard navigation.

Some form problems require changes to the underlying website code or the form service itself. If you use a hosted platform, check which settings and markup the platform allows you to control.

6. Use WAVE With a Blogger Website

If you publish through Blogger, you can use WAVE to investigate published posts and pages without first building a separate testing application.

Start with a published article

1. Open your Blogger blog.
2. Open a published article in its public view.
3. Copy the article's complete URL.
4. Visit the official WAVE website.
5. Enter the URL and run the check.
6. Review the findings associated with the article.
7. Record the problems that need attention.

Start with one article rather than attempting to evaluate your entire archive at once.

Investigate the content you control

Depending on your Blogger theme and editor, you may be able to correct some issues directly through your post content.

Examples include:

• Adding appropriate alternative text to informative images.
• Replacing vague link text.
• Improving the logical organisation of headings.
• Revising text or background colours where you control them.
• Simplifying confusing content structures.

Other problems may originate in the theme, navigation, widgets, embedded content, advertising, or platform-generated markup.

Do not assume that every finding can be fixed through the post editor.

If a problem originates in the theme, identify whether the relevant theme settings or HTML can be changed safely. Keep a backup before making significant theme modifications.

Test beyond a single article

After practising on one post, inspect other important page types, such as:

• Your homepage.
• A representative article.
• A page containing forms or embedded content.
• Navigation and other shared interface elements.

A single successful scan does not establish that the entire website is accessible. Different page types may introduce different problems.

7. Test the Page as a Human User

Automated testing is useful, but accessibility also depends on how people actually interact with a website.

After reviewing WAVE, perform several manual checks.

Keyboard navigation

Try navigating the page using the keyboard without relying on a mouse.

Check whether you can reach interactive elements, identify which element currently has focus, operate menus, and complete important actions.

If you become trapped in a component or cannot reach a critical control, investigate the problem.

Readability and zoom

Enlarge the page using the browser's zoom controls. Check whether text remains readable, content is lost, or essential controls become difficult to use.

Inspect the page on a smaller screen where possible. A responsive layout should not unnecessarily hide important information or force visitors to navigate an unusable interface.

Content understanding

Read the headings, links, instructions, and form messages.

Ask whether a visitor could understand the page's purpose and identify the next action without relying entirely on colour, position, or visual appearance.

Screen reader considerations

Screen readers convert digital content into speech or other accessible output. Their behaviour depends on the assistive technology, browser, operating system, and page implementation.

If you can, test important workflows with a screen reader or arrange feedback from people who use assistive technology.

Do not assume that a website works well with screen readers merely because WAVE reports few errors.

W3C's Easy Checks — A First Review of Web Accessibility provides a practical starting point for manual evaluation.

8. Understand the Limits of Automated Testing

It is tempting to treat accessibility testing as a process of running a tool until every warning disappears. That is not a reliable strategy.

Some problems require contextual judgment.

For example:

• An image can have alternative text that is technically present but describes the wrong thing.
• A heading structure can contain valid elements but still be confusing.
• A link can be technically accessible but communicate an unclear purpose.
• A form can have labels but still provide an unusable error-recovery process.
• A page can pass automated checks while remaining difficult to operate using a keyboard.

WAVE cannot determine every aspect of the experience for every user. The W3C explicitly recommends combining suitable evaluation tools with knowledgeable human evaluation.

See W3C: Evaluating Web Accessibility.

This matters when making public claims about a website.

Do not announce that a website is fully accessible, WCAG-compliant, or legally compliant solely because an automated checker produced a clean report. A conformance claim requires a more comprehensive and appropriate evaluation.

9. Turn Accessibility Testing Into a Repeatable Workflow

A single scan is useful for learning, but repeated evaluation is more useful for maintaining a website.

Use this workflow whenever you publish or significantly update important content.

Before publishing: Review the content structure, informative images, links, forms, and colour choices that you control.

After publishing: Run an appropriate accessibility check on the public page.

Investigate: Read the findings and distinguish definite issues from items requiring further judgment.

Correct: Make appropriate changes to the content, theme, or implementation.

Verify: Run the relevant checks again and manually test important interactions.

Record: Keep a short note of the problem, correction, and remaining limitations.

A simple record could contain:

Field	Example
Page	Published article URL
Finding	Informative image lacks an appropriate alternative
Location	Image within the second section
Correction	Added a meaningful text alternative
Verification	Rechecked the page and reviewed the image's purpose
Remaining work	Keyboard testing of shared navigation

This record helps you avoid repeating the same investigation and makes it easier to track recurring issues.

For a large website, you may need a more systematic assessment of representative pages and user journeys. W3C's Website Accessibility Conformance Evaluation Methodology provides a framework for more comprehensive evaluations.

10. Practise on a Website You Know

Use a website you own or have permission to evaluate.

Your first exercise is to inspect one published page and identify three things:

1. One finding that appears to indicate a definite problem, if any is present.
2. One aspect that requires human judgment.
3. One manual test that would help you understand the visitor's experience.

If the page has no obvious findings, do not invent problems. Choose a different page or use W3C's accessibility resources to practise evaluating a known example.

Next, select one genuine problem and investigate it.

Write down what you observed, why it matters, what you changed, and how you checked the result. If the issue requires changes to the theme or underlying code, record the limitation rather than making an unsafe modification.

The aim is not to achieve a particular WAVE score. It is to learn how to identify and address barriers that affect real people.

Conclusion

Digital accessibility is part of responsible website design, publishing, and development. A website should not merely display information; it should make that information and its important functions usable by as many people as reasonably possible.

WAVE gives you a practical starting point for finding potential barriers. Used carefully, it can help you investigate images, headings, contrast, and other accessibility concerns.

But the tool is only one part of the process. You must interpret the findings, make appropriate corrections, test important interactions, and consider the experiences of people who use assistive technologies.

Inspect the page. Understand the barrier. Make a meaningful correction. Test the result. Repeat.

That is how accessibility evaluation becomes an ongoing part of building better digital experiences. 

Image: DreamHost