WebInclusiveby Giuseppe Stumbo

Assessing a website

People must be able to search, read or submit a request on your website. This guide helps you select journeys to test, recognise barriers and document what you find.

Prepare and perform checks

Before using tools, clarify what you want to know: where someone gets stuck, which changes to check or what evidence to gather.

  • Scope

    Define scope, requirements and exit criteria

    Decide which pages and functions to check: this is the assessment scope. A pre-release check may cover a complete journey; assessment of a change may focus on the affected component and related journeys.

    • Specify domain, environments, excluded pages, authentication, languages, breakpoints and assistive technologies to use.
    • Connect the pages and functions to assess with the expected outcome: a risk list, tasks to assign, report, statement, ACR or remediation plan.

  • Sampling

    Build a representative sample

    If you do not check every page, choose a representative set, called a sample. Include different layouts, components and states: twelve similar pages may not cover search, purchasing, form errors and confirmations.

    • Include the home page, navigation, search, forms, lists, detail pages, documents, errors and dynamic states where present.
    • Record why each page is included in the sample: template, frequency of use, risk, information obligation or critical function.

  • ACT

    Define applicability and expected results

    ACT Rules describe what to assess, when a test applies and what result to expect. Use the examples to compare your procedure and also record cases that are not applicable or not assessed.

    • Check the rule's status: approved, proposed or deprecated.
    • A positive rule result alone does not demonstrate conformance with the WCAG criterion.

  • Test

    Combine tools, manual checks and human judgement

    Combine automated scanners, keyboard tests, screen readers, semantic inspection and task testing. For example, a scanner may detect a missing text alternative, but assessing its adequacy requires consideration of content and context.

    • Use automated checks to find recurring patterns, but manually validate focus, accessible name, role, state and messages.
    • Where possible, involve people with disabilities or use real feedback to understand impact beyond the technical error alone.

  • Validation

    Distinguish HTML validation, scanners and E2E tests

    Nu Html Checker validates markup; a scanner such as axe can detect a button without an accessible name; the accessibility tree exposes name, role and state. E2E tests verify implemented scenarios: none of these tools alone establishes WCAG conformance.

    • Nu Html Checker finds markup errors; DevTools helps inspect names, roles and properties exposed by the browser.
    • Evaluate each tool alert: it can suggest what to check, but does not alone demonstrate conformance or the absence of barriers.

From the audit report to retesting fixes

Document findings, plan remediation and verify fixes through traceable retests. Update issue status and the regression suite: closing a defect does not establish conformance of the entire website.

  • Components

    Check ARIA, focus and the design system in reusable components

    Barriers in shared components can spread across many pages. For example, a modal dialog with incorrect focus containment can reproduce the defect in every journey using it.

    • Use native HTML where it provides the semantics and behaviour; add ARIA only where needed, with correctly updated states.
    • Keep accessible examples, prohibited patterns, acceptance criteria and minimal tests in the design system to prevent regressions across pages.

  • Findings and triage

    Document findings and prioritise remediation

    A finding documents an audit result. Triage assesses its impact, severity and priority: a non-conformance requires an applicable WCAG criterion that is not met. For example, “the Confirm button cannot be reached by keyboard at checkout step 2” is reproducible; “the checkout is not accessible” is not sufficient.

    • Describe steps, observed behaviour, expected behaviour, WCAG criterion, severity, page and technology used.
    • Keep diagnosis separate from the possible solution so the team can choose the most suitable fix.

  • Retesting and regression

    Retest and define the regression suite

    Retesting (confirmation testing) verifies resolution of a defect on the corrected build. Regression tests assess the effects of changes on existing functionality: they are not synonyms. For example, after a dialog focus fix, retest the defect and related journeys.

    • Define which issues need another manual assessment, which need only quick checks and which tests to repeat to prevent recurrence.
    • When a barrier recurs across templates, assess the shared component and establish a checking frequency.

  • Knowledge base

    Turn recurring errors into reusable knowledge

    Turn recurring errors into checks your team can reuse. For example, if filters repeatedly lack labels, add that check to the checklist rather than treating every case as an isolated issue.

    • For each frequent pattern, retain what to check, how to test it and what expected behaviour to document.
    • Update shared documentation when a new assessment shows that a fix does not work on other pages or component states.

Sources and tools to open during assessment

Official references for setting up the assessment: initial checks, sampling methodology and report structure.