← Guide libraryWebsite experience, enquiries and handoffs · Resolution guide

Abrasim problem-resolution guide

Accessibility Barriers Are Reducing Discovery, Comprehension and Conversion

Find and remove accessibility barriers in important search journeys.

By Tafadzwa BoriwondoPublished 29 August 2026Evidence reviewed 29 August 2026

For: Website Owner, Product Owner or Accessibility Lead
Decision to make: Test WCAG 2.2 AA-relevant journeys, content structure and actions with qualified review where needed.
Scope boundary: Journey diagnosis and remediation; automated scans alone do not prove conformance.

Downloadable working pack · ZIP

Accessible Search Journey Review Pack

Fill in the workbook as you follow the guide. Keep each decision linked to its evidence, responsible owner, live-site checks and review date.

Download working pack

What to expect in the working pack

Start Here
Set the investigation scope, decision question, accountable owner, dates and working rules before changing anything.
Evidence Register
Capture each source, observation, date, owner, confidence limit and evidence gap without turning an assumption into a fact.
Diagnosis
Compare possible causes, record the evidence for and against each one, and identify which failed check needs action.
Action Plan
Assign an owner to each agreed action. Record dependencies, acceptance criteria, release controls and rollback conditions.
Verification
Record production proof, live tests, expected reporting lag, guardrails and the result against the original baseline.
Decision Log
Record the decision to proceed, change, investigate again or stop. Name who authorised it, the remaining risks and the next review date.

How to use it as you follow the guide

Before Section 1
Open Start Here. Name the exact problem, affected scope, decision owner and safe working boundary before gathering or changing evidence.
While working through Sections 1 and 2
Use Evidence Register for source facts and Diagnosis for competing explanations. Keep observations, interpretations and unknowns separate.
During Section 3
Move only the accepted cause into Action Plan. Assign an owner, dependency, acceptance test and rollback condition to every change.
During Section 4
Use Verification to compare the released result with the baseline. Record technical proof and later search or commercial movement as separate evidence.
During Section 5 and close-out
Use Decision Log to record what will proceed, change, reopen or stop. Name who will prevent the problem returning and when they will review fresh evidence.

Working rule: The workbook is a structured investigation record, not a pre-completed diagnosis or performance promise. Keep source evidence, uncertainty and decision authority visible throughout.

Start here

Agree what you need to find out.

Use this guide when you are responsible for resolving the problem described by “accessibility barriers reducing website conversion”. Check the cause before changing content, technology or the way the work is done.

Before you start

A representative user task, entry page and device context, plus a control journey that is known to work.
Access to analytics, form or call handling, CRM and operational response evidence where those systems are in scope.
Named owners for the page experience, conversion mechanism and downstream response handoff.

What you leave with

A dated evidence record for the problem described by “accessibility barriers reducing website conversion”.
A decision that answers: Test WCAG 2.2 AA-relevant journeys, content structure and actions with qualified review where needed.
An action plan with a responsible owner, live-site evidence, acceptance criteria and a follow-up date. State when to roll back the change or investigate again.

How to run every step

01Record the observation, source, date, scope and evidence owner before drawing a conclusion.
02Classify the statement as VERIFIED, INFERRED, PROPOSED or REQUIRES VALIDATION; do not silently promote an assumption.
03Name the result you need and who is responsible for each step. Record the decision it supports and any question still unanswered.
04After a change, record the live result and acceptance test. Keep source-code, preview and live-site evidence separate.
05Monitor search recovery and business results separately. If a check still fails, investigate that check again before repeating the whole method.

Accountable owner: Website Owner, Product Owner or Accessibility Lead
Operating action: follow the user from the page promise through the action and response. Check whether the problem is usability, technical failure or a missed handoff
Decision gate: Before making a change, check that the evidence supports this decision: Test WCAG 2.2 AA-relevant journeys, content structure and actions with qualified review where needed.
Acceptance evidence: a representative user can complete the task, and the enquiry or action reaches the correct workflow and responsible person. Keep evidence of both
Rollback or reopen when: completion falls, accessibility regresses, duplicate records are created or a working downstream path is interrupted
Scope boundary: Journey diagnosis and remediation; automated scans alone do not prove conformance.

What the problem looks like and why it matters

People must be able to find, understand and act on your information. Check the tasks that accessibility barriers prevent them from completing. Automated scans cover only part of the work; human evaluation and qualified review are also needed.

