Accessibility needs an owner after launch

What we found in the news

W3C’s Planning and Managing Web Accessibility (opens in a new tab), updated in August 2026, treats accessibility as continuing organizational work. Its guidance includes:

“Continue to review and report on content, processes, and resources.”

— W3C Web Accessibility Initiative, August 12, 2026

That sentence is useful well beyond a launch checklist. A service website changes as people add forms, replace documents, update instructions, and introduce new ways to take part. The arrangements for reviewing those changes need to continue too.

This guidance describes a management approach. It does not certify a particular website or establish that a service meets every user’s needs.

Why this matters to us

Imagine a team has carefully reviewed a new registration page. A few months later, someone adds a downloadable form. Another colleague changes the instructions. A supplier update alters a control.

Each change has a practical reason. Together, they may create a task that is harder for some people to complete.

At genus, we think ongoing ownership matters as much as initial care. A person visiting today encounters the service as it is today. They cannot benefit from a good review of an earlier version if a new barrier now stands in their way.

Decide who checks an ordinary change

Choose a common update, such as replacing a document or adding an activity booking. Follow it from request to publication.

Who prepares the content? Who reviews whether it is understandable and usable? What checks require specialist support? Who can delay a change when an important problem remains unresolved?

Make the route clear enough for occasional editors as well as regular staff. Provide practical examples and access to the support they need. Avoid assigning responsibility to someone who has neither time nor authority to act.

Record the version reviewed and the scope of the checks. That helps a later colleague understand what was assessed and what has changed since.

Give feedback somewhere useful to go

A person who encounters a barrier should be able to report it through a workable alternative route. Make that route visible where help is likely to be needed.

Ask what task the person was trying to complete and what happened. Do not require them to diagnose the technical cause or disclose more personal information than the organization needs to respond.

Agree who receives the report, who can arrange immediate practical assistance, and who follows the underlying issue through to review. Those may be different people, but the handover should be explicit.

Keep the person informed in an appropriate way. If the problem cannot be resolved immediately, explain the available alternative without presenting it as suitable for everyone.

Include maintenance in the service plan

Set aside time to revisit important journeys and recently changed content. Involve people with relevant experience and use qualified assessment where needed.

Look for patterns in support requests. A recurring question may point to an instruction, an error message, or a process that needs attention. A low number of complaints does not prove that everyone can complete the task; some people may simply leave.

Include accessibility responsibilities when staff roles change or a supplier contract is reviewed. Check who will respond to a newly identified issue and how changes will be tested.

The work becomes easier to sustain when it has a place in ordinary service ownership, rather than depending on one enthusiastic colleague remembering to ask.

What this means for the people you serve

People should be able to choose how to seek help and explain what works for them. Invite feedback without making access to the service depend on participation in a test or review. Someone asking for an alternative route should receive a useful response, with appropriate attention to their privacy and preferences.

The genus connection

Today, genus public and care-team experiences are configured around an organization’s content and workflows. That means changes to content and configuration deserve continuing review alongside the underlying product.

This article does not claim universal accessibility or certification. It describes the shared work of maintaining a usable service: clear responsibilities, appropriate evidence, responsive support, and attention to what people encounter after launch.

One question for your next team meeting

Who would notice, receive, and resolve an accessibility problem introduced by our next routine update?