【HTML】キーボード操作で考えるアクセシビリティの基本

はじめに

こんにちは、株式会社TOKOSの優真です。

今回は、HTMLによるWebアクセシビリティを「キーボード操作」の観点から解説します。
WebページのアクセシビリティはHTMLの書き方に左右されます。どの要素を選び、どう組み立てるかによって、操作しやすさが変わります。
普段PCをマウスで操作していると意識しないのですが、マウスを使わずキーボードだけでWebページを操作している方がいます。

そうした操作を妨げないHTMLの書き方は、特別な知識がなくても、基本を押さえるだけで実践できます。
記事内にはキーボード操作を録画した動画も載せているので、あわせて確認してみてください。

対象読者

• HTMLのアクセシビリティに興味がある方
• キーボード操作で生じる問題を知りたい方

キーボード操作とアクセシビリティ

アクセシビリティとは

アクセシビリティとは、年齢や障害の有無にかかわらず誰もがWebページを利用できる状態を指す考え方です。
書籍『Webアプリケーションアクセシビリティ』では「利用可能な状況の幅広さ」と表現されています。
使う人や環境・状態の幅まで含むため、障害のある方や片手がふさがっている時、加齢で操作しづらくなったときなども対象に入ります。
似た言葉に「ユーザビリティ（使いやすさ）」がありますが、視点が異なります。
ユーザビリティが「どれだけ快適に使えるか」に注目する一方、アクセシビリティは「そもそも使えるのか」という、利用できる範囲そのものを広げる考え方です。キーボードで操作しやすいページは、マウスが使えない方にもたまたまマウスが手元にない方にも使いやすくなります。

Webアプリケーションアクセシビリティ（技術評論社）

アクセシビリティとは「利用可能な状況の幅広さ」のこと。より多くの人が、より多くの環境で、より多くの状態で利用できることです。もちろんそこには視覚・上肢・認知などに障害があるケースも含みます。日々繰り返し利用するWebアプリケーションにこそ、アクセシビリティが求められます。 Webサイトに比べて、多くのインタラクションを行うWebアプリケーションでは、アクセシビリティの確保はやや難易度が高いものです。特に既存のWebアプリケーションは複合的な課題を抱えていることが多く、教科書どおりの方法では必ずしも改善できません。 本書では、Webアクセシビリティの基礎である「HTMLとWAI-ARIA」を解説したうえで、Webアプリケーションの要である「フォーム」、色やテキストなど「UIデザインの基本」、モーダルダイアログや通知など「少し複雑なUIパターン」の3分野に分けて、よくある事例を取り上げながら、現実的で段階的な改善方法を紹介します。 さらには、デザインシステムの活用や組織での推進法など、アクセシビリティの取り組みを定着・推進・向上させるためのノウハウも詳説します。

gihyo.jp

その中でも「キーボード操作」は、アクセシビリティの向上に繋がる重要な観点の1つです。

キーボード操作が重要な理由

キーボード操作ができないとWebページ自体を使いこなせない人がいます。たとえば、次のような方です。

• 手の動きに制約があってマウスの細かい操作が難しい方
• 視覚に制約があって画面を直接見ることが難しい方

手の動きに制約がある方は、マウスの代わりにTabキーや矢印キーでフォーカスを動かします。EnterキーやSpaceキーで実行するなど、キーボードだけで画面内を移動します。
視覚に制約がある方は、スクリーンリーダー（画面の内容を音声で読み上げるソフト）とキーボードの専用ショートカット（見出しやリンクへのジャンプなど）を組み合わせて、ページ内の要素をたどりながら操作します。

キーボードだけで操作する方にとって、操作できないボタンやリンクは「存在しないもの」と同じです。

ユウマ

自分で作ったWebが、誰かにとっては使えないものになっているのは悲しいですよね🥲

WCAGの「操作可能」という原則

アクセシビリティには、WCAG（Web Content Accessibility Guidelines）という国際的なガイドラインがあります。
このWCAGは「知覚可能」「操作可能」「理解可能」「堅牢」という4つの原則で構成されています。

このうちキーボード操作と深く関わるのが、**操作可能（Operable）**の原則です。
これは、ユーザーインターフェイスのコンポーネントやナビゲーションが操作できる状態でなければならない、という考え方です。

