accessibility

アクセシビリティ skill の概要

アクセシビリティ skill でできること

アクセシビリティ skill は、WCAG 2.2 レベル AA に準拠したアクセシブルな UI を設計・実装・監査するための skill です。製品の意図を、ネイティブ要素、ARIA ロール、ラベル、ヒント、フォーカス挙動、そして Web・iOS・Android 向けのプラットフォーム固有のアクセシビリティ特性といった具体的な選択に落とし込むことを目的としています。

どんな人にアクセシビリティ skill を入れるべきか

このアクセシビリティ skill は、汎用的なアクセシビリティチェックリストではなく、実装にそのまま使える指針が必要なフロントエンドエンジニア、デザインシステムチーム、UX 監査担当、プロダクトデザイナーに最適です。特に UX Audit のアクセシビリティ対応で、「このフローは危なそう」から具体的な修正案に落とし込みたいときに役立ちます。

どんな仕事を完了するのに役立つか

本当に解決したい仕事は、単に「準拠させる」ことではありません。コンポーネントやフローをアクセシビリティツリーに正しく対応づけ、支援技術の利用者が適切なロール、名前、状態、順序、操作モデルを得られるようにすることです。この skill は、広い方針の要約よりも、セマンティックな対応付け、フォーカス管理、ラベリング、POUR 原則を重視します。

通常のプロンプトよりこれを選ぶ理由

通常のプロンプトだと、アクセシビリティに関する助言が曖昧になりがちです。この skill は、たとえば「まずコンポーネントの役割を特定する」「ネイティブの意味を優先する」「そのうえでラベル、状態、キーボード操作、フォーカスの扱いを定義する」といった、構造化された判断が必要な場面でより有効です。そのため、実装レビューや監査でそのまま使える、実用的な指摘が得やすくなります。

アクセシビリティ skill の使い方

導入時の文脈と、最初に読むべき内容

skills ワークフローから skill を導入したら、最初に skills/accessibility/SKILL.md を開いてください。この skill には追加のスクリプトや参照ファイルはないため、実用的な情報のほとんどはこの 1 つのドキュメントにまとまっています。読む順番は次の通りです。

1. When to Use
2. Core Concepts
3. How It Works
4. コンポーネントの役割を特定する手順

これは軽量なアクセシビリティ導入です。セットアップの手間は少ない一方で、不足している製品文脈は自分で補う前提になります。

アクセシビリティ skill に必要な入力

アクセシビリティ skill は、次の情報があると最もよく機能します。

• platform: Web, iOS, Android
• component or flow: button, modal, form, tabs, menu, carousel など
• user goal: ユーザーが何をしようとしているか
• current implementation: HTML, JSX, SwiftUI/UIKit, Jetpack Compose/View XML、またはスクリーンショットと挙動メモ
• constraints: デザインシステム上の制約、レガシーマークアップ、サードパーティウィジェット
• audit target: WCAG 2.2 AA、キーボード対応、スクリーンリーダーの挙動、フォーカス順、ターゲットサイズ、名前/状態の問題

弱い入力: 「これをアクセシブルにして。」
強い入力: 「この React の modal を WCAG 2.2 AA の観点で監査してください。セマンティックな role、accessible name、focus trap、escape の挙動、初期フォーカス、戻りフォーカス、スクリーンリーダーへの通知を確認し、修正版の JSX を提案してください。」

あいまいな目的を強いプロンプトに変える

アクセシビリティ利用をより良くするには、次のようなプロンプト構成が有効です。

• UI の role と、現在の要素をネイティブ要素で置き換えるべきかを特定する
• 想定される accessibility tree を説明する
• 必要な label、role、state、value、hint を列挙する
• キーボードとフォーカスの挙動を定義する
• WCAG 2.2 AA のリスクを指摘する
• 修正版コードと短い監査サマリーを返す

例:
「Web 上のこのカスタム dropdown を accessibility skill でレビューしてください。まず、ネイティブの select、button + listbox、または別のパターンのどれにすべきか判断してください。そのうえで、想定される ARIA、キーボード操作、フォーカス移動、可視フォーカスの要件、ターゲットサイズの懸念、修正版コードを提示してください。」

