1. Define the review scope
Start with complete outcomes, not random URLs. Map the home page, key content, search, contact, account, booking or checkout, confirmation, help, and every embedded service used on the route. Include reusable navigation, modals, cookie controls, and forms because one defect can repeat across the site.
Record the WCAG version and level, coverage, browsers, devices, and known exclusions.
Review every step and state, including signed-in, empty, and error views.
2. Test the keyboard path
Complete each selected task without a pointer. Tab and Shift+Tab through links, controls, dialogs, menus, filters, date pickers, media, and vendor widgets. Focus should be visible, follow a sensible order, never get trapped, and return to a useful place after a dialog closes. Keyboard operation is central to WCAG; do not assume a custom mouse control works by keyboard.
Provide and test a way to reach main content without tabbing through repeated navigation.
Where an interface needs dragging, review whether an applicable non-drag alternative is available.
3. Check structure and clear meaning
Give pages descriptive titles and use headings for hierarchy, not appearance. Check that controls expose a useful name, role, and state to assistive technology; native HTML controls often reduce risk. Meaningful images need concise alternative text for their purpose, while decorative images should not add noise. Do not use color alone for status or instructions, and identify the page language.
Make destinations or actions understandable in context; repeated vague links create ambiguity.
When layout changes or styles are unavailable, content and controls should still read logically.
4. Stress text, layout, color, and media
Increase browser zoom and text size, then repeat key tasks. Content should remain readable and usable rather than collide, disappear, or become an unintended horizontal hunt. Check the actual color pairs for text, controls, focus, errors, and charts in relevant states. For recorded media, provide captions for needed audio information and text alternatives appropriate to the content.
Include hover, focus, disabled, error, and any dark or alternate visual state.
Keyboard-test the player as well as captions, transcripts, and essential visual information.
5. Make forms and account tasks recoverable
Submit missing, malformed, and valid data through your highest-value forms. Inputs need persistent, programmatically associated labels; placeholders alone are not a reliable substitute. Identify required fields before submission, explain what is wrong in plain language, point to the field, and preserve entered data where possible. Test sign-in, password reset, one-time codes, checkout, and confirmation as journeys.
Pair error color with a plain-language message and an identifiable affected field.
Keyboard-test the handoff, redirect, failure path, and return from payment or identity providers.
6. Combine tools with people and manual review
Run an automated checker on representative pages and use its findings as leads, not a pass certificate. Tools cannot judge whether alternative text is meaningful, an order makes sense, instructions are understandable, or a journey works with assistive technology. Add manual keyboard and zoom checks plus a targeted screen-reader review. When possible, involve people with relevant lived experience early and compensate them fairly.
Save tool output, reviewer notes, decisions, remediation, and retest results in one issue record.
Use a qualified evaluator for formal claims, regulated services, complex applications, or disputed results.
7. Build remediation into releases
Accessibility can regress after a theme, campaign, plugin, script, design-token, or vendor change. Add a proportional review to design, content, quality assurance, and launch work. SIU focuses on proactive uptime optimization and remediation: maintain a pre-launch path, identify customer-facing defects, make safe fixes, and use a rollback plan when needed. Accessibility review complements that work; it is not replaced by availability checks or outage alerts.
Block a release when a primary task cannot be completed by keyboard or a critical error cannot be understood.
Check the original task, mobile and error states after a fix before closing the issue.