「操作可能」はさらに細かい達成基準に分かれていますが、本記事で扱うポイントは、次の基準と対応しています。

各ポイントの解説のなかで、対応する基準もあわせて紹介していきます。

操作可能アクセシビリティ（MDN Web Docs）

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の操作可能原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 操作可能とは、ユーザーインターフェイス・コンポーネントとナビゲーションが操作可能でなければならないということです。

developer.mozilla.org

キーボード操作の基本

キーボードだけでWebページを操作するとき、主に次のキーを使います。

Tabキー・Shift+Tabキーでフォーカスを移動する

Tabキーを押すと、リンクやボタン、入力欄など操作できる要素へ順番にフォーカスが移っていきます。
フォーカスとは「いまどの要素を選んでいるか」を示す状態のことです。

下記の動画では、Tabキーを押すたびにリンクへ順番にフォーカスが移り、フォーカスの当たった要素に枠線（フォーカスリング）が表示されています。
画面下の「フォーカス状態」には、いまどの要素にフォーカスがあるかが表示されています。

この枠線を目で追うことで、いま自分がどこを操作しようとしているかが分かります。

Enterキー・Spaceキーで実行する

フォーカスを当てた状態で、EnterキーやSpaceキーを押すと、その要素が実行されます。

下記の動画では、リンクはEnterキーで、ボタンはSpaceキーで実行できていることが確認できます。

キーボードだけで操作できるようにする

最初のテクニックは、もっとも基本的で効果の大きいポイントです。
「ボタンやリンクを、正しいHTML要素で作る」というだけの話ですが、これを外すとキーボードで操作できなくなります。

問題のあるコード例（divタグをbuttonタグにする）

見た目を整えやすいという理由で、divタグにクリックイベントを付けてボタンのように使うことがあります。

<div class="button">送信</div>

CSSで見た目をボタンらしく整えれば、マウスで使う分には問題なく動きます。
しかし、ここに落とし穴があります。

Tabキーでどうなるか

このページをキーボードで操作しようとすると、次の問題が起きます。

• Tabキーを押しても、この「送信」にフォーカスが当たらない
• そもそも到達できないので、Enterキーを押して実行できない

下記の動画では、Tabキーで上の「お問い合わせ」リンクと下の「キャンセル」ボタンにはフォーカスが当たりますが、divタグで作った真ん中の「送信」だけが飛ばされています。

divタグはもともと操作するための要素ではないため、Tabキーの移動先（フォーカスの対象）になりません。
つまり、マウスを使えないユーザーは、このボタンを永遠に押せません。

改善方法（buttonタグとaタグを使う）

解決方法はとてもシンプルで、用途に合ったHTML要素を使うだけです。
これは「セマンティックHTML」と呼ばれる考え方です。

セマンティックHTMLとは、見た目ではなく「その要素がどんな意味・役割を持つか」に基づいてマークアップすることです。MDNの用語集でも、セマンティクスとはコードが持つ意味のことで、HTMLでいえば要素が果たす目的や役割を指す（どう見えるかではない）と説明されています。
見た目を整えるのはCSSの役割で、HTMLは「中身が何であるか」を表すために使う、というわけです。
意味に合った要素を使うと、ブラウザや支援技術がその役割を正しく理解できます。たとえばbuttonタグを使えば「これはボタンだ」と伝わり、キーボード操作などの機能も自動で備わります。
具体的には、用途に合わせて次のように要素を選びます。

• ページ内で何かを実行する（送信、開閉など）→ buttonタグ
• 別のページへ移動する → aタグ

Semantics（セマンティクス）（MDN Web Docs）

プログラミングでは、セマンティクス (semantics) とは、コードの断片の意味を指します。たとえば、「JavaScript でその行を実行すると、どのような効果があるのか？」、「その HTML 要素には、どのような目的や役割があるのか？」 (「どのように見えるのか？」ではなく)。

developer.mozilla.org

<!-- 何かを実行するならbutton -->
<button type="button">送信</button>
 
<!-- ページ移動ならa -->
<a href="/contact">お問い合わせ</a>

