Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Define accessibility requirements for WebMCP user-agent UI

Abierto
  • ¿Algo no está bien?
#277 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
html
Área
accessibility

Línea de trabajo

Start with the empty Accessibility considerations section in index.bs and read the linked declarative-api-explainer.md passages, plus the related issues and pull requests listed in the description. Resolve the open questions about conformance guidance, review policy, and agent-filled state before proposing requirements. Done means the draft addresses the listed accessibility needs and the FAST API checklist item.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

a11y-tracker

Summary

Define accessibility requirements for any user-agent or agent-frontend UI that exposes WebMCP tool
discovery or mediates tool execution. This is a focused follow-up to the APA WG review in
#65 and the FAST self-review in #272.

This does not propose adding WebMCP tool metadata to the page accessibility tree; #91 settled
that question. It concerns the accessibility of user-facing UI created by a user agent or agent
frontend from WebMCP data.

Current gap

The draft says a tool's title is used by the user agent in UI,
but its Accessibility considerations section is empty.

The declarative explainer also defines user-visible behavior:

Those hooks are useful, but author styling and script events are not a substitute for requirements
on the UI that people actually use. In particular, toolautosubmit skips the described review
state entirely.

Requirements to resolve

Any normative or recommended user-agent mediation should address at least:

  1. Discovery: a user can determine that agent capabilities are available and identify them by
    an accessible name and description.
  2. Review and approval: a user can inspect the exact tool, origin, arguments, target, and likely
    consequence before a consequential action is committed, then approve or reject it. A user-agent
    policy or user preference must be able to require review regardless of an author hint or
    toolautosubmit. This supports WCAG 2.2's review/confirm/correct model for consequential
    submissions    .
  3. Operation: the mediation UI is keyboard- and assistive-technology-accessible, with defined
    roles, names, states, values, focus behavior, and hardware-agnostic controls.
  4. Status and recovery: start, progress, completion, partial failure, cancellation, and any undo
    opportunity are perceivable without relying only on color, animation, or visual focus.
  5. Agent-filled state: users can tell which form values were supplied by an agent and review
    changes without requiring visual comparison. Whether this needs a WebMCP primitive, HTML work,
    or user-agent-only behavior remains an open layering question.
  6. Privacy and parity: the same mediation is available whether or not assistive technology is
    present; implementations must not detect or reveal AT usage to select behavior.
  7. Localization: accessible names, descriptions, status, and review UI follow the language and
    direction decisions tracked in #153 and #276.

Relationship to existing work

  • #165 / PR #204: user-input and human-in-the-loop flows.
  • #176 / PR #217 and #198: consequence/reversibility hints and review policy. Site-provided hints
    remain advisory; they are not authorization decisions.
  • #139: declarative validation feedback.
  • #66, #67, and #210: labels and input-schema synthesis.
  • #91: WebMCP and the page accessibility tree remain separate layers.

The outcome could be conformance requirements, non-normative implementation guidance, or both, but
the current empty accessibility section does not answer the FAST API checklist item.

Maintainers: please apply the a11y-tracker label so APA is notified. I cannot apply repository
labels with my current permissions.

Lenguaje dominante
Bikeshed
Estrellas
4.7k
Forks
328
Merge medio
2 d 15 h
PR fusionados (30 d)
16

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de webmachinelearning/webmcp

Todos los issues de webmachinelearning/webmcp

Issues similares

Más issues de Accessibility

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.