本文へ移動
easeweb
ご相談

開発者とデザイナーの方へ

アクセシビリティの修正と確認を、コーディングエージェントの中で

修正ガイドを Model Context Protocol のサーバーとして。実際の人にとって何が壊れるか、コード付きの修正、そして人にしかできない確認。無料、ログイン不要、日本語と英語に対応。

設定する ガイドを見る

EaseWebなし

  1. 自動再生のカルーセルを作って
  2. setInterval(next, 3000)
  3. 完了しました。

リリース後に3件の不適合。

同じ依頼を、EaseWebなしとありで。

設定

4つのステップで設定して使う

  1. コーディングエージェントにサーバーを追加する

    キーもアカウントも不要です。アドレスは https://easeweb.dev/mcp。お使いのクライアントを選んでください：

    ターミナルで：

    claude mcp add --transport http easeweb https://easeweb.dev/mcp

  2. 最初に聞くよう指示する

    ツールを呼ぶかどうかはエージェントが決めます。UIを変更するたびに聞くよう、この一行をプロジェクトのルール（CLAUDE.md、AGENTS.md、.cursor/rules）に貼り付けてください：

    UIの設計・実装・変更を頼まれたら、コードを書いたり画面を描いたりする前に、依頼内容をそのまま easeweb の before_building ツールに渡すこと。色を決めるときは check_palette を呼ぶこと。作り終えたら test_steps を呼び、「人が確認すること」はそのまま私に引き継ぎ、完了として報告しないこと。

  3. いつもどおりUIを依頼する

    エージェントはコードを書く前に、依頼の言葉で before_building を呼びます。依頼どおりでは不適合になる場合は、合格する形で作り、その理由を伝えます。

    > 自動再生のカルーセルを作って
● easeweb · before_building

  4. 渡された確認を行う

    作り終えると、エージェントはスクリーンリーダーでの確認など、人にしかできない確認を一覧にします。公開前にそれを行ってください。エージェントがそれを完了扱いにすることはありません。

ツール

5つのツール、それぞれに呼ぶタイミングがあります

  • before_building

    いつ: メニュー、ダイアログ、カルーセル、タブ、フォーム、ドラッグ＆ドロップ、独自の操作部品など、UIを設計・実装する前に。ワイヤーフレームやプロトタイプも対象です。

    返すもの: 該当するガイド、最初から組み込む要件、動く参考コード、誰が確認できるかで分けたチェック項目。依頼そのものがルールに抵触する場合は、意図を保ったまま合格する形と、あなたに伝える一言。

  • find_fix

    いつ: 指摘、苦情、失敗したチェック、質問で問題が挙がったとき。

    返すもの: 該当する項目ごとに、問題、一行の修正方針、確認方法、ガイドへのリンク、そして WCAG・EN 301 549・Section 508・JIS X 8341-3 での達成基準。ガイドが未公開の項目はその旨を返します。

  • get_guide

    いつ: エージェントが修正の全体を必要とするとき。

    返すもの: /learn/⟨slug⟩.md と同じ Markdown のガイド。修正前・修正後のコードをプレーンテキストで、推奨・単独では不十分・背景にある原則の印つきで返します。

  • test_steps

    いつ: 実装や修正の後、エージェントが「完了」と言う前に。

    返すもの: 合格の条件、エージェント自身が実行できるチェック、人にしかできない2分の手順（どのキーを押し、何が起きるべきか）、ガイドの限界、そして空のままでは合格しない Playwright の回帰テストの雛形。

  • check_palette

    いつ: 色、パレット、デザイントークンを決める・変えるとき、使う前に。

    返すもの: 各ペアのコントラスト比、テキスト（1.4.3）と操作部品（1.4.11）の AA / AAA での合否、同じ色相で合格する最も近い色、該当するガイド。

各ガイドはMCPのリソースでもあるので、対応するクライアントでは @ で参照できます。2つのプロンプト（before_building、handoff）で、この2つのタイミングをスラッシュコマンドとして実行できます。

答えの形

「だめ」ではなく「こうすれば」

「ラベルの代わりにプレースホルダーを使う設定フォーム」に対する before_building の答えから、スキャンツールと違う部分を抜粋したもの：依頼の意図を保った合格する形、ユーザーへの一言、人が確認すること。

この依頼には、そのままでは不適合になる部分があります

抵触: WCAG 3.3.2 ラベル又は説明 (A; JIS X 8341-3 3.3.2; EN 301 549 9.3.3.2; Section 508)

代わりに: 入力中も見え続けるラベル：欄の上のラベル、またはフォーカスで欄の上に移動してそのまま残るフローティングラベル。プレースホルダーを使うなら入力例にとどめ、項目名にはしない。

ユーザーへの一言: “プレースホルダーは入力を始めると消えてしまうので、小さく見えるラベルを残し、プレースホルダーは入力例に使います。”

エージェントが確認できること

  • 各入力欄に for と id で結ばれた label 要素があり、入力中もラベルが見える。
  • アクセシブルな名前が、見えるラベルの文字と一致する。

人が確認すること

  • 欄にフォーカスすると、スクリーンリーダーが各ラベルを読み上げる。
  • 200%の拡大と強制カラーでもラベルが読める。

抜粋です。完全な答えには、ガイドへのリンク、参考コード、2分の確認手順が含まれます。

流れ

どの修正も、最初と最後は人が確かめる

  1. 1

    人が見つける

    キーボード、スクリーンリーダー、拡大表示での手動テストで、スキャンが見落とす問題を見つけます。

  2. 2

    エージェントが直す

    エージェント向けに書かれたガイドから：修正、コード、チェック項目。無料です。

  3. 3

    人が確かめる

    「修正済み」とは、スキャンが通ったことではなく、人の再確認に合格したこと。

  4. 4

    テストで守る

    確認済みの修正ごとに、CIに回帰テストを。test_steps が返す雛形から始められます。無料です。

2と4は無料で、今日から使えます。継続サポートでは、1と3も同じエージェントの中に入ります：レポートの指摘、再確認、プロジェクト独自のルールを、順次提供していきます。

限界を先に

できないこと

  • あなたのページを見ることはありません。ガイドと、渡された言葉から答えます。スキャンは axe や Playwright で、あなたのCIの中で。
  • 答えがきれいでも、ページがアクセシブルとは限りません。どの答えも「エージェントが確認できること」と「人が確認すること」に分かれ、後者が本当の判定です。
  • check_palette は値を確認します。画像の上の文字、実際のフォーカスやホバーの状態、強制カラーは描画されたページが必要です。
  • ガイドはよくある失敗から順に書かれています。未公開の項目は「準備中」として達成基準と共に返り、毎週増えています。
  • 利用の目安：アドレスあたり1日600リクエスト（ハッシュで数えます）。アカウントもクッキーも不要で、引数は保存しません。

開発者向けのその他

MCPクライアントがなくても

エージェントの仕事が終わったら

決め手になるのは、人が行う確認です。継続サポートでは、Section 508 Trusted Tester がその確認を担当します。指摘、再確認、確認済みの修正ごとの回帰テストを、チーム全体に。

継続サポートについて相談する サービス一覧を見る