buttonタグやaタグは、最初からキーボード操作に対応しています。
Tabキーでフォーカスが当たり、Enterキー（buttonタグならSpaceキーも）で実行できます。
特別な属性を追加しなくても、ブラウザがこれらの動作を自動で備えているのです。

下記の動画では、buttonタグに変えた「送信」にもきちんとフォーカスが当たり、操作できるようになっています。

フォーカスの当たり順を整える

正しい要素を使えていても、次に問題になりやすいのが「フォーカスの当たる順番」です。
Tabキーで移動したときに、意図しない順番で飛んでしまうと操作しづらくなります。

問題のあるコード例（見た目と並び順がずれている）

CSSで要素の位置を入れ替えると、HTMLの並び順はそのままに、画面上の見た目だけがずれてしまう場合があります。

<!-- HTML上は「キャンセル → 送信」の順 -->
<div class="buttons">
  <button type="button">キャンセル</button>
  <button type="submit">送信</button>
</div>

/* 見た目だけ左右を入れ替える */
.buttons {
  display: flex;
  flex-direction: row-reverse;
}

この場合、画面では「送信」が左、「キャンセル」が右に表示されます。
しかしTabキーの移動順は、見た目ではなくHTMLの並び順に従います。

Tabキーでどうなるか

Tabキーを押すと、画面の見た目とは逆の順序でフォーカスが移動します。

• 見た目の並び：送信（左）→ キャンセル（右）
• フォーカスの移動順：キャンセル → 送信

下記の動画では、左にある「送信」より先に、右の「キャンセル」にフォーカスが当たっています。
見た目は左から右に並んでいるのに、フォーカスは右の要素から先に当たっているのが分かります。

目で見ている順番とフォーカスの動きが食い違うため、キーボードユーザーは混乱しやすくなります。
左から押していくつもりが、思っていたボタンと違うものにフォーカスが当たってしまうのです。

改善方法（DOM順を見た目に合わせる）

基本方針は「見た目の順番とHTMLの並び順をできるだけ一致させる」ことです。
CSSで順序を入れ替えるのではなく、HTMLの記述順そのものを見た目に合わせるのが確実です。

<!-- 見た目の順番どおりにHTMLを書く -->
<div class="buttons">
  <button type="submit">送信</button>
  <button type="button">キャンセル</button>
</div>

下記の動画では、見た目とTabキー順が一致し、左の「送信」から右の「キャンセル」へ自然な順番でフォーカスが移動しています。

tabindexでフォーカス順を変えるのは非推奨

ここまで「フォーカスの当たり順」を見てきましたが、関連してよく登場するtabindexという属性についても触れておきます。

tabindex（タブインデックス）は、要素のフォーカスの扱いを制御するためのHTMLのグローバル属性です。
通常はTabキーでフォーカスが当たるのはリンクやボタンや入力欄といった操作可能な要素だけです。tabindexを使うと、それ以外の要素をフォーカスできるようにしたり、逆にフォーカスの順序から外したりできます。

ここで、「tabindexを使えばフォーカス順を直接指定できるのでは？」と思った方もいるかもしれません。
tabindexは、次の3パターンの値を取ります。

一見すると、正の値で並び順の問題を直せるように思えます。次のような書き方です。

<!-- 正の値のtabindexでTabキー順を無理やり指定する -->
<div class="buttons">
  <button type="submit" tabindex="1">送信</button>
  <button type="button" tabindex="2">キャンセル</button>
</div>

しかし正の値には、次のような問題があります。

• ページ全体の管理が破綻する：正の値のtabindexを付けた要素は、通常のリンクやボタンよりもすべて先にフォーカスされます。一部の要素にだけ付けると、ページ全体のフォーカス順が乱れてしまいます
• 要素を追加するたびに番号を振り直す必要がある：後からボタンを1つ足すだけで、関連する番号をすべて付け替えなければならず、保守が一気に大変になります
• そもそも根本解決になっていない：見た目とDOM順がずれているという本当の原因はそのまま残ります

下記の動画は、ボタンに正の値のtabindexを付けた例です。
本来なら上にある「お問い合わせ」リンクから先にフォーカスされるはずです。しかしtabindexを付けた「送信」「キャンセル」ボタンへ先にフォーカスが移ってしまいます。その結果、Tabキー順が「送信 → キャンセル → お問い合わせ → 戻る」という不自然な並びになっています。

