# Put accessibility into the software brief from the start

> Turn accessibility from a vague requirement into responsibilities, representative tasks, evaluation, and ongoing improvements.

- Published: Sep 25, 2026
- Topic: Project planning
- Author: RDR Digital
- Original: https://rdr.digital/blog/planning-accessible-business-software

“The application must be accessible” is an important intention, but it leaves a project team with several decisions. Who will define the target? Which journeys will be evaluated? Who fixes issues in a third-party form? What happens when content changes after launch?

A useful brief turns the intention into work that has an owner and evidence.

## Plan the work across the project

W3C's [accessibility planning guidance](https://www.w3.org/WAI/planning-and-managing/) organizes the work around establishing a foundation, planning, implementation, and sustaining progress. It includes assigning responsibility and evaluating early and regularly.

Use that approach to ask for an explicit evaluation plan. Agree the relevant standard and scope with appropriate expertise, along with how findings will be recorded and resolved. A general article cannot establish which legal obligations apply to a particular service or certify its conformance.

Include accessibility when comparing suppliers, estimating the project, and setting acceptance expectations. It should be clear which work is included before delivery begins.

## Choose complete tasks to evaluate

Select the journeys people need to finish, such as requesting a quote, changing account details, or submitting an expense. Include their error states and confirmations.

For an illustrative customer portal, the task might involve signing in, finding an order, opening its details, and requesting help. Checking only the landing page would leave most of that experience unexamined.

Ask the team to document representative devices, input methods, and assistive technologies for evaluation. Involve disabled users in research where appropriate, with suitable preparation and support.

## Make ordinary interactions part of acceptance

The following questions are a starting point for discussion, not a complete accessibility audit:

- Can someone reach and operate the relevant controls using a keyboard?
- Is the current focus visible and understandable?
- Do form fields have clear labels and useful error explanations?
- Can text be enlarged without losing essential content or actions?
- Does a status remain understandable without relying only on color?
- Can a user identify what happened after submitting the form?

Connect each question to a real task. Ask to see the behavior, including errors, instead of accepting a promise that a component library handles everything.

## Combine tools with skilled evaluation

W3C's [evaluation tools overview](https://www.w3.org/WAI/test-evaluate/tools/) explains that some accessibility checks cannot be automated and require manual work. It also cautions that tools can produce inaccurate results.

Treat automated checks as one source of evidence. Agree what manual evaluation is included and who has the expertise to interpret the findings. Record the scope and limitations of the assessment instead of turning a tool score into a blanket claim.

Include third-party parts of the journey, such as authentication, payment, booking widgets, and documents. If a supplier controls a problem, name the person responsible for following it through.

## Keep an issue path open after launch

Give users a clear way to report difficulty. Route those reports to someone who can investigate the affected task and coordinate a fix.

Include accessibility checks when adding features or changing shared components. Ask content owners to preserve meaningful headings, link text, and image descriptions as part of their editing process.

Finally, carry unresolved findings and their owners into the [maintenance plan](https://rdr.digital/blog/software-maintenance-after-launch). The goal is a service people can continue to use as the software and its content evolve.

## Sources

- [W3C WAI: Planning and Managing Web Accessibility](https://www.w3.org/WAI/planning-and-managing/)
- [W3C WAI: Evaluation Tools Overview](https://www.w3.org/WAI/test-evaluate/tools/)