WCAG 2.2「3.2.1 フォーカス時の動作」とは?Level Aの実装例と確認方法

woman in discussing a lesson plan
Photo by Andrea Piacquadio on Pexels.com

WCAG ​2.2の達成基準3.2.1「フォーカス時の動作」は、リンクや入力欄などがフォーカスを受け取っただけで、ページ移動や新しいウィンドウの表示といった文脈の変化を起こさないことを求めています。

適合レベルはAです。

キーボードで順番に操作項目を確認している途中に画面が切り替わると、利用者は現在位置や次に行う操作を見失いやすくなります。

実装では、フォーカスを受け取ることと、利用者が機能を実行することを分けて考える必要があります。

達成基準3.2.1が求めること

フォーカスとは、リンク、ボタン、入力欄などがキーボード入力を受け取れる状態になることです。

利用者はTabキーやShift+Tabキーでフォーカスを移動でき、入力欄をクリックしたときにもフォーカスが移る場合があります。

文脈の変化とは、利用者が現在の場所や操作対象を捉え直さなければならないほど大きな変化を指します。

代表例は次のとおりです。

  • 別のページへ移動する、またはページを再読み込みする
  • 新しいウィンドウやタブを開く
  • フォーカスを別の操作項目へ移す、または消す
  • ページの意味が変わるほど主要な内容を入れ替える

したがって、Tabキーで操作項目へ移動しただけで、これらの変化が起きる実装は避けます。

フォーカスと実行操作の違い

実行操作は、フォーカスを合わせることではなく、リンクやボタンの機能を利用者が意図して動かす操作です。

キーボードではEnterキーやSpaceキー、ポインティングデバイスではクリックなどが該当します。

状態 具体例 設計上の扱い
フォーカス Tabキーでリンクへ移動する 移動しただけでは文脈を変えない
実行操作 フォーカス中のリンクでEnterキーを押す 利用者が予測できるページ移動を実行できる
値の変更 選択肢や入力内容を変更する フォーカスとは別に、入力時の動作も確認する

なお、内容が変わるだけで直ちに文脈の変化になるわけではありません。

入力欄の説明が近くに表示されても、現在位置やページの意味が変わらなければ、達成基準3.2.1の禁止対象とは限りません。

表示内容だけでなく、フォーカスの移動、画面遷移、主要部分の入れ替えまで確認して判断します。

フォーカスだけでページを移動させない

次の例では、リンクがフォーカスを受け取った瞬間にページが移動します。

キーボード利用者はリンクの内容を確認してから実行する余地がありません。

<a ​href="/next-page/" ​onfocus="window.location.href=this.href;">
 ​ ​次のページ
</a>

通常のリンクとして実装すれば、フォーカスを合わせた段階では何も起こらず、利用者がリンクを実行したときにだけ移動します。

<a ​href="/next-page/">次のページ</a>

ボタンで画面を切り替える場合も、フォーカスイベントではなく、ボタンの実行操作に処理を結び付けます。

選択肢の変更とフォーカスを混同しない

select要素のchangeイベントは、フォーカスを受け取った瞬間ではなく、選択値が変わったときに発生します。

そのため、選択と同時にページを移動する実装は、達成基準3.2.1だけでなく、達成基準3.2.2「入力時の動作」と分けて確認する必要があります。

移動先の選択と実行を分けると、利用者は選択内容を確かめてから移動できます。

<label ​for="destination">移動先</label>
<select ​id="destination" ​name="destination">
 ​ ​<option ​value="/page1/">ページ1</option>
 ​ ​<option ​value="/page2/">ページ2</option>
</select>
<button ​type="button" ​id="move-button">
 ​ ​選択したページへ移動
</button>

ページ移動の処理は、選択欄のフォーカスや値変更ではなく、「選択したページへ移動」ボタンの実行操作に結び付けます。

フォーカスを強制的に外さない

フォーカスを受け取った要素でblur()を実行すると、キーボード利用者はその操作項目に留まれません。

<input ​type="text" ​onfocus="this.blur();">

フォーカスは、利用者が次の項目へ移るまで維持します。

ブラウザが表示するフォーカスの目印も安易に消さず、キーボード操作とフォーカス表示の設計も合わせて確認します。

<label ​for="name">氏名</label>
<input ​type="text" ​id="name" ​name="name">

新しいタブを開く場合の考え方

フォーカスを受け取っただけで新しいタブを開く実装は避けます。

利用者がリンクを実行した後に新しいタブを開く場合は、リンク文言で事前に知らせると動作を予測しやすくなります。

<a ​href="example.html" ​target="_blank">
 ​ ​利用案内(新しいタブで開きます)
</a>

ここでの判定点は、新しいタブを使うこと自体ではなく、フォーカスだけで予期しない切り替えが起きないことです。

手動テストの手順

フォーカス時の動作は、実際にキーボードとポインティングデバイスで操作して確認します。

  1. ページの先頭からTabキーを押し、リンク、ボタン、入力欄、選択欄を順番に移動する
  2. 各項目がフォーカスを受け取った瞬間に、ページ移動、再読み込み、新しいタブの表示、フォーム送信が起きないことを確認する
  3. フォーカスが勝手に別の項目へ移ったり、ページから消えたりしないことを確認する
  4. EnterキーやSpaceキーで操作項目を実行し、意図した機能がその時点で動くことを確認する
  5. 入力欄をクリックした場合にも、フォーカスだけで文脈が変わらないことを確認する

AxeやWAVEなどの検査ツールは、関連する実装上の問題を探す補助として利用できます。

ただし、フォーカスを受け取った瞬間の動作や、変化が利用者の現在位置を変えるかどうかは、手動操作でも確認します。

実装とレビューのチェックリスト

  • フォーカスイベントでページ移動、再読み込み、フォーム送信を実行していない
  • フォーカスイベントで新しいウィンドウやタブを開いていない
  • blur()などでフォーカスを強制的に外していない
  • ページを変える処理は、リンクやボタンの実行操作に結び付いている
  • 選択値の変更による動作を、フォーカス時の動作と分けて確認している
  • 自動検査だけで終えず、キーボードとマウスで挙動を確認している

利用者が現在位置を保てる設計にする

達成基準3.2.1への対応では、利用者が操作項目へ移動しただけで現在位置を失わない設計が求められます。

フォーカスは確認の段階、リンクやボタンの実行は機能を動かす段階として分ければ、予測しやすい操作の流れを作れます。

当社では、Webアクセシビリティを導入しやすくするUUU ​ウェブアクセシビリティを提供しています。

サイトの操作性やアクセシビリティ改善を検討している方は、サービスの詳細をご覧ください。

投稿者 greeden

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)