実装 インタラクション

チェック項目

「ボタンの使用」とは

レベル1：必ず達成

ユーザーのクリックやタップを起点にしてインタラクションが発生する場合、他に適切な要素がなければ、トリガーの要素にはbutton要素を使用してください。

button要素はデフォルトでキーボードフォーカスを受け取り、スペースバーを含むキーボード操作によってクリックイベントを発生させることができます。a要素やspan要素にJavaScriptでこれらの挙動を模倣して作るのは実装面・テスト面で大きなコストになりえます。

ヒント：ボタンが持つデフォルトスタイルをリセットする

button {
  margin: 0;
  padding: 0;
  color: inherit;
  background: none;
  font-size: 100%;
  line-height: inherit;
  font-family: inherit;
  font-weight: inherit;
  text-transform: none;
}

チェック項目

「挿入されるコンテンツ」とは

レベル1：必ず達成

サブメニューやモーダルダイアログ、ディスクロージャー、「もっと見る」による追加読み込みなど、コンテンツが動的に追加・表示されるUIについて、そのコンテンツのDOMノードは操作の起点（トリガー）の直後になるようにしてください。トリガーの直後にコンテンツが挿入されることで、キーボードやスクリーンリーダーを使用したときに、トリガーの操作後に自然な流れで操作や読み上げを続けることができます。

JavaScriptによってフォーカス位置を制御できる場合、このガイドラインは必須ではありません。

チェック項目

「フォーカスインジケーター」とは

レベル1：必ず達成

フォーカスインジケーターが不可視にされていると、キーボードユーザーはフォーカスの現在位置がわからず、操作を続けることができなくなってしまいます。

また、フォーカスインジケーターを取り除くためにHTMLElement.blur()を使用すると、フォーカス位置が失われ、キーボード操作を再度先頭からやり直さなければいけなくなってしまうかもしれません。

ヒント：キーボード操作時だけフォーカスのスタイルを適用する

:focus疑似クラスを使用すると、マウスやタッチ操作で選択したときにもスタイルが適用されます。キーボード操作時のみスタイルを適用したい場合、かわりに:focus-visible疑似クラスを使用します。

ヒント：フォーカスを受け取ったUIが追従コンテンツによって隠されないようにする

ページをTabキーで下に移動すると、フォーカスの当たった要素が表示領域に収まるようにスクロールを伴いますが、追従ヘッダ等がある場合、それによってフォーカスされたUIが隠れてしまうケースがあります。このような場合、scroll-paddingプロパティを設定することで要素の重なりを回避することができます。

ヒント：Cookieの利用同意を求めるモーダルダイアログにフォーカスを移動する

Cookie利用同意のポップアップはしばしばダイアログとして実装され、ページの読み込み後すぐに表示されます。 このダイアログを背面と対話可能なモードレスダイアログとして実装すると、背面のUIがダイアログに完全に隠され、操作が困難になる可能性があります。この問題を回避するため、ダイアログはモーダルとして実装し、閉じるまでフォーカスが外側のコンテンツに移動しないようにすることが推奨されます。

チェック項目

「ズームの許容」とは

レベル1：必ず達成

ロービジョンのユーザーを含む一部のユーザーにとっては、画面を任意の大きさにズームして表示できることは極めて重要です。そのような人にとって、ウェブサイトがズームを禁止しているとウェブサイトを利用できなくなることがあります。ズームされると大多数のユーザーに致命的な問題が起きない限り、ズームを許容してください。

ヒント：入力フィールドにフォーカスしたときに画面がズームしないようにする

iOS Safariにおいて、ユーザーが入力フィールドにフォーカスすると画面が自動的にズームすることがあります。入力フィールドの文字サイズを16px以上にすることでこの挙動を抑止できます。

チェック項目

「文脈に応じたフォーカス」とは

レベル2：可能な限り達成

キーボードやスクリーンリーダーなどのシーケンシャルな操作体系の環境でスムーズに操作を行えるように、ユーザーの操作に応じた適切な位置にフォーカスを移動してください。

参考情報

• Dialog (Modal) Pattern
  ダイアログが閉じたときのフォーカス移動先について有用なガイドがあります