監査と実装のための推奨ワークフロー

UX Audit 向けのアクセシビリティ対応では、まずフロー単位で見てからコンポーネントに掘り下げてください。

1. タスクと失敗リスクを言語化する
2. 各インタラクティブ要素の真の role を特定する
3. まずネイティブのセマンティック代替を確認する
4. label、name、value、state を検証する
5. キーボード順序とフォーカスの可視性を確認する
6. スクリーンリーダーの通知を概念的にテストする
7. 修正済みコードまたは仕様を依頼する

実装が目的なら、単なる説明文ではなく、エンジニアや QA にそのまま渡せる受け入れ条件を求めてください。

アクセシビリティ skill FAQ

このアクセシビリティ skill は初心者向けですか？

はい、すでに基本的な UI 実装を理解しているなら使えます。この skill はアクセシビリティの基本概念を平易に説明しますが、WCAG の完全な入門講座ではありません。学習リソースの代わりというより、実装をガイドする支援ツールとして使うのが向いています。

導入判断に足る内容ですか？

ほぼはい、です。scope は明確で、ワークフローも具体的、技術面へのフォーカスも実用的です。主な制約はパッケージの厚みで、補助的なサンプル、テストスクリプト、プラットフォーム別の参照ファイルはありません。再利用可能な資産を大量に求めるなら軽めに感じますが、素早い指針が欲しいなら導入しやすい skill です。

一般的なアクセシビリティ prompt と何が違いますか？

違いはフレーミングです。このアクセシビリティ guide は、role の特定、セマンティックな対応付け、アクセシビリティツリーの考え方、ラベル、フォーカス管理を中心に据えています。一般的な prompt は ARIA 属性の話にすぐ飛びがちで、その結果、過剰設計や不適切なパターンにつながることがあります。

どんなときにこの skill を使うべきではありませんか？

法的な最終判断、複雑な支援技術互換性テスト、非常に特殊なネイティブプラットフォームのエッジケースまで、このアクセシビリティ skill だけに頼るべきではありません。設計やコードの判断には強いですが、実機、スクリーンリーダー、キーボードのみの操作による手動テストの代わりにはなりません。

アクセシビリティ skill の改善方法

コード断片だけでなく、UI の文脈をもっと詳しく伝える

品質を大きく左右するのは文脈です。ユーザーのタスク、その操作が状態変更なのか画面遷移なのか、画面上で何が見えているか、今どこで壊れているかを含めてください。アクセシビリティの提案はマークアップだけではなく挙動に依存します。div でも複数のパターンを表せるため、意図したインタラクションを明示したほうが skill はよく機能します。

ARIA を求める前に、パターン選定を依頼する

よくある失敗は、間違ったコンポーネントに無理やり ARIA を載せることです。アクセシビリティ出力を改善するには、「これは実際にはどのパターンか？」と先に पूछねるのが有効です。たとえば、修正の前に native button、link、disclosure、tab、dialog、listbox のどれにすべきかを判断してもらってください。不要なカスタムウィジェットを避けやすくなります。

実装にそのまま使える形式で出力を求める

より強いアクセシビリティ利用のために、構造化された応答を求めてください。

• 見つかった問題
• ユーザーへの影響
• WCAG 2.2 上の懸念
• 推奨セマンティックパターン
• 具体的なコード変更
• テスト手順

この形式は、1 本のエッセイ形式の回答よりも、エンジニア、QA、デザインシステム責任者への引き継ぎに向いています。

実際の失敗証拠をもとに繰り返し改善する

最初の回答のあと、スクリーンリーダーの発話内容、キーボードトラップ、可視フォーカスの欠如、タッチターゲットのサイズなど、具体的な情報をフィードバックして精度を上げてください。この skill は、1 回きりの準拠チェックとして使うより、UX Audit の指摘を反復改善するループとして使うほうがはるかに価値があります。