Plan a DIY Website Accessibility Check: Tasks, Evidence and Next Steps

Give the first pass a clear boundary

A DIY accessibility check is most useful when it produces a reproducible finding or a clear next test. An afternoon is a scheduling choice, not a guarantee that you can evaluate an entire site. Avoid estimating a universal percentage of issues that an automated tool will catch.

Choose one visitor task and the pages it touches. “Find our contact form and recover from an invalid entry” is a more testable brief than “check the website.” Use the step-by-step website accessibility self-check for the detailed method; this work plan helps organize the session and handoff.

Before the session: prepare the task and record

Write down the starting URL, intended outcome, page states, browser and site revision if known. Agree which actions are safe to complete. Prefer synthetic inputs in a test environment for submissions, bookings or purchases; do not send a real enquiry just to generate a success message.

Download the blank self-check record. Leave methods you have not completed marked not tested. Decide who can reproduce findings and make changes. If an area requires authentication or a third-party service, record that access dependency rather than treating its absence as a passing check.

During the session: separate the kinds of evidence

• Public HTML scan: retain the URL, timestamp, findings and tool scope. It does not establish script-driven states, contrast or completed tasks.
• Keyboard task: retain the keys, focus, visible result and any blocked step. It does not establish screen-reader speech or every input method.
• Form correction: retain invalid inputs, errors, retained values and the correction path. Successful delivery needs separate completion and verification.
• Screen-reader task: retain the tool/browser versions, commands and actual output. Results do not establish other combinations or the experience of all users.
• Visual/content review: retain the relevant image purpose, colors, zoom, state and observation. Other pages and states remain untested.

Our HTML scanner runs selected automated rules on fetched markup. It does not execute the page's JavaScript or measure contrast. A rendered-browser tool can inspect a different state, but still needs interpretation and manual follow-through. W3C explains the limits of evaluation tools.

A worked example from our own site

On October 19, 2026, our single-page HTML scan of the already-repaired contact page returned zero findings across 388 elements. The completed scan observation identifies the exact result and its limits. It did not exercise form validation or submission.

Our separate form review did exercise invalid entries. We recorded the errors and focus, added an upfront minimum-length instruction, and retested the relevant boundaries. An error disappearing during editing did not prove that the replacement value was valid; another validation attempt was needed.

We also have a real NVDA test record, but it concerns our heading validator, not the contact form. Keeping those scopes separate prevents a useful test from becoming an unsupported site-wide claim.

After the session: assign repairs and preserve gaps

For each finding, save the actual steps, expected and observed behavior, affected page/state and evidence. Prioritize by the barrier's effect on the visitor task and its reach, then assign an owner. If several tools flag the same issue, consolidate the underlying repair rather than adding duplicate tickets or assuming it is automatically the highest priority.

Repeat the same task after the fix and record the new revision. Check the released page separately from a local preview. Our audit-process guide shows a completed finding-to-retest example.

Where a result depends on unfamiliar screen-reader modes, complex widgets, media, documents or a business-critical process, involve someone with the relevant testing experience. Define the required coverage with an audit-scope brief; do not assume every professional audit includes the same pages or technologies.

Finish with an honest handoff: what was checked, what was observed, what was repaired and what still needs evidence. A self-check helps direct the next work. It does not certify ADA compliance, predict litigation or establish a conversion improvement.