Turn five web pages into an accessibility remediation backlog

An automated accessibility scan is useful evidence. It is not yet a remediation
backlog.

Raw results tend to mix repeated component defects, isolated page issues, and items
that still require human judgement. Teams can then end up estimating a number of rule
instances instead of the work needed to improve the product.

A focused five-page triage pass is a practical way to reduce that noise. It will not
establish conformance, but it can help a web team decide what deserves deeper
investigation and what should be fixed first.

Here is the workflow.

1. Choose pages by behaviour

Do not simply pick the five most visited URLs. Pick pages that expose different
templates, components, and states:

• the home page;
• a representative content or listing page;
• a form or other important user journey;
• a page with repeated cards, navigation, filters, or tables; and
• an error, help, account, or support state.

Five marketing pages built from the same template will usually teach you less than a
smaller set chosen for structural variety.

Record each exact URL, a short stable label, and the date tested. If you configure a
runner from JSON, keep the input deliberately boring:

{
  "pages": [
    { "slug": "home", "label": "Home", "url": "https://example.com/" },
    { "slug": "search", "label": "Search results", "url": "https://example.com/search" },
    { "slug": "contact", "label": "Contact form", "url": "https://example.com/contact" }
  ]
}

Only test pages and states you are authorised to evaluate. Do not use real customer,
financial, health, or account data in forms.

2. Capture rendered evidence

Run an automated ruleset against the rendered page rather than only inspecting the
original HTML. For every result, retain enough context to reproduce it:

• the rule and reported impact;
• the affected element or selector;
• the tool's explanation;
• the page and test date; and
• a desktop and narrow-screen screenshot where useful.

Keep incomplete or needs-review results separate from confirmed failures. They are
questions for a reviewer, not automatic defects.

Two interpretation rules prevent a lot of bad reporting:

1. A zero-violation scan does not prove that the page is accessible.
2. A high violation count does not tell you how many engineering tasks exist.

Automation is strongest at collecting repeatable evidence. It cannot determine every
meaningful alternative, whether focus order matches the task, whether an error message
is understandable, or whether a control's name is useful in context.

3. Add a short human pass

Use the same small checklist on every selected page. At minimum, check:

• keyboard access, focus visibility, and focus order;
• page title, headings, landmarks, and page purpose;
• form labels, instructions, validation, and error recovery;
• whether links and buttons make sense in context;
• image alternatives and decorative-image treatment;
• zoom, reflow, and operation at a narrow viewport;
• contrast and information communicated by colour;
• dialogs, menus, disclosures, and other state changes; and
• time limits, motion, audio, or video when present.

Give each check an explicit status such as pass, issue, not present, or
needs specialist follow-up. Never turn “not tested” into an implied pass.

This is also where scope boundaries become visible. Documents, media, authenticated
flows, native applications, assistive-technology compatibility, and disabled-user
research may require separate work.

4. Group by shared cause

Suppose the same navigation control has an inaccessible name on all five pages. That
is normally one component-level remediation task with five observed contexts, not five
unrelated tickets.

Group findings using the likely implementation boundary:

• shared navigation or footer;
• design-system control;
• form pattern;
• card or listing component;
• content-authoring issue; or
• page-specific defect.

This makes estimates more honest. The team can fix the shared cause once, then retest
every affected context. It also avoids inflated issue counts that make reports look
larger without making them more useful.

5. Prioritise impact, reach, and journey importance

A simple first-pass order is:

1. blockers in an essential journey;
2. keyboard, focus, form, and error-recovery failures;
3. defects in global or frequently reused components;
4. issues affecting comprehension, zoom, or narrow-screen use; and
5. isolated lower-impact defects.

Severity alone is not enough. A moderate defect in the main navigation may deserve
attention before a severe defect in an obscure, unavailable state. Record both user
impact and reach so the product owner can see the trade-off.

6. Write tickets that can be retested

Keep observation and recommendation separate. A compact issue can use this structure:

Title: [component] — [observed barrier]
Evidence: [page, state, selector, screenshot or rule output]
User impact: [who is affected and what becomes harder or impossible]
Reach: [pages, templates, journeys, or component instances]
Reference: [relevant WCAG success criterion, when reviewed]
Recommendation: [implementation direction, not a claim of the only valid fix]
Retest: [clear steps and expected result]

That final retest condition matters. “Improve accessibility” cannot be verified;
“using only the keyboard, focus reaches the menu button, remains visible, opens the
menu, moves through each item, and returns predictably when closed” can.

What the five-page pass can and cannot say

The result is a sampled triage and prioritisation aid. It is not certification, legal
advice, a complete WCAG conformance evaluation, or proof that every barrier was found.

Its value is narrower and more concrete: it turns a mixed pile of machine output and
human observations into a smaller set of reproducible, component-aware tasks. That is
usually a much better starting point for remediation planning.

---

Disclosure: Five Page Focus publishes a paid local toolkit that implements this
workflow with pinned Playwright and axe-core dependencies, a manual checklist, report
templates, and a completed five-page demonstration. The method above is complete and
usable without buying it. If a packaged version would save your team setup time, you
can view the £29 kit on Gumroad.