If your team is preparing for an accessibility review, a clear WCAG 2.2 checklist can help you catch common issues before they turn into audit findings. WCAG 2.2 builds on earlier guidance and raises the bar in several practical areas, especially for keyboard users, people with low vision, users with cognitive disabilities, and anyone navigating complex forms or authentication flows.
For compliance, privacy and digital teams, the challenge is rarely just identifying one broken component. It is maintaining website accessibility compliance across templates, content updates, third-party scripts, consent interfaces and ongoing product changes. That is why a pre-audit checklist should focus on repeatable checks your team can apply across the full user journey.
Below is a practical list of 15 issues worth reviewing before your next audit. It is not a substitute for a full accessibility assessment, but it is a strong way to reduce avoidable problems and improve readiness for WCAG 2.2 compliance work.
Accessibility audits often surface patterns, not isolated defects. A missing focus indicator in one component usually means the same issue appears across navigation, forms, modals and account areas. A weak checklist helps teams stay reactive. A strong one helps teams review the experience systematically.
Using a structured checklist before an audit can help your team:
WCAG 2.2 is especially relevant for organizations aligning digital experiences with broader obligations around accessibility, privacy and legal compliance. If your website also includes consent flows, notices or embedded tools, those experiences should be reviewed as part of the same accessibility process.
Users must be able to reach and operate links, buttons, menus, form controls, dialogs and custom components using only a keyboard. Review navigation, search, filters, accordions, carousels, popups and embedded widgets.
Common issues include clickable elements built from non-semantic containers, keyboard traps inside overlays, and controls that require a mouse hover to work.
WCAG 2.2 places strong emphasis on focus visibility. When users tab through the interface, they should be able to clearly see where they are at all times. Review focus states across headers, menus, forms, modal windows and footers.
Look for low-contrast outlines, focus styles hidden by CSS resets, and components where the focused item is partially obscured.
When keyboard focus moves, the active element should remain visible. Sticky navigation bars, cookie banners, chat launchers and other overlays can easily cover focused controls, especially on smaller screens.
This becomes particularly important on sites with layered compliance interfaces. If your site uses a combined accessibility or consent layer, test those states carefully. Corpowid discusses this broader interface approach in Inside the 4-in-1 Widget: Accessibility, Consent, Legal and Company Info in One Script.
Small tap targets create real barriers for users with limited dexterity and for mobile users in general. Check primary actions, icon buttons, close controls, pagination, dropdown triggers and consent controls.
Pay close attention to mobile layouts where visual spacing may shrink, even if desktop designs look acceptable.
If any feature depends on dragging, swiping along a precise path or similar pointer gestures, users should have another way to complete the same task. This can affect sliders, sortable lists, maps, media controls and interactive dashboards.
Where possible, provide buttons, direct input fields or simple single-pointer alternatives.
If an action can be triggered by shaking, tilting or moving a device, users need a standard interface alternative. Motion-triggered interactions can be difficult or impossible for many users and should never be the only way to complete a task.
Forms remain one of the most common sources of accessibility failures. Review labels, instructions, required fields, grouping, validation, error messages and confirmation states.
Before an audit, test whether users can:
WCAG 2.2 gives added attention to authentication experiences. Login, account recovery and verification steps should not create unnecessary memory tests or confusing cognitive burdens.
Review sign-in flows, one-time code entry, password reset paths and account creation. Make sure instructions are clear, fields are labeled, and users are not forced into inaccessible verification patterns.
Images that convey information or act as controls need meaningful text alternatives. Decorative images should not create noise for assistive technology. Review icons, linked cards, product imagery, charts, infographics and logos used as navigation elements.
One of the most common problems is alt text that repeats surrounding text without adding value, or image links with vague labels that do not communicate purpose.
A clear heading structure helps screen reader users, keyboard users and content teams alike. Every page should have a logical content hierarchy, with headings that describe the section that follows.
Look for skipped heading levels, headings used only for styling, repeated vague headings and sections that visually appear important but are not marked up semantically.
Text, controls, focus indicators and meaningful visual elements need sufficient contrast. Also check whether status, validation and alerts rely only on color. Users should not have to distinguish meaning from color alone.
This is especially important in error states, charts, selected filters, required field indicators and consent preferences.
Modern sites often update content without a full page reload. Search results, inline validation, cart updates, consent changes and modal confirmations should be communicated properly to assistive technologies.
Review whether users receive clear feedback when something changes and whether that feedback is announced in a way that matches the context.
Dialogs should open with correct focus management, keep focus within the active window when appropriate, and return focus logically when closed. Users should be able to dismiss or complete the interaction without confusion.
Cookie banners and privacy controls are often overlooked in accessibility reviews, even though they are legally significant user-facing components. If your team is reviewing consent experiences alongside accessibility work, this related guide may help: How to Run a Cookie Audit on Your Website in 5 Steps.
Your accessibility posture is only as strong as the weakest embedded experience. Audit chat widgets, booking tools, video players, maps, payment flows, analytics overlays and external forms.
Third-party tools often introduce keyboard issues, poor labeling, inconsistent focus order or inaccessible iframes. These problems still affect your users, even if the code comes from another vendor.
One of the most common pre-audit mistakes is fixing a single page and assuming the issue is resolved everywhere. Re-test shared templates, reusable components and responsive breakpoints after remediation.
This is where ongoing monitoring matters. Accessibility work is not only about passing one review. It is about maintaining compliance readiness as content, code and regulations change. Teams exploring a more automated workflow may also be interested in AI Agents Are Here: How Autonomous AI Will Quietly Take Over Your Accessibility To-Do List.
The most effective way to use a WCAG 2.2 checklist is to apply it across representative user journeys, not just a handful of pages. Start with the paths that matter most to users and to the business.
A strong review combines manual checks with automated scanning. Automated tools can help detect certain issues quickly, but they cannot judge the full user experience. Manual keyboard testing, screen reader review and responsive testing are still essential.
If the same button component fails across ten templates, document it as a design-system or component-level issue. This makes remediation faster and helps teams prevent the problem from recurring.
Many organizations prepare for an audit by reviewing visible content issues while missing structural and workflow-related barriers. The most commonly overlooked areas include:
These issues are easy to miss because they often appear only under certain states, devices or interaction methods. That is why continuous monitoring and repeatable compliance workflows matter as much as one-time remediation.
A checklist is useful, but sustainable compliance requires more than a one-off review. Teams usually get better results when accessibility is built into design, development, content publishing and legal or privacy operations together.
For organizations managing accessibility alongside consent and legal disclosures, a unified approach can reduce fragmented tooling and inconsistent user experiences. Corpowid positions this as one platform for accessibility, cookie consent and legal compliance, helping teams audit, fix and monitor digital obligations in one place.
If your organization also needs documentation support for procurement or enterprise accessibility reviews, Corpowid’s VPAT ACR services may be relevant alongside broader accessibility compliance efforts.
The best WCAG 2.2 checklist is the one your team can use consistently before every release, redesign and audit cycle. Start with the 15 issues above, test them across real user journeys, and treat recurring failures as system-level problems rather than isolated bugs.
If you want to improve audit readiness, reduce regulatory risk and create a more maintainable accessibility process, the right next step is not just fixing isolated findings. It is putting accessibility, consent and compliance monitoring into an ongoing operational workflow.
No. A checklist is a practical starting point, but it does not guarantee full compliance. A complete accessibility review should include manual testing, representative user journeys, component-level analysis and ongoing monitoring.
WCAG 2.2 expands on earlier guidance and adds attention to issues such as focus visibility, target size, drag alternatives and accessible authentication experiences. For many teams, this means reviewing interaction design more closely, not just page content.
Yes. Cookie consent interfaces, privacy controls and other legal notices are part of the user experience and should be reviewed for keyboard access, focus management, labeling and clarity.
Teams should use it before audits, after major releases, during redesigns and as part of routine QA for critical templates and user journeys. The more frequently it is built into workflow, the easier it is to prevent recurring issues.
Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
TR
