- Can the page be used without a mouse?
- Is the content understandable and perceivable?
- How do repairs remain effective?
Can the page be used without a mouse?
Move through navigation and forms with the keyboard. Check that focus is visible and follows a meaningful order. Open menus and dialogs, then verify that users can complete or leave them without getting stuck.
Test the interactive states, not only the initial page. Error messages and success confirmations need to be understandable and available to assistive technology where appropriate.
Is the content understandable and perceivable?
Use descriptive headings and links, appropriate labels and meaningful alternatives for informative images. Check contrast and text resizing. Review media for necessary captions or other access requirements.
WCAG provides testable criteria, but a short checklist does not cover every criterion or context. State the version and evaluation scope rather than claiming blanket compliance from a score.
How do repairs remain effective?
Record the barrier, correction and retest. Check shared components across representative pages. Give editors guidance so new content does not recreate the same issue.
Dappr can scope practical accessibility review and implementation. This is not legal advice or certification; the assessment needs defined boundaries and qualified review for any legal conclusion.
Define the scope before using the checklist
Name the pages, components and customer tasks included in the review. Record the devices, browsers and assistive technologies used where relevant. A statement that a website was checked is incomplete without knowing which parts and conditions were actually examined.
Select the applicable standard and conformance target for a formal assessment. WCAG 2.2 provides testable criteria, but this article is a practical starting framework rather than a complete criterion-by-criterion evaluation. Legal conclusions require an appropriately scoped professional review.
Include representative complex states such as errors, menus, dialogs and submission feedback. A homepage screenshot does not show how a user completes the task. The checklist should follow the interaction, not stop at the first visible state.
Include at least one complete task in the review record rather than checking isolated controls alone. Note the starting page, intermediate states and completion feedback. This helps a second reviewer reproduce the experience and identify a barrier that appears only after several otherwise usable components are combined.
Check navigation and keyboard completion
Choose an important journey and attempt it without a mouse. Record where a control cannot be reached, focus becomes unclear or the order no longer matches the task. Test opening and closing interactive components, including returning to the page after a dialog.
Describe failures with reproducible steps. “The menu cannot be closed after opening it with the keyboard” gives the implementer a clearer task than “navigation is inaccessible.” Include the relevant page and state so another reviewer can confirm the issue.
After a repair, repeat the affected journey and a nearby use of the shared component. A fix that works in one dialog can leave another configuration broken. Keep the retest proportional to the shared behavior that changed.
Check structure, names and reading meaning
Review whether headings, links and controls communicate their purpose. An accessible name should help the user understand the action, and the reading structure should preserve the meaning of the content. Avoid relying on visual position alone to explain a relationship.
Inspect informative images and media for the alternatives required by their purpose. A decorative image and a diagram carrying essential instructions need different treatment. The review should consider what information would be lost if the visual or audio were unavailable.
Use appropriate tools and qualified manual review for semantic issues. A page can look organized while its underlying structure is confusing, and an automated result may not judge whether an alternative text description is actually useful.
Check forms through failure and recovery
Test the labels, instructions and the way errors are communicated. A visitor needs to know what information is requested and how to fix a problem. Do not evaluate only the successful submission path with a perfect sample entry.
Review whether entered information is preserved when correction is needed and whether the user can reach the affected field. Inspect confirmation messages and status changes with the relevant assistive-technology checks. The feedback should describe the actual result of the action.
Keep test data fictional and submissions authorized. Accessibility testing should not expose customer information or create confusing operational records. Coordinate the exercise with the responsible team when the flow triggers real notifications or other actions.
Check visual presentation under changed conditions
Review contrast, text resizing and content reflow using appropriate methods. A design that works at one default size may become difficult when a visitor increases text or uses a narrow viewport. Record the condition that exposes the barrier.
Inspect fixed elements and overlays together. A banner, header and chat control may each appear acceptable while their combined state covers the task. Include keyboard visibility and the position of error messages in the interaction review.
Do not rely on color alone to explain an important state. Check whether the meaning remains understandable when the visual distinction is unavailable. The exact criterion assessment belongs to the selected standard and review scope, not a general score.
Use automated findings as leads for investigation
Automated tools can identify some issues efficiently, but their output is not a complete accessibility verdict. Confirm the findings, investigate manual tasks and document the tool and configuration used. A high score should not erase a barrier observed during a real journey.
Prioritize by the effect on people and tasks, while retaining the requirements of the formal assessment. A blocked inquiry flow may need urgent attention. Cosmetic preference should not be confused with an accessibility defect without an identified barrier or criterion.
Keep false positives and unresolved questions visible. The report should explain why a finding was accepted, corrected or set aside. This makes the review useful to the implementer and avoids repeating the same investigation without context.
Create a repair record that can be verified
For each issue, capture the affected task, observed behavior, relevant criterion where assessed, correction and retest result. Name the owner and retain any limitation. A completed code change is not the same as a verified customer outcome.
Give content editors guidance on the issues they can reintroduce, such as unclear links or missing image context. Shared components also need maintenance when new variants are added. Accessibility work continues as the site changes.
Dappr can scope practical review and implementation around these records. The deliverable should state what was tested and what remains outside the assessment. Avoid claiming blanket compliance, legal clearance or universal usability from a short checklist.
An illustrative form repair
A fictional request form shows a red border after an error but gives no understandable explanation of what to change. The review records the failed task and the information missing from the feedback. The implementation adds an appropriate explanation and verifies access to it through the agreed testing methods.
The retest checks that the user can identify and correct the problem without losing the rest of the request. That is a concrete improvement. It does not establish that every other page or criterion has been evaluated, so the broader assessment boundary remains explicit.