An accessible button is useful. An accessible way to finish is the point.
That distinction matters as apps acquire agents and microphones. A person might be able to ask for help and still be unable to inspect the answer, correct it or approve the next step. The entrance has changed. The barrier has moved further inside.
The state of web accessibility makes this a practical concern. In its February 2026 study of one million home pages, WebAIM detected WCAG failures on 95.9%WebAIM · February 2026 sampleThe WebAIM MillionDetected WCAG failures on 95.9% of one million home pages. Automated testing finds only some barriers; an error-free scan does not establish accessibility.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab). This was an automated scan of a defined sample, not a verdict on every page or every person's experience. Undetected problems remain possible on pages without detected errors.
Access has to last until the task is done.
Explanation and sources
WebAIM detected WCAG failures on 95.9% of one million home pages in February 2026, with 56.1 detected errors per page on average. Each square is one percentage point; the 96th is 90% filled. The remaining 4.1% had no detected failures, which is unknown rather than accessible. A home-page scan covers the first stop of an illustrative booking journey; finding a date, comparing places, checking an access need, fixing details and saving the booking are not measured by it.
Sources reviewed 5 October 2026. Conceptual diagrams are labelled separately from the reported scan.The old barriers are still here
Low-contrast text, missing image descriptions and unlabelled form inputs remain among the report's common findings. An agent does not make those defects irrelevant. People still need to read a result and understand what an action will do.
Consider booking an appointment. Finding the date is one step. The person may also need to compare locations, check an access requirement, correct their details and save the confirmation. A conversational front end that handles the first step has helped. Whether the whole booking is accessible is a larger question.
That is already part of established practice. WCAG 2.2's complete-process requirementW3C · Conformance requirement 3WCAG 2.2: Complete processesConformance for a sequence that accomplishes an activity covers all its pages. Access to an isolated control is not the entire question.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab) covers all pages in a sequence needed to accomplish an activity. The journey did not become important when agents arrived.
What changes is where the journey can break. A misunderstood request may produce a plausible answer. A missing status message may leave someone unsure whether anything happened. Asking again might repeat an action rather than explain it.
A microphone does not settle the question
Speech can remove the need to reach a control or type a long instruction. It can also introduce demands on speech, hearing, memory and privacy. Whether it helps depends on the person, the task and the surroundings.
W3C's draft natural-language accessibility requirementsW3C · Group Draft Note · September 2022Natural Language Interface Accessibility User RequirementsDiscusses input and output choices, understanding and error recovery. This is work in progress, not an endorsed conformance standard.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab) address alternative inputs and outputs, comprehension and recovery. The document is work in progress. Its scope is useful here: access includes the information returned by the system, not only the conversation used to request it.
For the appointment example, we would want a spoken request to produce a booking proposal that can also be read and edited. The person should be able to switch to typing without starting again. If the service is unavailable, they need an understandable result and a next step they can use.
These are design requirements for the example. We have not run a booking study or established that one input method is best.
Measure the journey people actually take
Start with a task people need, and include people who use the access methods being evaluated. Ask them to complete the task through the existing interface and the proposed alternative. Account for familiarity and order: someone who has already learned the task has an advantage on the second attempt.
Record completion, assistance and corrections. Observe where the person loses track of what happened. Time can reveal friction, but a fast attempt that ends in the wrong booking is not a successful one.
Automated checks, manual inspection and participant work answer different questions. Use them together. A demonstration by the person who built the app cannot stand in for the people it intends to serve.
The opportunity is substantial. A well-designed agent could handle navigation that previously required another person's help. That would change who can complete the task independently. It is a claim worth testing carefully because the benefit matters.
Next, WebMCP gives agents explicit ways to actOrchestra · related articleStop making agents hunt for buttonsWebMCP lets a page expose actions to a browser agent. Radar shows how that can keep the person and agent working in the same place.Orchestra editorial summaryOpen original ↗ (new tab). Those actions can support a better journey. The journey still needs to work for the person using it.