When to request a risk assessment

A risk assessment answers a different question than an audit

A full WCAG audit produces a complete, criterion-by-criterion record of accessibility failures and the evidence to support each finding. A risk assessment answers a narrower, earlier question: what is the shape of the problem, how exposed are we right now, and what would it take to get to an acceptable position?

Leadership often needs the second answer before they can fund the first. A risk assessment compresses scope review, sample testing, severity estimation, and remediation sizing into a single artifact that decision-makers can read in one sitting. It does not replace an audit, but it tells the team whether one is warranted, where to focus it, and what to expect from the work that follows.

What this helps with

• Best for: leadership, legal, and product teams who need a defensible read on accessibility exposure before committing budget or timelines.
• Outcome: a short briefing that names the priority surfaces, the severity of likely failures, the remediation effort range, and the recommended next step.
• Use when: the team has a feeling that accessibility risk is real but does not yet have the evidence to plan a response.

Planning principle: a risk assessment is for sizing the problem. An audit is for documenting it. Run the assessment when the question is "how much" or "how urgent", not "exactly which criteria fail".

Signals that it is time to request one

Most teams notice the same signals before they commission an assessment. The signals are rarely a formal complaint on day one. They are usually a combination of stakeholder pressure, internal uncertainty, and upcoming events that make the lack of an answer uncomfortable.

• A buyer, partner, or government program has asked for an ACR, VPAT, or accessibility statement.
• Legal or risk has surfaced concern after coverage of an accessibility lawsuit or settlement.
• A new product, brand refresh, redesign, or platform migration is about to launch.
• An overlay or scanner tool has produced numbers leadership does not know how to interpret.
• A user complaint, support ticket, or social post has named a specific accessibility barrier.
• An internal champion needs evidence to make the case for funding remediation.

What a risk assessment usually covers

The scope is intentionally narrower than an audit. The goal is to produce a defensible read in days, not weeks, by sampling the most consequential surfaces and patterns rather than testing exhaustively.

• Priority surfaces: the highest-traffic, highest-revenue, or highest-risk flows on the product.
• Representative components: the navigation, forms, tables, modals, and media patterns that recur across pages.
• Sample testing: targeted manual checks across keyboard, screen reader, focus, contrast, forms, and visual content.
• Severity estimation: a read on how many barriers are blocking versus inconvenient, and how concentrated they are.
• Remediation sizing: a directional estimate of engineering effort, sequencing, and the surfaces that would benefit first.
• Recommended path: whether the next step is a full audit, targeted remediation, an ACR engagement, or program-level work.

What it does not do

A risk assessment is not a substitute for an audit and it does not produce conformance evidence. Setting that expectation up front prevents confusion later, particularly with legal and procurement stakeholders who may treat the assessment as a complete record by mistake.

• It does not document every WCAG failure on every page.
• It does not constitute a conformance claim or an ACR/VPAT.
• It does not replace manual audit coverage required for defensible compliance.
• It does not commit engineering to specific dates or scopes without further planning.

What leadership receives

The deliverable is intentionally short. It is meant to be read by people who do not specialize in accessibility and used as the basis for a funding, scoping, or timing decision.

• Executive summary: a plain-language read on the level of exposure and the recommended next step.
• Priority findings: the barrier patterns most likely to affect users and most likely to trigger complaints.
• Effort range: a directional estimate of remediation work, expressed as ranges rather than precise hours.
• Next-step options: a short menu of paths forward with the trade-offs of each.
• Open questions: what the assessment could not answer with confidence and would require an audit to resolve.

When to skip the assessment

An assessment is the wrong tool when the team already has enough information to move. If a recent audit exists, if a demand letter has already arrived with specific allegations, or if leadership has already committed to a full remediation program, the assessment will repeat work the team has already paid for.

In those cases the right next step is usually direct audit work, remediation planning, ACR drafting, or legal coordination, not a sizing exercise.

How to make the request

The fastest path is a short conversation that establishes the products in scope, the deadline driving the question, and the stakeholders who need to read the result. From there the team can confirm a sampling plan, agree on the deliverable format, and define what would count as a clear answer.

Most assessments complete within a week or two depending on the size of the surface area. The output is sized to be useful to leadership without committing the team to a specific remediation path until the answer is in hand.

Conclusion

A risk assessment is the right next step when the team needs a defensible read on accessibility exposure and the evidence to plan a response. It compresses scope review, sample testing, and remediation sizing into a single artifact that supports a decision without pretending to be a full audit. When leadership needs a clear answer fast, the assessment is usually the shortest path to one.