Test the important tasks people need to complete, including with keyboards and assistive technology where appropriate. Record the barrier, affected task and responsible owner, then verify the repair. Automated scores alone cannot establish accessibility.

What evidence distinguishes the real cause

Evidence	What to capture	Control
E-01	Priority search-to-action journeys and affected content or controls	Record source, date, scope, owner and confidence.
E-02	Automated findings mapped to WCAG 2.2 success criteria	Record source, date, scope, owner and confidence.
E-03	Keyboard, screen-reader, zoom, reflow, contrast and error-handling tests	Record source, date, scope, owner and confidence.
E-04	Content structure, language, labels and status-message evidence	Record source, date, scope, owner and confidence.
E-05	Severity, frequency, user consequence, component reach and remediation owner	Record source, date, scope, owner and confidence.

Classify evidence as VERIFIED, INFERRED, PROPOSED or REQUIRES VALIDATION. Keep consent, privacy, accessibility and unavailable-data limitations visible.

How to fix it step by step

Step 1: Define scope and standard

Set WCAG 2.2 AA as the target and identify priority journeys, technologies and known user needs.

Step 2: Run automated checks

Use tools for repeatable signals but retain raw evidence and avoid claiming full coverage.

Step 3: Test manually

Verify keyboard, focus, reading order, headings, names, roles, values, zoom and forms.

Step 4: Include assistive and user evidence

Use qualified evaluators and people with disabilities appropriate to the risk and scope.

Step 5: Prioritise systemic barriers

Score user harm, reach, task consequence, component reuse and remediation risk.

Step 6: Fix components and content

Repair the controlling pattern, preserve semantics and document exceptions.

Step 7: Retest acceptance and regression

Verify affected criteria, complete journeys and negative states before release.

For each action record owner, approver, dependency, production proof, acceptance test and rollback trigger. Test the complete route rather than approving a screen in isolation.

How to verify recovery

Accept when scoped success criteria have evidence, priority journeys complete across agreed modes and unresolved exceptions have owners and risk decisions. Roll back visual or interactive changes that create new barriers.

Use successful, failed and out-of-scope scenarios. Implementation acceptance, user recovery and commercial recovery are separate gates.

How to prevent the problem returning

Embed accessibility in design tokens, components, content standards and release tests. Train owners and schedule qualified audits. Reopen after major redesigns or framework changes.

Primary guidance reviewed at the 29 August 2026 source cutoff includes W3C technical standard and W3C Web Accessibility Initiative guidance. These standards guide testing but do not prove an outcome for a particular organisation.

Where the journey crosses search, content, experience, technology and sales ownership, Discuss accessibility priorities. The six value paths cross functional budgets, evidence and ownership; diagnosis therefore needs cross-functional authority, access and independent challenge, whether led internally or externally.

Use the method with AI

A prompt to help you work through this guide

Use this prompt to organise your analysis. Share only evidence you are authorised to provide to that model. A person must remain responsible for the decision, privacy limits and final action.

Copy and adapt

You are helping me apply the Abrasim problem-resolution guide: “Accessibility Barriers Are Reducing Discovery, Comprehension and Conversion”.

Situation: accessibility barriers reducing website conversion
Decision to make: Test WCAG 2.2 AA-relevant journeys, content structure and actions with qualified review where needed.
Scope boundary: Journey diagnosis and remediation; automated scans alone do not prove conformance.

Use only the evidence I provide. Do not invent facts, benchmarks, sources, outcomes, customer research or legal conclusions. Keep VERIFIED, OBSERVED, INFERRED, PROPOSED and UNKNOWN separate. Ask focused questions when the evidence or authority is missing.

Help me work through this method by returning:
1. An evidence table with claim, source, date, confidence and limitation.
2. The strongest competing explanations, including what would disprove each one.
3. Decision options with trade-offs, dependencies and the cost of waiting where evidence supports it.
4. The next smallest evidence-gathering action, its accountable owner and acceptance test.
5. A proceed, change, validate, defer or stop recommendation that a named human decision-maker can review.

Treat the attached Abrasim working pack as a blank working record. Do not fill missing rows with plausible data. Flag privacy/POPIA, security, accessibility, safety and authority issues. Cite primary sources for external claims and show uncertainty. End with the conditions that would make us change course or stop.

My organisation-specific evidence and constraints:
[Paste evidence, links, dates, decisions and limitations here]

Working rule: AI can help organise evidence and expose questions; it cannot establish truth, approve risk, make the business decision or replace qualified legal, privacy, security or accessibility review.