Website Accessibility Check: A Practical First Audit - Yenra

Review a real website task, identify access barriers, and turn findings into repair and retest steps.

An ivory keyboard faces a navy browser panel with an amber focus outline beside a glass magnifying lens.
A useful accessibility review follows the task a visitor is trying to complete.

A first accessibility review should end with specific problems that someone can reproduce and fix. Choose an important task—finding information, booking an appointment or submitting an application—and follow it from entry to confirmation. You will need a browser, a keyboard, permission to test any submissions, and a place to record results. This guide helps you organize that first pass; a full conformance evaluation requires broader coverage and expertise.

Choose the task and record the conditions

Write down the starting URL, intended outcome, browser and operating-system versions, device, date, and any assistive technology used. Use a test account and fictional information where a process changes records or sends messages. Include the pages reached after an error, an expired session or an empty search result: those states are part of the experience.

For a small site, sample each distinct page template plus its main interactive journey. For a larger service, inventory templates, components, languages and account roles before selecting a sample. Record what you left out. The W3C evaluation overview explains the difference between initial checks, comprehensive evaluation and user involvement. An automated scan supplies useful leads; human evaluation establishes whether people can actually use the service.

Follow the journey with a keyboard

  1. Reload the starting page and put the pointer aside. Press Tab and Shift+Tab to move among controls. Confirm that you can see the current focus and that its sequence makes sense.
  2. Activate links and buttons with their expected keys. For menus, radio groups and other widgets, use the documented keyboard interaction; arrow keys often move inside a component.
  3. Open a menu or dialog, complete its task, and close it. Check where focus goes after opening and closing. A hidden control or background overlay should not make the next step impossible.
  4. Submit a deliberately incomplete form in a safe test environment. Find the error, understand the correction and reach the affected field. Preserve any observations about lost information or unexpected focus movement.

If you become stuck, record the last working step and the first failing control before using the mouse to continue. This preserves a reproducible report. A keyboard check and a screen-reader check answer different questions; ask a proficient screen-reader user or tester to examine names, roles, states, reading order and announcements.

Inspect information and presentation

Use W3C Easy Checks as a starting reference for titles, headings, image alternatives, focus and text resizing. Look for a page title that identifies the page and headings that explain its organization. Ask whether each meaningful image has an equivalent explanation; decorative images should stay out of the reading flow.

At 200 percent browser zoom, inspect menus, notices and form controls for clipped text. Also test a narrow viewport and reflow: a visitor should be able to read ordinary paragraphs without repeatedly panning sideways. Record the exact viewport and zoom instead of saying only “mobile failed.” Data tables and other genuinely two-dimensional content need a usable way to inspect their full extent.

Measure foreground/background contrast with a suitable tool. The WCAG 2.2 reference specifies 4.5:1 for normal text and 3:1 for qualifying large text, subject to its stated exceptions. A successful contrast measurement establishes that color pair, not the entire page's accessibility.

For a form, read labels and instructions before typing; then verify required-field and error information. The W3C forms tutorial explains label associations, grouping and feedback. For media, check captions for accuracy and useful speaker/sound information, and establish how essential visual information reaches someone who cannot see it.

Write a finding that leads to a repair

Prioritize by the task blocked, the number of places affected and the availability of an effective alternative. Assign an owner and a retest condition. A shared navigation failure may warrant attention before an isolated decorative problem. Use the plain-text accessibility review log to record findings without requiring a particular tool.

Retest the journey and widen coverage

Repeat the original steps in the same environment, then inspect related components that share the repaired code. Include people with disabilities in the evaluation plan and arrange suitable participation and compensation. Keep unresolved issues visible with an owner and next review date. Report exactly which pages, states and methods were tested; a clean scan or a completed checklist is insufficient evidence for a blanket compliance claim.

Continue exploring