Accessibility is not a decorative layer applied after a page is complete. It determines whether people can perceive content, operate controls, understand information, and use the page with different devices and assistive technologies. The World Wide Web Consortium’s Web Accessibility Initiative publishes standards and a set of Easy Checks for an initial review. W3C is explicit that these checks are not exhaustive: a page can appear to pass them and still contain significant barriers. Their value is to catch common publishing failures early, create evidence for fixes, and show where a fuller standards-based evaluation and involvement of disabled users are needed.
Start with purpose, scope, and a representative sample
Write down the audience, primary tasks, technologies, and standard or policy that applies. Select pages representing templates and risk: the home page, navigation, article, search, form, account flow, error state, media page, and any custom interactive component. Include narrow and wide screens and supported browsers. A single perfect landing page does not establish accessibility for a checkout or application workflow.
Record the page address, date, browser, operating system, viewport, zoom level, assistive technology if used, and authentication state. Preserve the exact steps that expose a barrier. Report what happened and what was expected rather than assigning a person’s disability as the cause. An issue such as “focus disappears after the menu opens” is reproducible; “keyboard users cannot use the site” is broader than one observation can prove.
Put the mouse aside and follow the focus
Begin at the address bar and use Tab, Shift+Tab, arrow keys, Enter, Space, and Escape as appropriate. Every interactive control should be reachable, its focus indicator should remain visible, and the order should follow the visual and logical task. Ensure focus does not become trapped in a component and that opening a dialog moves focus appropriately and closing it returns focus sensibly. Test the skip link and confirm that it moves to the main content rather than merely changing the address fragment.
Activate menus, accordions, carousels, forms, media controls, and dismissal buttons. Hover-only information needs another accessible route. A custom element that looks like a button should provide button semantics and keyboard behavior; adding a tab stop alone is insufficient. Check that sticky headers do not cover focused content. Repeat essential operations at high zoom and on a narrow viewport because reflow can reorder or conceal controls.
Inspect structure, text alternatives, and visual presentation
Confirm that each page has a descriptive title and identifies its primary language. Read the headings as an outline: levels should communicate the content hierarchy rather than merely produce a desired font size. Link text should make sense in context, and repeated links named “click here” should not force readers to reconstruct destinations. Turn off images or inspect accessible names. Informative images need alternatives that convey their purpose; decorative images should be ignored by assistive technology; complex charts need equivalent information beyond a short label.
Check text and meaningful interface contrast with an appropriate measurement tool, including hover, focus, disabled, and error states. Do not use color as the only indication of status. Zoom text and the page according to the applicable requirements and observe clipping, overlap, horizontal scrolling, and controls that disappear. Motion, flashing, autoplay, and time limits require special attention because they can create serious barriers, not simply annoyance.
Test forms, errors, and media as complete tasks
Every form control needs a visible, programmatically associated label or another appropriate accessible name. Instructions should appear before they are needed, required fields should not rely only on color, and autocomplete purpose should be supported where applicable. Submit the form empty and with invalid values. Errors should identify the field, explain the correction, remain discoverable by assistive technology, and preserve valid entries so the user does not start again.
Check captions for prerecorded video, transcripts for audio where required, and audio description or an equivalent treatment when essential visual information is not conveyed in the soundtrack. Play the media rather than trusting the presence of a caption button. Captions need accurate speech identification and meaningful non-speech audio, not only automatically generated words. Ensure controls have names and can be operated by keyboard. A downloadable document linked from an accessible page is still part of the user journey and needs its own review.
Combine tools, human judgment, and disabled-user feedback
Automated tools efficiently identify some missing names, invalid relationships, and contrast problems. They cannot determine whether alternative text communicates the right meaning, whether heading choices make editorial sense, or whether a workflow is understandable. Review the underlying markup and accessibility tree where appropriate, test with representative assistive technologies, and involve disabled users in evaluating real tasks. One screen reader and one tester do not represent every access need.
Prioritize barriers by impact, task importance, reach, and recurrence across templates. Fix the component or content process that created repeated failures, then retest the original steps and nearby behavior. Document unresolved issues, owners, target dates, and available alternatives without presenting the alternative as permission to leave the main experience inaccessible. A first review supports action; it is not a conformance certification. The defensible report names the scope, methods, observed results, limits, and next evaluation step so another reviewer can reproduce the work.
REFERENCES
Sources and further reading
- 01W3C WAI: Easy Checks—A First Review of Web Accessibility
- 02W3C WAI: Accessibility Principles
- 03W3C WAI: Involving Users in Evaluating Web Accessibility
External links support verification and further reading; they do not endorse every statement at the destination. Accessed September 2026.