AccessReady

Public documentation

Methodology notes

How the AccessReady triage works

Methodology notes

Purpose

These notes explain how the public tool produces its outputs:

  • applicability triage
  • starter checklist
  • starter accessibility statement

The goal is to make the logic understandable to users without presenting the tool as legal advice or a full audit.

Output model

The tool produces three linked outputs.

1) Applicability triage

The tool uses structured user inputs to place the case into one of four broad outcome bands:

  • Likely covered
  • Possibly covered
  • May need legal review
  • Likely not covered

This is a practical classification model for first-pass review.

It is not a legal determination.

2) Checklist

The tool turns the user inputs into a starter checklist covering areas that commonly matter for accessibility planning.

The checklist is tailored by product/service type, delivery channel, and declared features.

It is intended to support internal action planning.

It is not an audit report.

3) Starter accessibility statement

The tool generates a draft statement structure using the user inputs and the classification outcome.

This draft is intended as a starting document only.

It should be reviewed and edited before any publication or compliance use.

Inputs considered

The triage logic is based on a limited set of user-provided facts, such as:

  • market or geography
  • organisation role
  • product or service type
  • delivery channel
  • target audience
  • whether the offer is public or internal
  • whether the offer is commercial
  • sector/use case
  • relevant features that may affect accessibility
  • current accessibility work already completed

The tool assumes these inputs are accurate as entered.

How classification works

The classification is based on pattern matching against high-level applicability signals.

Stronger “covered” indicators

Examples of indicators that may push a case toward Likely covered:

  • the offer is made in the EU market
  • the offer is consumer-facing
  • the offer appears to fit a commonly discussed EAA-relevant product or service category
  • the offer is publicly available rather than internal-only
  • the service includes key user transactions or access flows

Ambiguity indicators

Examples of indicators that may push a case toward Possibly covered or May need legal review:

  • mixed B2B/B2C use
  • unclear operator role
  • borderline product/service classification
  • incomplete answers
  • cross-border distribution complexity
  • possible exemptions or exceptions not reliably resolved by the tool

Stronger “not covered” indicators

Examples of indicators that may push a case toward Likely not covered:

  • no meaningful EU market connection based on entered facts
  • internal-only use with no public consumer offer
  • entered case does not align with the tool's covered categories

Confidence and limits

The tool does not calculate legal certainty.

Instead, it uses conservative user-facing language:

  • “Likely covered” means the answers fit a common pattern, not that coverage is legally confirmed.
  • “Possibly covered” means there is a meaningful chance of relevance, but more detail is needed.
  • “May need legal review” means the tool should not be relied on for a decision without further review.
  • “Likely not covered” means no clear trigger appears from the entered facts, but the result is still indicative.

Checklist generation approach

The checklist is assembled from broad accessibility workstreams rather than from a claim of completed compliance review.

Typical checklist sections may include:

  • scope confirmation
  • critical user journeys
  • content and interface review
  • forms and transactions
  • media and documents
  • input methods and assistive technology support
  • support/contact channels
  • accessibility statement preparation
  • ownership and follow-up

The checklist is intentionally practical.

It is designed to help a team organise next steps after triage.

Starter statement generation approach

The statement draft is intentionally cautious.

It should:

  • identify what the statement covers
  • avoid unsupported compliance claims
  • leave room to describe current status honestly
  • include a contact path for accessibility issues
  • signal that updates may follow review or remediation

The statement should not:

  • assert legal compliance unless verified
  • claim audit completion unless it happened
  • hide known accessibility gaps

Design choices for public release

The documentation and wording are designed for a public static tool, not a full SaaS workflow.

Key public-release choices:

  • plain-language inputs
  • action-oriented result labels
  • explicit disclaimer language
  • no suggestion of certification
  • no suggestion of legal advice
  • separate privacy explanation for a no-account public tool

What the tool does not do

This tool does not:

  • fetch or scan a live site or app
  • run automated accessibility tests
  • inspect code
  • verify documents or media assets
  • confirm whether a legal exemption applies
  • replace national legal interpretation
  • replace expert accessibility assessment

Appropriate use

The tool is appropriate for:

  • early internal triage
  • preparing first conversations with legal or accessibility reviewers
  • creating an initial task list
  • drafting a first version of an accessibility statement

The tool is not appropriate as the sole basis for:

  • formal legal sign-off
  • procurement promises
  • compliance certification claims
  • publication of unreviewed accessibility claims

Recommended disclaimer language

Recommended baseline disclaimer for the public release:

> This tool provides an indicative first-pass assessment based on the information entered by the user. It does not provide legal advice, does not perform a full accessibility audit, and should not be treated as a final determination of scope or compliance. Edge cases may require review by qualified legal and accessibility professionals.