A website can look polished and still be impossible for someone to use with a keyboard, screen reader or increased text size. Accessibility isn’t a finishing decoration. It is part of whether people can read the information, understand the interface and complete the site’s main tasks.
What WCAG 2.2 provides
The Web Content Accessibility Guidelines (WCAG) are developed by W3C’s Web Accessibility Initiative. They organize accessibility requirements around content being perceivable, operable, understandable and robust. WCAG 2.2 adds success criteria to earlier versions, including improvements related to focus visibility, target sizes and accessible authentication.
Use W3C’s WCAG 2.2 quick reference and summary of changes in 2.2 as the standard, rather than relying on a theme’s claim of being “fully accessible.” The exact legal obligations depend on the organization and the jurisdictions it serves.
Test the website without a mouse
Open the homepage and press Tab repeatedly. Can you see where focus is? Can you enter and exit menus, dialogs and search fields? Does a mobile menu trap focus when open, or does focus escape behind it? Check that the site offers a clear way to skip repeated navigation and reach the main content.
Inspect content with low vision in mind
Increase text size substantially and narrow the browser window. Look for clipped paragraphs, overlapping buttons, horizontal scrolling and controls that become unreachable. Text must remain readable against its background; subtle mint and gray palettes can fail contrast checks despite looking sophisticated. Check non-text controls such as icon buttons and borders, not only paragraphs.
| Area | Manual test |
|---|---|
| Headings | Read only headings; do they describe the page in a useful order? |
| Images | Does alternative text convey information without repeating nearby captions? |
| Forms | Can every field be identified and errors corrected without guessing? |
| Keyboard | Can every important task be completed without a mouse? |
| Zoom and mobile | Does the layout reflow without hiding key content or controls? |
| Focus | Is focus visible and unobscured when navigating with Tab? |
Do not use automation as the only test
Automated scanners can identify some missing labels, low-contrast combinations and structural issues. They cannot reliably judge whether alternative text is meaningful, whether instructions make sense, or whether a complicated checkout works for a real person with assistive technology. Combine scanning with keyboard tests, a screen-reader review and feedback from users with disabilities when possible.
Choose representative pages
Test at least the homepage, article template, search results, category archive, contact form, newsletter signup and a calculator or checkout if the site has one. Shared components can create the same bug across dozens of URLs. Fix global navigation and form patterns before chasing small cosmetic issues on individual pages.
Make an issue log that developers can act on
Record the affected URL, device, browser, action taken, observed behavior, expected behavior and relevant WCAG success criterion. Add a short reproduction path. “Mobile menu broken” is less useful than “at 200% zoom, focus moves behind the open drawer after the third Tab press.”
Accessibility is about completing real tasks
WCAG 2.2 provides testable accessibility criteria, but an audit should begin with the journeys that matter most to a visitor: reading information, navigating categories, searching, submitting a form and completing a purchase. A website can pass automated scans while remaining difficult to use with a keyboard, screen reader, zoom or touch input.
Choose representative templates: the homepage, an article, a comparison table, a form, a search result and the checkout if there is one. Test each with the same conditions and record failures in terms of user impact. A vague instruction to “improve accessibility” gives developers little direction; a reproducible issue with a page URL and expected behavior can actually be fixed.
A practical manual test sequence
| Test | What to observe |
|---|---|
| Keyboard navigation | All relevant controls reachable in a logical order with visible focus |
| Zoom and reflow | Text and controls remain usable without unnecessary two-axis scrolling |
| Forms | Labels, required fields and errors are understandable |
| Images | Meaningful alternatives for informative images; decoration handled appropriately |
| Headings | Structure describes content instead of being used solely for visual size |
| Touch controls | Targets remain practical for visitors with different motor abilities |
Use the W3C WCAG 2.2 quick reference to connect an observed issue to the relevant success criterion. Automated tools can help identify patterns, but conformance cannot be concluded from an automated percentage alone. Review the site’s actual functionality with assistive technology and real users where feasible.
Work from customer harm to technical priority
If a payment button cannot be activated by keyboard, the problem blocks a core transaction and deserves immediate attention. If a decorative icon lacks appropriate treatment, it may be lower priority, depending on the context. Rank issues by how severely they prevent task completion, how many templates are affected and how quickly they can be repaired.
Keep a log with the affected URL, steps to reproduce, expected result, actual result, relevant criterion, severity and owner. After a repair, retest the complete journey. A form that becomes keyboard accessible but stops sending notifications is not a successful fix.
Content teams own a significant part of accessibility
Editors control headings, link labels, table structure, image descriptions and the clarity of instructions. Developers control components, focus behavior, semantics and much of the responsive layout. Train both groups to work together. A content publishing checklist that catches ambiguous links and missing table headings can prevent problems from returning after the technical audit.
A consistent accessible design system is usually more valuable than one-time fixes applied separately to dozens of pages. Reusable buttons, form patterns and navigation components reduce the chance that each new feature introduces another avoidable barrier.
What an audit can and cannot certify
An internal checklist can identify improvements and document reasonable testing, but it does not by itself establish legal compliance or official WCAG conformance. Requirements differ by jurisdiction and use case. When the site serves public services, regulated customers or an audience with substantial accessibility needs, obtain qualified review appropriate to the risk. Continue testing as new content, ads and third-party widgets are introduced.
Prioritize critical user journeys
Address blocks to purchasing, requesting help, reading essential content and accessing account settings before minor visual inconsistencies. Then establish a review step for new templates, content and third-party widgets. Accessibility work is an ongoing editorial and engineering practice, not a one-time plugin installation.
For broader technical upkeep, see our WordPress performance checklist and plugin evaluation guide. This article is a first-pass audit plan, not a certification that a website conforms to WCAG.