こんにちは、道洋行東京支店Web制作スタッフのT.Y.です。
今回は「2.1.1 キーボードの達成基準」への対応について解説します。Webサイトは「見える」だけでなく「操作できる」ことがとても重要です。特にキーボード操作への配慮は、多くのユーザーの利用体験を左右します。
もくじ
「キーボードの達成基準」と聞くと、少し専門的に感じるかもしれません。しかし考え方はとてもシンプルで、“マウスを使わなくても、すべての操作ができるか”ということです。
手の動きに制限がある方、視覚に障害がある方、あるいはキーボード操作の方が速いパワーユーザーなど、Webをキーボードだけで操作する人は意外と多くいます。
WCAG 2.1の達成基準「2.1.1 キーボード」は、リンクのクリック、メニューの開閉、フォームの送信、モーダルの操作など、すべての機能がキーボードのみで操作できることを求めています。
よくあるのが、「ほとんど操作できるのに、最後の送信ボタンだけクリックできない」「ハンバーガーメニューが開けない」といったケースです。
これはユーザー体験としては致命的で、「せっかくここまで来たのに使えない」という不満につながります。2.1.1は、そうした最後の壁をなくすための基準とも言えます。
まず最初に確認したいのが、Tabキーでフォーカスが順番に移動できるかです。リンクやボタン、フォーム入力欄など、操作できる要素にきちんとフォーカスが当たる必要があります。
このとき、見た目上も「今どこを操作しているのか」が分かるように、フォーカスリング(枠線など)が表示されているかも重要です。
CSSで outline: none; を指定して消してしまっているサイトも見かけますが、これはアクセシビリティの観点ではNGです。デザインを整えたい場合でも、代替となるフォーカススタイルを必ず用意しましょう。
リンクはEnterキー、ボタンはEnterやSpaceキーで実行できるのが基本です。
JavaScriptで独自のUIを作る場合、div や span にクリックイベントだけを付けていると、キーボード操作ができません。この場合は、button 要素を使うか、tabindex と keydown イベントを適切に設定する必要があります。
近年のWeb制作では、モーダルウィンドウやドロップダウンメニューなど、動的なUIが当たり前になっています。しかし、ここがキーボード非対応になりやすい落とし穴でもあります。
例えばモーダルを開いたとき、
といった点を意識しないと、キーボードユーザーは操作不能になります。これは実装段階での細かい配慮が必要な部分で、Web制作会社の技術力が問われるところでもあります。
tabindex を使えば、フォーカスの順番を制御できますが、むやみに指定すると逆に操作しづらくなります。基本はHTMLの自然な順序に任せるのがベストで、どうしても必要な場合だけ最小限に使うのがコツです。
一番シンプルで効果的なのが、マウスを使わずにサイトを操作してみることです。
トップページからお問い合わせフォームの送信まで、すべてキーボードでたどってみてください。途中で詰まる箇所があれば、そこが改善ポイントです。
アクセシビリティチェックツールでも、キーボードに関する指摘はある程度拾えます。ただし、実際の操作感までは分かりません。
ツールで機械的にチェックし、人の手で実際に操作する。この二段構えが、品質の高いWeb制作には欠かせません。
行政機関や公共性の高いサイトでは、Webアクセシビリティへの対応が事実上の必須要件になりつつあります。
キーボード操作に対応していないだけで、入札や案件の評価が下がるケースも現実にあります。
キーボード対応は、特定の人のためだけのものではありません。
検索が多い業務サイト、入力作業が多い管理画面などでは、キーボード操作ができる方が誰にとっても効率的です。結果として、離脱率の低下やコンバージョン改善にもつながります。
「2.1.1 キーボードの達成基準」は、
Webアクセシビリティというと難しく感じがちですが、「マウスなしで使えるか?」という視点で見ると、一気に現実的になります。
これからのWeb制作では、こうした“操作できるアクセシビリティ”がますます重要になっていきます。
当社サービスに関するご相談・お見積もりなど、お気軽にお問い合わせください。