Accessibility testing asks whether people with different abilities can perceive, understand and operate a website. It is not a single tool score and it is not complete when an automated scan reports no errors.

The Web Content Accessibility Guidelines (WCAG) provide testable criteria, but a useful review combines automation, expert manual checks and the experience of disabled users. This guide outlines a practical process for a small-business website.

Define the scope before testing

List the pages, templates and journeys that matter. Include:

  • homepage and navigation;
  • primary service or product templates;
  • search and filters;
  • contact, booking or checkout forms;
  • account or login flows;
  • articles and media;
  • consent controls;
  • error and confirmation states;
  • third-party widgets and embedded tools.

Select examples of repeated components rather than testing only the homepage. Dynamic states matter: an accordion while open, a form after an error and a menu at mobile width may expose issues not present in the initial view.

Choose the standard and target. WCAG 2.2 is the current W3C Recommendation, and Level AA is a common organisational target, but legal obligations vary by organisation and jurisdiction. Obtain appropriate legal advice rather than treating a checklist as a compliance guarantee.

Start with automated checks—but know their limits

Automated tools can quickly detect issues such as missing form labels, some colour-contrast failures, duplicate IDs and invalid accessibility attributes. Browser accessibility audits, linters and specialist scanners can all help.

Run more than one representative page and save the tool version, settings and date. Triage results rather than assuming every warning has the same severity.

Automation cannot reliably judge whether alternative text communicates the image's purpose, whether heading structure makes sense, whether focus order is logical or whether instructions are understandable. W3C explicitly notes that evaluation tools cannot do everything and require manual intervention.

An automated score is therefore a starting signal, not certification.

Test the site with a keyboard

Put the mouse aside and use Tab, Shift + Tab, Enter, Space, arrow keys and Escape where appropriate.

Check that:

  • every interactive control can be reached;
  • focus is clearly visible;
  • focus order follows a sensible reading sequence;
  • links and buttons can be activated;
  • menus, dialogs, accordions and tabs work predictably;
  • focus moves into an opened dialog and returns appropriately on close;
  • no component traps the keyboard;
  • a skip link allows repeated navigation to be bypassed;
  • hidden or disabled items do not receive focus unexpectedly.

Test mobile menus and consent tools too. Keyboard problems often reveal weak semantics that also affect assistive technology.

Review headings, landmarks and page structure

Inspect the document outline. The page should have a clear primary heading and a logical hierarchy that reflects content, not merely visual size. Do not choose heading levels to achieve a styling effect.

Use semantic regions such as header, navigation, main and footer appropriately. Landmarks help screen-reader users move around a page. Links should make sense in context; repeated “click here” labels make lists of links difficult to interpret.

Check the page title and declared language. Both provide essential context before someone reaches the visible content.

Test with screen readers

Use at least one common screen reader with a supported browser and learn its fundamental navigation commands. A quick test should cover:

  • page title, language and landmark navigation;
  • heading navigation;
  • link and button names;
  • form labels, requirements, errors and status messages;
  • menus and dialogs;
  • tables where used;
  • dynamic updates;
  • images and alternative text.

Do not treat a sighted person completing one scripted screen-reader pass as equivalent to testing with an experienced screen-reader user. It is still useful for finding obvious implementation errors, but lived expertise reveals different problems.

Assess images and media

Every informative image needs an appropriate text alternative. The wording depends on purpose, not appearance alone. A decorative image can use an empty alt attribute so it is skipped; a chart may need a concise alternative plus nearby data or explanation.

Avoid putting essential text inside an image. If a logo or branded graphic contains meaningful wording, provide an equivalent name.

Video should provide accurate captions for spoken content and relevant sound. Audio-only material needs a transcript. Where visual information is necessary to understand a video, consider audio description or an equivalent alternative. Check player controls with keyboard and assistive technology.

Check contrast and non-colour cues

Measure text and user-interface contrast with an appropriate tool. Do not judge contrast by eye. Test states including hover, focus, selected, disabled and error.

Information should not depend on colour alone. An error field outlined only in red needs a text message or another perceivable cue. Charts should combine colour with labels, patterns or shapes where needed.

Be careful with text placed over photography, gradients and video; contrast may vary across the background.

Zoom, reflow and resize

Zoom text and the page, and test a narrow viewport. Content should reflow without forcing horizontal scrolling in ordinary reading contexts, with recognised exceptions such as complex data tables.

Check that controls, labels and error messages remain visible; sticky elements do not cover content; and text does not become clipped. Browser text-size changes can expose components built with inflexible heights.

Test orientation where relevant and ensure touch targets can be used without precise movement. WCAG 2.2 includes updated criteria relevant to focus appearance, dragging and target size.

Test forms carefully

Forms are central to many commercial journeys. Confirm that every field has a persistent, programmatically associated label. Placeholder text alone is not a label.

Indicate required fields clearly. On error, identify the field, describe the problem and explain how to correct it. Move focus or provide a summary where this helps users find errors. Do not erase valid entries after one error.

Test autocomplete, time limits, date pickers and confirmation messages. Success or error updates should be announced appropriately to assistive technology without stealing focus unnecessarily.

Include disabled people in evaluation

Standards-based testing finds conformance issues; usability testing with disabled participants shows how the experience works in practice. Recruit people with relevant access needs and compensate them fairly.

Give participants realistic tasks rather than asking them to inspect criteria. Observe where the journey becomes confusing, slow or impossible. Avoid expecting one person to represent every disability or assistive technology.

Record and prioritise findings

For each issue, record:

  • page and component;
  • steps to reproduce;
  • user impact;
  • affected standard or criterion where relevant;
  • evidence such as screenshot or code snippet;
  • recommended correction;
  • owner and status;
  • retest result.

Prioritise blockers in critical journeys, widespread component defects and issues affecting many users. Fix the shared component rather than patching every page separately.

After remediation, retest the specific issue and nearby functionality. Accessibility regressions can be introduced by well-intended changes.

Make accessibility continuous

Add accessible components, editorial guidance and automated checks to the normal workflow. Include accessibility acceptance criteria in briefs, design reviews and quality assurance. Train content editors to write headings, link labels and alternative text appropriately.

Publish an accessible way for users to report problems and define who responds. Re-test after redesigns, platform upgrades and significant third-party changes.

FAQ

Can an automated tool prove that a site is accessible?

No. Automated checks find only issues that can be reliably detected by rules. Manual and user testing are required to assess context, usability and many WCAG criteria.

Do we need to test every page?

Test every distinct template, component and critical journey, plus a representative sample of content. High-risk or legally significant services may require a more comprehensive evaluation.

Is WCAG conformance the same as a good user experience?

Conformance provides an essential baseline, but people can still encounter usability barriers. Combine standards testing with research involving disabled users.

Accessibility is a quality practice, not a launch-day badge. If you need a structured review that connects findings to design, content and implementation, Yieldberg Studios can help build a practical remediation plan.

Sources

Continue reading