How to do a first website accessibility review

Choose pages and tasks before testing

Start with the homepage, a typical content or service page, the contact form and any important booking, search or purchase journey. Include a page with unusual features such as a menu overlay, video or interactive tool. Record the address, date, browser and device so another person can repeat the review.

Choose tasks a visitor actually needs to finish: find a service, open its details and send an inquiry, for example. Include open menus, validation errors and confirmation states. Reviewing only the first screen misses much of the experience.

• Download the blank accessibility issue log (CSV)
• Download a fictional review example (Markdown)

The CSV starts with an unfilled Not checked row. Duplicate it for findings; an empty log is not evidence that a page passed. Keep a separate scope note listing the pages, states and checks completed, including anything you could not review.

W3C's Easy Checks describes this kind of review as a starting point. A page can pass a small set of checks and still have significant barriers. This guide produces a practical issue list, not a WCAG conformance assessment or a legal certificate.

Follow the visitor path with a keyboard

Put the pointer aside. Use Tab to move forward and Shift + Tab to move back through interactive elements. Use Enter for links and Enter or Space for ordinary buttons. Arrow keys are normal inside some controls, such as radio groups; every item need not be a separate Tab stop. Browser and operating-system keyboard settings can affect which controls receive focus, so record them when relevant.

• Can you reach and operate the navigation, forms and important actions?
• Can you see where focus is, including on a busy background?
• Does the order make sense, and can you leave every control or opened panel?
• Do sticky headers, banners or dialogs cover the control you are using?

For a menu or dialog, check its open, inside and closed states. After closing it, confirm focus returns somewhere useful. A dialog can intentionally keep focus inside while open, but there must be an accessible way to close it. Note the exact control and keys where progress stops.

These checks follow W3C's guidance on keyboard operation and visible focus. A mouse click reaching the same destination does not resolve a keyboard barrier.

Enlarge the page and check reflow

Use the browser's zoom control to reach 200%, checking intermediate settings too. Repeat the main task. Look for clipped labels, overlapping text, hidden buttons and messages that disappear outside their containers. W3C's Resize Text guidance addresses enlarging text to twice its size without losing content or functionality.

Then inspect a narrow layout. For a typical vertically scrolling page, W3C's Reflow criterion uses a width equivalent to 320 CSS pixels. One way to reach that is a 1280 CSS-pixel-wide content viewport at 400% zoom. A browser's responsive preview can also set a 320 CSS-pixel viewport; record the actual setting, not just the device name.

Ordinary paragraphs and controls should fit without repeatedly scrolling sideways to read them. Some content, such as a data table or map, genuinely needs a two-dimensional layout; that exception does not cover the whole page. Check that surrounding text still reflows and controls remain reachable. A narrow screenshot alone cannot show that an interaction works.

Responsive design helps adapt the layout, but it still needs these usability checks. Include at least one real phone when practical, especially for menus, forms and on-screen keyboards.

Review the page title and heading outline

Read the browser-tab title and the visible headings. They should identify the page and explain its sections. Text made large or bold is not automatically a heading in the page's markup.

Open the Heading Structure Checker and paste the relevant HTML, or enter the actual H1–H6 levels manually. Choose Analyze headings, then compare the outline with the page. A manually entered list checks the list you supplied; it cannot confirm how the website is coded.

Look for empty headings, unclear labels and subsection levels that do not match the content. For example, an H2 called Services can contain H3 headings for each service. Returning from an H3 to another H2 begins a new section. W3C's headings tutorial explains this hierarchy. An H1 count or skipped-level warning is a prompt to inspect context, not an automatic verdict on the page.

The checker reads native headings from supplied content. It does not run the site's scripts or reproduce its full accessible structure. For a page that builds content after loading, ask the maintainer for the relevant rendered markup and compare the result with the working page.

Measure contrast in the relevant states

Collect the text and background colors from the page's styles or ask the designer for the actual values. Enter a solid foreground/background pair in the Color Contrast Checker. Do this for body text, links, labels, error messages and the states people encounter while using the page.

Under WCAG's AA text criterion, ordinary text needs at least 4.5:1 contrast; large text needs at least 3:1. Large means at least 18pt regular or 14pt bold, approximately 24 or 18.7 CSS pixels. If unsure about the size, use the ordinary-text threshold for this first review.

The checker compares opaque, solid sRGB colors. It cannot evaluate a gradient, translucent layer or photograph as a single background, or establish that every interactive state is usable. Record those cases for further review. Required control visuals and meaningful graphics have a separate non-text contrast criterion; do not apply the large-text result to all interface elements.

Check what images communicate

Review each image in context. An informative image needs a text alternative conveying its useful meaning. A purely decorative image can use an empty alt="". An image acting as a link or button needs an accessible name that describes the destination or action. Charts may also need their information explained in nearby text or a data table.

Use the alt text definition and W3C's alt decision tree to decide what belongs. The same photograph can be informative on one page and decorative on another.

The HTML Accessibility Checker can flag missing image alternatives and other common markup issues. Paste or upload a safe copy of the relevant HTML, then inspect the reported locations. A missing attribute is detectable; whether the wording communicates the right meaning needs human judgment. The checker handles supplied text locally and does not fetch the URL, execute scripts or inspect the page's CSS.

Try form instructions and errors

Read the form before typing. Each field needs a clear purpose, and required fields and format instructions should be understandable. A placeholder that disappears during entry is a poor substitute for a persistent visible label. W3C's labeling guidance also explains the programmatic association between a label and its control; visual proximity alone does not establish that connection.

Agree a safe test with the site owner first. Use fictional data and a supported test environment for actions that send messages, book appointments or take payment. A staging address does not by itself mean its connected services are isolated.

1. Leave a required field blank or enter a clearly invalid value, then follow the agreed test process.
2. Check whether the message identifies the field and explains how to fix it, instead of relying only on a red border.
3. Use the keyboard to find the error, correct it and continue. Check that previously entered information is preserved where appropriate.
4. Check the successful state too: can the visitor tell what happened and what comes next?

W3C's form notification guidance covers clear error and success feedback. Visible feedback also needs to be conveyed to assistive technology. If no screen-reader review was performed, record that as Not checked; a visible message does not prove it was announced. The HTML checker cannot exercise submission, focus movement or live announcements.

Turn findings into reproducible work

Give each issue its own row. Include the page and state, browser/device, viewport and zoom, steps, expected behavior, observed barrier and its effect on the visitor. Attach a useful evidence reference without exposing submissions, account details or other private information.

Assign an owner, next action and target date. Prioritize by impact: a visitor unable to complete the main task needs attention before a minor inconvenience. These are work priorities, not WCAG levels. Use Open, In progress, Ready for retest and Closed consistently; use Not checked where evidence is missing.

After a fix, repeat the original steps in the same conditions and inspect any shared component affected elsewhere. Record the change reference, retest date and result. If the original barrier remains or a new one appears, keep the issue open. Closing one issue does not mark the page or website as accessible.

Decide what needs a deeper review

Summarize what was checked, what was found and what remains unknown. This first pass does not cover every criterion or combination of assistive technology, browser and interaction. Video, complex widgets, authentication, purchasing and dynamic content can need more detailed evaluation.

For a broader assessment, plan work with an experienced accessibility evaluator and involve people with disabilities using relevant tasks. W3C provides guidance on involving users in evaluation. User feedback and technical review complement each other.

Repeat relevant checks when shared navigation, colors, templates or forms change. Add the issue log to the website maintenance record, and use the publishing checklist before releasing a revised page.