検証できるアクセシビリティのユーザーストーリーを書く方法。
要件は観察可能な操作の振る舞いを記述します。提示された関連基準を使い、確認方法も含めてください。
作業手順をタスクに合わせましょう。
該当するアクセスニーズに対する操作結果を述べ、観察可能な受け入れ確認を付けます。必要に応じてフォーカスやコントロール名などを含め、適切な方法で実装を検証します。
- 用意するもの
- 画面の利用場面と提示したアクセシビリティ基準。
- 得られるもの
- 実装に結び付くアクセシビリティ要件。
入力と結果を確認しましょう。
説明用の入力と出力 · 実際の WebAct 実行ではない学習用サンプル
入力項目サンプル個
Draft a keyboard-accessibility user story for a dialog. Opening moves focus inside; a labeled close action is keyboard-operable; closing returns focus to the opener. Include acceptance checks.
完成例
Story: As a keyboard user, I want to open, use and close the dialog without losing my place. Acceptance checks: - Opening the dialog places focus on a sensible element inside it. - The close control has an understandable accessible name and works from the keyboard. - Closing returns focus to the control that opened the dialog. Verification: exercise these behaviors in the implemented interface; this draft alone does not establish conformance.
この入力をプロンプトに読み込み、WebAct にコピーして試してください。結果は掲載例と異なる場合があります。
判断のポイントとトラブル対処。
ユーザーストーリーでテストを代替できますか？
いいえ。期待する動作と確認項目を定めるものです。実装評価には、キーボード、支援技術などの実際の関連テストが必要です。
「アクセシブルにする」が検証しにくいのはなぜですか？
操作と観察可能な結果を明記します。例えば、ダイアログを閉じたら開いた要素にフォーカスを戻す、と書きます。
自分の資料で試しましょう。
タスクのプロンプト内の例を自分の資料に置き換えてください。必要な要件を残し、タスクを WebAct にコピーします。
タスクを調整してコピー ↑