MDNでも、正の値のtabindexは避けるよう警告されています。

tabindex に正の値を使わないでください。 tabindex に正の値を持つ要素は、ページ上の既定のインタラクティブ要素の前に配置されます。

キーボードで操作可能な JavaScript ウィジェット（MDN Web Docs）

ウェブアプリケーションは、メニュー、ツリービュー、リッチテキストフィールド、タブパネルなどのデスクトップウィジェットを模倣するために JavaScript を使用することがよくあります。 これらのウィジェットは通常、 <div> 要素や <span> 要素で構成されています。これらの要素は本来、デスクトップのものと同じキーボード機能を提供しません。 このドキュメントは JavaScript ウィジェットをキーボードでアクセス可能にするためのテクニックを説明します。

developer.mozilla.org

HTML: アクセシビリティの良き基本（MDN Web Docs）

正しい HTML 言語の要素を常に正しい目的のために使用するようにするだけで、多くのウェブコンテンツをアクセシビリティに対応させることができます。この記事では、アクセシビリティを確実にするために HTML を使用する方法について詳しく見ていきます。

developer.mozilla.org

では、tabindexはどう使うのが良いのでしょうか。値は0または-1に限定するのが安全です。
0は本来フォーカスできない要素をフォーカス可能にしたいとき、-1はスクリプトからフォーカスを当てたいとき（モーダルを開いた直後など）に使います。
いずれもフォーカス「順」を操作するものではない、という点がポイントです。

フォーカスの順番が論理的であることは、WCAGの達成基準「2.4.3フォーカス順序」に対応します。
タブ移動の順序が意味のある並びになっていれば、キーボードで操作する人にとって、画面を見ている場合も見ていない場合も使いやすいページになります。

フォーカスリングを消さない

最後は、見落とされがちですが重要なポイントです。
「いまどこにフォーカスが当たっているか」が見える状態を保つことです。

問題のあるコード例（outline: none）

要素にフォーカスが当たると表示される枠線（フォーカスリング）を、outline: noneで消してしまっているケースは意外とよくあります。
原因のひとつが、リセットCSSや自前の初期化スタイルでoutlineをまとめて消していることです。自分では消した覚えがなくても、次のような指定がどこかに入っていると、気づかないうちにフォーカスリングが消えます。

/* リセットCSSなどでまとめて消してしまいがち */
*:focus {
  outline: none;
}

ほかにも、ボタンの見た目を整える過程で:focusのスタイルごと上書きしてしまうケースや、標準のフォーカスリングの見た目がデザインに合わないからと意図的に消すケースがあります。
いずれにせよ、マウスで操作している分には見た目がすっきりして、問題に気づきにくいのが厄介なところです。

Tabキーでどうなるか

しかしキーボードで操作すると、深刻な問題が起きます。

• Tabキーを押しても、今どの要素にフォーカスが当たっているか分からない
• どこを操作しようとしているのか見失い、操作不能に近い状態になる

下記の動画では、上の「お問い合わせ」と下の「キャンセル」には枠線が見えます。outline: noneを指定した真ん中の「ボタン」だけは、フォーカスが当たっても見た目が変わりません。
画面下の「フォーカス状態」では中央のボタンにフォーカスが移っているのに、画面上ではその位置が分からない状態です。

フォーカスリングは、キーボードユーザーが「いま自分がどこにいるか」を把握するための重要な手がかりです。
これを消してしまうと、マウスで操作しているときにカーソルが見えないのと近い状況になり、操作がとても難しくなります。

改善方法（:focus-visibleで見やすく示す）

「マウス操作のときは枠線を出さず、キーボード操作のときだけ枠線を出したい」という要望には、:focus-visibleが使えます。

:focus-visibleは、ブラウザが「キーボード操作によるフォーカス」と判断したときだけ適用される擬似クラスです。
これを使えば、マウスクリック時には枠線を出さず、Tabキーでの移動時にはしっかり枠線を表示できます。

/* キーボード操作のときだけ、見やすい枠線を表示する */
button:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

