How WAVE Browser Extension Catches Real Errors
If a page feels hard to use, WAVE usually tells why in under a minute. It flags missing alt text, contrast failures, heading structure issues, and ARIA misuse right on the page. No guessing and no code required. It fits neatly into daily design and QA workflows for teams that care about WCAG compliance and real-world accessibility testing. The best part: designers, developers, and content folks can all use it without special training.
Below is a practical take on what WAVE does well. Where it falls short, and how to get the most out of it with a quick. Repeatable 10‑minute sweep that uncovers issues that affect users; especially keyboard and screen reader users who often face broken flows. I’ll also show where to add manual checks, so the audit doesn’t stop at surface-level issues and marketing pages don’t slip through with hidden blockers for ADA and Section 508 compliance.
What WAVE Does Best (and What It Misses)
WAVE shines at fast, visual checks that catch common WCAG failures on first pass. It overlays icons on the page and lists issues in a sidebar. So it’s easy to match a problem to the element that caused it. It also groups items into errors, alerts, features, and structural elements; useful for triaging fixes during sprint work.
What it does best:
- Highlights missing or suspicious alt text right where images live. Making content fixes straightforward for editors and marketers.
- Surfaces color contrast problems that break task flows and readability. With contrast ratios and affected elements visible in context.
- Maps heading structure so teams can fix skipped levels. Get screen reader navigation back on track without digging through code.
- Flags ARIA roles, labels, and landmarks that can confuse assistive tech when misused. Which helps keep “fixes” from making things worse.
What it misses:
- Keyboard traps, focus order, and interactive behavior problems, because those need hands-on testing with a keyboard and real navigation paths.
- Screen reader experience issues like confusing announcements, redundant labels. Or modal focus bugs that only show up when reading the page out loud with a screen reader.
- Dynamic content changes, timing, and error recovery patterns that affect real users during form submissions or single-page app updates.
So, treat WAVE as a fast front line: it clears the noise and reveals the obvious. Then manual checks confirm the experience for real users with assistive tech.
Spotting Alt Text Problems in Context
WAVE pins markers on images with missing alt attributes or empty alt text that looks suspicious given the image’s purpose. That context matters because the right fix depends on the role of the image:
- Decorative images: keep alt empty so screen readers skip noise and users can move faster through content.
- Informative images: add precise, concise alt text that conveys the same information a sighted user gets without repeating nearby captions.
- Linked images: make sure the alt describes the destination or action. Not just “logo” or “image,” so link purpose is clear for screen reader users.
I like to scan hero banners, feature cards, and CTA blocks first because mistakes there hurt both accessibility and conversions. If the main CTA uses an image with weak or missing alt text. Screen reader users won’t know what action they can take. An easy and costly miss during campaign launches.
Contrast Issues That Break Real User Flows
Low contrast doesn’t just affect reading; it breaks critical tasks like finding buttons. Spotting form errors, or reading disabled help text. WAVE catches contrast failures and shows the exact elements and colors involved, so designers can adjust tokens quickly. Pay extra attention to:
- Text on images or gradients, where visual design may pass a quick eye test but fails the ratio check.
- Small, lightweight fonts used for helper text or legal copy that slip below required contrast thresholds.
- Focus indicators and link states that blend into backgrounds, which hurts keyboard users and anyone scanning for interactive elements.
Fix contrast in components, not just one-off pages, so changes cascade site-wide and reduce rework in future sprints.
Setting Up WAVE for Daily Design Checks
Teams get the most from WAVE when they add it to the daily review loop. Right before sign‑off on a new page or component. It takes a few minutes to install and configure. But it pays back every day by catching problems early when changes cost less.
Installing and Configuring the Browser Extension
- Install the WAVE extension for the browser used in the team’s review workflow, so designers and QA see the same overlays and counts.
- Pin the extension for one‑click access and set a habit: run it before merging a feature branch or publishing a page.
- Turn on contrast and structure views in the sidebar to speed up triage, and collapse categories that rarely apply to your site to reduce noise during quick checks.
- Save a checklist template inside the team’s QA doc and pair it with screenshots from WAVE, so developers know what to fix and where.
Running Your First Page Scan
- Open the target page and click the WAVE icon to inject overlays and the results panel.
- Start with the summary view to see error counts, then jump into the code or structure tabs if something looks off.
- Click markers on the page to jump to the element in context and read the associated message, then add a ticket with the exact component or template name to speed up fixes.
- Re-run the scan after each fix, and aim for zero errors and a clean structure map before shipping.
The 10‑Minute WAVE Sweep Checklist
Use this quick routine before page sign‑off or campaign launch to catch the top WCAG blockers that WAVE can validate fast. Keep it on a sticky note, or better yet, bake it into the pull request template so the team can ship with confidence and lower risk for ADA website requirements.
Essential Checks Before Page Sign-off
- Alt text on all informative and linked images makes sense, and decorative images stay silent with empty alt attributes.
- Contrast passes for body text, small helper text, buttons, links, and focus indicators, including text over images and gradients.
- Heading structure starts at H1 and follows a logical order with no skipped levels, so screen reader users can jump between sections easily.
- Links and buttons have meaningful names, visible focus, and don’t rely on color alone to convey state, so keyboard users can find and activate them reliably.
- Form fields show clear labels, visible errors, and helpful instructions that don’t disappear or hide behind icons, so the flow remains usable under pressure.
- ARIA landmarks match the page layout (main, navigation, complementary) and don’t conflict with native elements, reducing confusion in screen reader regions.
- No obvious overlays obscure content or trap focus during cookie banners, popups, or modal dialogs, which WAVE can hint at by revealing structure mismatches and ARIA alerts.
Common False Positives to Ignore
- Decorative dividers or background SVGs that don’t require alt text and shouldn’t announce to screen readers, as long as they aren’t focusable or interactive.
- Repeated structural warnings on components that the team already audited and documented as acceptable patterns for the current design system.
- “Feature” notes that look scary but only mark helpful semantics (for example, correctly set landmarks), which don’t require any fixes during a quick pass.
Treat false positives lightly, but never ignore an error attached to real content or interactive elements; especially anything that touches forms, buttons, or navigation.
When WAVE Isn’t Enough: Adding Manual Tests
Automated checks only catch a slice of WCAG failures, so teams need a simple manual routine to cover behavior and assistive tech experience. Add the steps below right after the WAVE sweep to complete the picture and raise confidence before release, especially for e‑commerce flows and logged‑in dashboards where missed issues become serious blockers.
Keyboard Navigation Checks WAVE Can’t Do
- Tab through the page from the top: can the focus reach every link, button, and input, and does focus stay visible at all times?
- Open menus, modals, and accordions with Enter or Space, and close them with Esc; check that focus returns to the trigger when the dialog closes.
- Check logical focus order: does tabbing move through the page the same way a person reads it, or does it jump around awkwardly because of CSS positioning or hidden DOM order?
- Try a form start to finish using only a keyboard: can errors be fixed without the mouse, and does the error message announce right where focus lands?
This quick pass takes 3–5 minutes and finds the issues that frustrate keyboard users the most; issues automation won’t catch.
Screen Reader Verification Steps
- Turn on a screen reader and navigate by headings first: do section labels make sense and cover the full page structure without gaps?
- Navigate by links and form fields: do names and instructions make sense when read aloud without surrounding context?
- Trigger common interactions: open a menu, submit an empty form, close a dialog; listen for clear announcements and confirm that focus lands where a user expects next.
- Check repeatable templates: product cards, article lists, and pagination; make sure the experience sounds consistent and predictable across items.
This isn’t a deep test, but it reveals the rough edges that make a page feel broken for screen reader users even when WAVE looks clean.
Extra Sections to Reach Full Coverage
To help teams ship pages that hold up under audits and real use, it helps to connect WAVE checks with a few broader practices that keep quality high over time and support WCAG compliance at scale.
Building Accessibility into Components
- Fix contrast and alt text patterns in the design system, not one page at a time, so future pages inherit the right defaults.
- Add a WAVE screenshot to each component’s QA checklist, including contrast ratios and live examples that passed, so developers can see how a correct state looks before they code.
- Document “do and don’t” examples in the component library for headings, labels, and landmarks to reduce inconsistent patterns across teams.
Pair WAVE with an Accessibility Audit Cadence
- Run WAVE for every new page and after major visual updates, then schedule quarterly manual checks for keyboard and screen reader flows on top traffic pages.
- Use audit findings to update the backlog with component-level fixes and training topics for content authors and designers.
- Track metrics that matter: error count trend by template, contrast failure rate by component, and time to fix top issues; these show progress beyond a one‑time pass.
Content Teams: Small Habits with Big Impact
- Add alt text while writing, not at the end, and write it as if describing the page to someone on a call: short, direct, and relevant to the goal of the content.
- Use headings to express the story of the page, not just format; a quick “heading only” read‑through should summarize the page clearly.
- Avoid link text like “learn more”; use meaningful nouns and verbs that describe destinations or actions for better clarity and SEO.
Designers: Contrast and Focus First
- Test contrast in light and dark backgrounds and over images; build tokens that pass under different states like hover and disabled.
- Commit to visible focus styles early; don’t rely on default browser outlines that get removed by CSS resets or clash with brand colors.
- Include a keyboard walkthrough in design reviews: “Can I reach everything? Can I see where I am? Can I complete the task without a mouse?”
Developers: Ship with Confidence
- Treat ARIA as a last resort and prefer native HTML roles; WAVE helps spot misuse that causes double announcements or conflicts.
- Validate headings, landmarks, and names in WAVE before pushing a branch; screenshots help reviewers spot regressions quickly.
- Keep DOM order logical and use CSS for layout; avoid tabindex tricks or off‑screen hacks that scramble focus order.
Putting It All Together: A Real-World Flow
Here’s how a team can use WAVE in a typical sprint:
- Day 1–2: Design adds contrast tokens and focus styles while prototyping components. They run WAVE on static mocks in the browser with prototype pages.
- Day 3–4: Dev builds the component, runs WAVE, and attaches a screenshot to the pull request. QA follows the 10‑minute sweep when testing the merged feature.
- Day 5: Before release, the team runs keyboard checks and a short screen reader pass on the key flows tied to the feature (for example, add to cart, newsletter signup).
- Post‑release: Analytics confirm no drop‑off in conversions for keyboard or screen reader users; the team logs any new issues and updates the design system if needed.
This loop prevents last‑minute fire drills and keeps fixes small and fast, while maintaining a clear link to WCAG compliance and an accessible experience that stands up to audits and real users.
FAQ: Quick Answers Teams Ask About WAVE
- Is WAVE an accessibility testing tool or just a linter? It’s an automated checker for visible issues and structure that points to likely WCAG failures; it’s not a full test on its own.
- Can non-technical roles use it? Yes, content editors and designers use it daily to catch alt text, headings, and contrast issues without code changes.
- How does it relate to WCAG and ADA? WAVE helps identify problems tied to WCAG success criteria; teams should still perform manual checks to reduce legal risk under ADA and Section 508.
- Will it work on single-page apps? It can, but dynamic states need manual testing; always confirm focus behavior and announcements with a screen reader after route changes.
- How do we track progress? Keep component‑level tickets for recurring issues, log WAVE error counts per release, and set a quarterly review of top traffic templates.
Final Checklist: Use This Before You Hit Publish
- Zero WAVE errors on the page, with a clean heading map and valid landmarks.
- Contrast tokens pass across states and backgrounds, with focus styles visible at all times.
- Images have correct alt decisions (empty for decorative, descriptive for informative, action‑oriented for linked).
- Keyboard-only users can complete top tasks; modals open and close with focus managed correctly.
- Screen reader users can navigate by headings, links, and forms with clear names and announcements.
If a page passes these steps, it will feel better for everyone, and it will stand up when auditors come calling for WCAG and ADA compliance proof.
Using Automated Tools for Quick Insights (Accessibility-Test.org Scanner)
Automated testing tools provide a fast way to identify many common accessibility issues. They can quickly scan your website and point out problems that might be difficult for people with disabilities to overcome.
Visit Our Tools Comparison Page!
Run a FREE scan to check compliance and get recommendations to reduce risks of lawsuits
Final Thoughts
Want a simple way to keep momentum? Add our 10‑minute WAVE Sweep as a checklist in the team’s QA doc and set a weekly reminder to test one high‑traffic page for keyboard and screen reader behavior. Then share results with the team so fixes roll into components, not just one-off pages.
Start your compliance journey, update your accessibility statement, and keep EAA top of mind in every project going forward.
Run a Free Scan to Find E-commerce Accessibility Barriers
Want More Help?
Try our free website accessibility scanner to identify heading structure issues and other accessibility problems on your site. Our tool provides clear recommendations for fixes that can be implemented quickly.
Join our community of developers committed to accessibility. Share your experiences, ask questions, and learn from others who are working to make the web more accessible.