Define accessibility requirements for WebMCP user-agent UI
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- 明確に書かれている
- 活発さ
- 静か
- 技術スタック
- html
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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:
- without
toolautosubmit, the browser focuses the submit button and asks the user to review the
form; :tool-form-activeand:tool-submit-activelet authors visually highlight an agent-filled
form;toolactivatedandtoolcanceledexpose lifecycle changes to script, but do not ensure those
changes are perceivable to the user.
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:
- Discovery: a user can determine that agent capabilities are available and identify them by
an accessible name and description. - 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. - Operation: the mediation UI is keyboard- and assistive-technology-accessible, with defined
roles, names, states, values, focus behavior, and hardware-agnostic controls. - Status and recovery: start, progress, completion, partial failure, cancellation, and any undo
opportunity are perceivable without relying only on color, animation, or visual focus. - 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. - 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. - 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.
- 主要言語
- Bikeshed
- スター
- 4.7k
- フォーク
- 328
- 平均マージ
- 2日 15時間
- マージ済み PR（30日）
- 16
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
webmachinelearning/webmcp のほかの issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 72/100
webmachinelearning/webmcp#360 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Say how an agent should weigh annotations that the page wrote about itself対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
webmachinelearning/webmcp#353 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
webmachinelearning/webmcp#343 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Agenda+ i18n-tracker
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
webmachinelearning/webmcp#273 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
a11y-tracker Agenda+
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
webmachinelearning/webmcp#272 · コメント 4 件 · リアクション 2 件 ·
メンテナーはふだん 1 日以内に返信
webmachinelearning/webmcp の issue をすべて見る
似ている issue
-
revealjs speaker view: missing named landmarks for current slide, upcoming slide, time, and notes対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug revealjs
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
quarto-dev/quarto-cli#15160 ·
メンテナーはふだん 1 日以内に返信
-
enhancement good first issue help wanted priority: high Stellar Wave
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
Fortexa-stellar/Fortexa#359 ·
メンテナーはふだん 1 日以内に返信
-
bug mobile
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
lognorman20/monaco#6265 ·
-
accessibility area: dialog help wanted roadmap
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
bug: OTP component displays pointer cursor instead of text cursor対応中かも @linkin85 が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
saadeghi/daisyui#4826 · コメント 2 件 ·
メンテナーはふだん 3 日以内に返信