:focus-visibleはSafariを含むすべての主要ブラウザが対応済みなので、いまはこのシンプルな書き方で問題ありません。
マウスクリック時にはブラウザが「キーボード操作ではない」と判断して枠線を出さず、Tabキーでの移動時だけ上のスタイルが適用されます。

:focus-visible非対応の古いブラウザにも備えるなら、:focus:not(:focus-visible)でマウス操作時の枠線だけを消す書き方もあります。:focus-visibleが効かない環境では:focusのスタイルが残るため、フォーカスリングが消えにくくなります。必須ではなく、より慎重に対応したい場合の選択肢です。

/* （任意）未対応ブラウザにも備える書き方 */
button:focus:not(:focus-visible) {
  outline: none;
}
 
button:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

下記の動画では、真ん中のボタンにもTabキーでの移動時にしっかり枠線が表示され、フォーカス位置が分かるようになっています。

これで、マウスユーザーには余計な枠線を見せず、キーボードユーザーにはフォーカス位置をはっきり示すことができます。
枠線のデザイン（色や太さ）は、背景とのコントラストを確保しつつ、サイトに合わせて調整してください。

この「フォーカス位置が目で見えること」は、WCAGの達成基準「2.4.7フォーカスの可視化」に対応します。
タブ移動したときに、どの要素にフォーカスがあるかを示す視覚的な目印が必要、とされています。outlineを消す場合も、必ず代わりの見た目を残すことが大切です。

補足情報

本記事ではキーボード操作の基本に絞って解説しました。
さらに踏み込んで対応する場合は、次のようなキーワードも知っておくと役立ちます。

• スキップリンク：ナビゲーションを飛ばして本文へ直接移動できるリンク
• フォーカストラップ：モーダルを開いている間、フォーカスをその中にとどめる手法
• WAI-ARIA：HTMLだけでは補えない役割や状態を伝えるための仕様（まずは正しいHTML要素を使うのが優先）

スキップリンクの実装は、MDNのHTML機能ガイドで解説されています。

アクセシビリティを推進する HTML の機能（MDN Web Docs）

以下のコンテンツは、さまざまな障害を持つ人々にとってウェブページのアクセシビリティをより高めるために使用できる HTML の特定の機能について説明しています。

developer.mozilla.org

フォーカストラップはモーダルUIでよく使われます。当ブログでもReact Ariaを使ったアクセシビリティ対応モーダルの記事があります。

React Ariaを使用したモーダル作成

ReactのライブラリであるReact Ariaを使用したモーダル作成を紹介しています。アクセシビリティ対応のモーダルが簡単に作成できます！

WAI-ARIAの概要は、MDNのアクセシビリティセクションが参考になります。

ARIA（MDN Web Docs）

Accessible Rich Internet Applications (ARIA) はロールや属性の集合で、ウェブコンテンツやウェブアプリケーション（特に JavaScript で開発するもの）を、ハンディキャップを持つ人々にとってよりアクセシブルにする方法を定義します。

developer.mozilla.org

キーボード操作はアクセシビリティの向上に繋がる要素の1つにすぎません。
スクリーンリーダーでの読み上げや色のコントラストなど、ほかの観点も含めた全体像は、MDNのアクセシビリティガイドが参考になります。

アクセシビリティ（MDN Web Docs）

ウェブ開発においてアクセシビリティ （Accessibility、よく A11y と略されます）とは、何らかの理由により能力に制約がある場合でも、可能な限り多くの人々がウェブサイトを使用できるようにすることを意味します。

developer.mozilla.org

おわりに

この記事では、HTMLのアクセシビリティを「キーボード操作」という視点から紹介しました。

• マウスを使えないユーザーのために、キーボードだけで操作できることが重要
• ボタンやリンクはbuttonタグ・aタグを使えば、キーボード操作に自動で対応できる
• フォーカスの当たり順は、HTMLの並び順で自然に整えるのが基本
• フォーカスリングは消さず、:focus-visibleで見やすく示す
• これらはWCAGの「操作可能」原則（2.1.1・2.4.3・2.4.7など）に対応している

ぜひ皆さんのサイトでも、一度キーボードだけで操作して確かめてみてください。