Access is a design constraint.

Start with the conditions

A capability can be impressive and still be impractical. Before someone sees an answer, they may need a compatible device, a stable connection, an account, a supported language, and a way to pay. A design decision about any one of these requirements changes who can participate.

The International Telecommunication Union estimates that 2.2 billion people remained offline in 2025. Its report also identifies continuing gaps in connection quality and affordability. These population-level estimates establish the scale of the connectivity question; they do not identify the needs, budgets, or preferences of a particular group of people.^[1]

We use access here to include practical and economic conditions. Disability accessibility remains a distinct requirement. W3C distinguishes accessibility, usability, and inclusion, and recommends addressing them together. A lower price or smaller download cannot establish that a product works with assistive technologies or is usable by people with disabilities.^[2]

Separate evidence from assumptions

This working note proposes a review method. It is not a report of participant research, a claim about the performance of a model, or a validated measure of inclusion. The accompanying simulator calculates consequences of assumptions that a visitor enters. Its outputs are scenarios, not observations about real people.

A useful review distinguishes four kinds of information: published context, a directly checked requirement or price, an assumption used to explore a possibility, and an observation from a defined task. Each has a different role. A global connectivity statistic can motivate a question, but cannot substitute for a local connection test. A plausible task can start a prototype, but cannot establish demand.

The discipline is to keep the provenance attached. Record where a number came from, what it includes, when it was checked, and whom it describes. When a value is unknown, leave it unknown or show a range. Precision in a calculator should never be mistaken for confidence in its inputs.

Make participation costs visible

Begin with a person, a task, and a time period. Then list the additional financial commitments needed to attempt that task: service charges, usage fees, data, and any required equipment or support. Identify costs already covered elsewhere. Allocating part of a device or connection bill to a workflow is a modelling choice; record the basis and avoid charging the same cost twice.

Keep immediate cash requirements separate from costs spread across a longer period. A device may appear inexpensive when its price is divided across several years, yet its purchase price can still prevent someone from starting. Similarly, a monthly average can conceal a prepaid data purchase or a minimum subscription commitment. Show those conditions alongside the estimate.

Time deserves its own ledger: setup, learning, waiting, checking, and recovering from failures. Do not automatically turn every minute into a monetary value. People have different constraints, and an assumed hourly rate can hide them. Record regional availability, language, device compatibility, and accessibility as requirements to investigate rather than as prices to average away.

The UK Government Digital Service defines cost per transaction from the service provider’s perspective, including the cost of delivering support. That is a different boundary from the participant’s budget used here. A complete decision may need both accounts: a low participant price can depend on costs borne by a provider, an institution, or another person.^[3]

Measure usefulness separately

A workflow that fits a budget has passed one constraint. It has not yet demonstrated value. Define what a useful result would enable a person to do, and what would make that result unacceptable. For a low-stakes task, that might mean producing an understandable first draft whose important details can be checked. High-stakes uses require a different scope and appropriate expert review.

Separate completion from quality. GDS measures completion as finished transactions divided by all started transactions, and notes that completing an application does not mean the application succeeds. For an AI-assisted task, our proposed distinction is similar: reaching an output is different from obtaining a correct, understandable, and usable result. Record both.^[4]

Compare against a reasonable alternative. That might be an existing service, a simpler document, another delivery method, or doing the task without AI. Define the same task and review criteria for each. Record the help needed, corrections made, and whether the person could recognise and recover from a problem. A lower cost is valuable when the required usefulness survives.

Test a smaller question

Choose one task and one barrier before expanding the scope. The first version of Everyday AI access is an assumption-based budget simulator. It can help frame a comparison and reveal which inputs matter. It does not call an AI model, evaluate an answer, measure a connection, or recruit participants.

Use its output to design the next investigation. For example, if data consumption changes the feasibility of a scenario, measure actual transfer sizes for the proposed workflow. Include setup and repeat attempts where relevant. If a fee dominates the estimate, check the current terms, taxes, billing minimums, and local availability rather than assuming a simple per-use price.

Before involving people, agree on the intended task, suitable participants, consent, privacy, support, and a definition of useful completion. Include people with relevant disabilities in the design and evaluation, alongside accessibility standards. W3C cautions that user involvement and technical guidance are complementary; either approach on its own leaves gaps.^[2]

Set a decision rule before reviewing outcomes. Continue if the defined requirements are met and the remaining uncertainty is acceptable for the next stage. Revise if a particular barrier can be addressed. Stop if the result is not useful, imposes an unacceptable burden, or depends on assumptions that do not hold. A recorded stop decision is a research output too.

Keep the limitations in view

A budget model cannot represent every barrier. Account eligibility, privacy, trust, safety, language, shared-device use, and the availability of human help may decide whether a workflow is appropriate. Record them explicitly. Do not compress these conditions into a single score that implies different barriers can always compensate for one another.

The initial model is deliberately small. It does not forecast future prices, infer household affordability, or estimate the social value of an AI system. Example settings are illustrative and should be replaced with checked local inputs before informing a real decision. No participant outcomes, comparative performance results, or accessibility conformance claim are reported in this release.

Leave a useful record

A review should end with an inspectable record: the task and context, the inputs and their sources, the cost boundary, the conditions not modelled, the criteria for usefulness, and the next decision. Preserve the version of the method used. Someone else should be able to see what changed without reverse-engineering a chart.

The simulator and Access Review Worksheet turn this note into a starting point for that record. Explore an assumption, export the scenario, then use the worksheet to capture what the calculation leaves open. The next meaningful improvement will come from replacing assumptions with measured inputs and appropriate observations—not from presenting the same assumptions more confidently.