AIで作ったWebアプリのアクセシビリティ確認：キーボードと拡大で3操作を点検する

マウスで使えた画面でも、キーボードではボタンへ進めなかったり、拡大すると入力欄が見切れたりする場合があります。AIが画面を生成した後は、見た目や通常操作と別に確認します。今回は架空のメモ登録画面で「入力・送信・エラー修正」の3操作を点検します。

確認条件をそろえる

使ったブラウザ、画面幅、拡大率、操作方法を記録します。まずマウスを使わずにTabとShift+Tabで移動し、フォーカス位置が見えるか確認します。操作中に見えなくなった場所は、どのキーでどの要素へ移動したときかを書きます。W3CのEasy Checksも、フォーカス表示やフォームなどを初期確認の対象にしています。［出典1］

3操作の期待結果を先に書く

操作	期待する状態	記録する失敗
入力欄へ進む	入力欄にフォーカスが当たり、名前と入力内容が分かる	飛ばされる、順序が不自然、ラベルが分からない
送信する	キーボードで送信ボタンを操作でき、完了が分かる	クリックでしか動かない、送信後の状態が不明
空欄のエラーを直す	どの項目をどう直すか分かり、入力へ戻れる	色だけのエラー、入力欄へ戻れない

空欄、短い本文、長い本文の3入力で繰り返します。長文でレイアウトが崩れるか、エラー時に別の場所へ飛ばされるかも確認できます。

見た目がボタンでも、操作できる要素とは限らない

生成されたHTMLが<div onclick="...">送信</div>だけなら、見た目はボタンでも標準のボタンの操作性がありません。通常の送信操作には、役割に合った要素を使う方針から確認します。

<form>
  <label for="memo">メモ本文</label>
  <textarea id="memo" name="memo"></textarea>
  <button type="submit">保存する</button>
</form>

これはラベルと入力、標準ボタンを示す最小HTMLです。エラー表示や保存処理を含まないため、これだけでアプリ全体の確認が終わるわけではありません。aria属性を増やせば自動的によくなるとも考えず、標準要素で表せるかを先に見ます。

拡大したときは、見切れと操作順を確認する

ブラウザの拡大機能を使い、入力欄、ボタン、エラー文を読めるか確認します。教材の確認条件として200%を使う場合は、その条件を記録し、画面幅も添えます。横スクロールが必要になったり固定ボタンが入力を隠したりしたら、再現手順と対象要素を残します。これだけをもって特定の規格への適合を認定するものではありません。

読み上げと自動検査の結果を混ぜない

スクリーンリーダーを使える場合は、入力欄の名前、送信ボタンの名前、エラーと完了通知を確認します。使っていなければ「読み上げ未確認」と残します。自動検査ツールで問題が0件でも、人の操作でしか分からない点が残るため、完全な適合証明として扱わないでください。［出典2］

AIへ返す修正依頼を具体化する

ブラウザを200%へ拡大すると、保存ボタンがメモ入力欄を隠します。キーボードで入力欄から保存へ進む操作でも再現します。入力内容が見えるようにレイアウトを直し、標準のフォーカス表示と操作順を維持してください。既存の保存処理は変更しないでください。

修正後は同じ条件で再確認します。「アクセシビリティを改善して」だけより、再現条件と期待結果を渡す方が、変更した場所と直った問題をレビューしやすくなります。

出典

W3C WAI: Easy Checks（初期確認用。ページ自体にDraft表示あり）。
W3C WAI: Evaluating Web Accessibility。