チェック項目

「Escapeキー操作」とは

レベル2：可能な限り達成

Escapeキーは「現在のコンテキストから抜ける」ための慣習的に用いられているキー操作です。ポップアップメニューやダイアログ、ツールチップなど、一時的に、ほかのコンテンツより前面に表示されるコンテンツをEscapeキーで閉じられるようにしてください。

チェック項目

「隠されているコンテンツ」とは

レベル2：可能な限り達成

DOMツリー上には存在するものの非表示にされているコンテンツは、意図的にそうしていない限り、キーボードや支援技術からもアクセスできないようにしてください。

キーボードや支援技術からもアクセスできてしまう非表示コンテンツとは、例えば次ような方法で非表示にしたコンテンツです。

• opacityを0にする
• overflow: hiddenとwidthやheight、clipを使ってコンテンツの一部分または全部を切り取る
• positionやtransformなどを使って画面外ないし親要素の範囲外に追いやる

チェック項目

「ホバーで表示されるコンテンツ」とは

レベル2：可能な限り達成

ホバーやフォーカスがコンテンツ表示のトリガーとなっている場合、ユーザーによって明示的に閉じられるまでそのコンテンツを表示し続けてください。トリガーからポインターやフォーカスが外れた時点でコンテンツを非表示にしたり、時限式に閉じることは避けてください。

明示的に閉じる操作とは例えば次のような操作です。

• Escapeキーが押される
• 表示されたコンテンツの中の閉じるボタンが選択される
• トリガーとコンテンツの両方からポインターが外れ、0.5秒以上が経過する
• トリガーとコンテンツとは無関係の場所がクリックされる

チェック項目

「外部コンテンツおよびUIライブラリ」とは

レベル2：可能な限り達成

アクセシビリティはページ全体として評価されるため、採用している外部のUIライブラリや、iframeとして埋め込んでいる外部コンテンツもアクセシビリティに配慮したつくりになっている必要があります。

チェック項目

「WAI-ARIA」とは

レベル2：可能な限り達成

インタラクションを含むUIはHTMLのセマンティクスに加えてWAI-ARIAを実装することでアクセシビリティを高められることがあります。

WAI-ARIAに定義された役割やステート、プロパティは、想定されていない使われ方をすると逆にアクセシビリティを損なうことがあります。使い方について不明瞭な箇所があれば、社内のエキスパートに相談してください。

チェック項目

「背後のコンテンツ」とは

レベル3：できれば考慮

ダイアログなどのモーダルコンテンツが表示されているとき、背後に隠されたコンテンツはキーボードや支援技術からアクセスされないようにしてください。

参考情報

• focus-trap - npm
  指定した要素の外側にフォーカスできないようにするためのライブラリ
• wicg-inert - npm
  指定した要素をキーボード操作不能にし、アクセシビリティツリーからも除外するinert属性のためのポリフィルライブラリ

※あくまで参考であり、実装方法を指定するものではありません。

チェック項目

「ダウンイベントの使用」とは

レベル3：できれば考慮

ダウンイベント（mousedown, pointerdown, touchstart）を機能実行のトリガーにしていると、細かい動作が苦手なユーザーは意図せず機能を実行してしまうことがあります。かわりにアップイベント（mouseup, pointerup, touchend）や、click, input, changeのような、より意図に近いイベントを用いるようにしてください。

チェック項目

「ドラッグ操作の中断」とは

レベル3：できれば考慮

UIがドラッグアンドドロップ操作を求めるとき、ドラッグの途中で操作を中止する手段を設けてください。中止する手段の例としては次のようなものがあります。

• ドロップエリアは画面の中の一部分であり、それ以外の箇所にドロップしても何も起こらない
• ドロップ操作をした後、簡単な操作で元に戻すことができる
• ドラッグ中にEscapeキーを押すとドラッグ操作を中止できる

チェック項目

「ステータスの通知」とは

レベル3：できれば考慮

アプリケーションの状態変化や通知メッセージをUIに表示する場合、スクリーンリーダー等の支援技術にも同様の情報を伝える必要があります。WAI-ARIAのライブリージョンを使うことで実現可能です。