ブロックスキップを考える

ウェブアクセシビリティのガイドライン (W3C 勧告) である WCAG 2.0 に、「ブロックスキップ」という達成基準があります。

2.4.1 ブロックスキップ: 複数のウェブページ上で繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる。 (レベル A)

出典 : WCAG 2.0 解説書「達成基準 2.4.1 を理解する

グローバルナビゲーションなどサイト共通のブロック (塊) を任意で読み飛ばせるようにして、メインコンテンツにスムーズにアクセスできるようにしましょう、というものです。達成方法には大きく分けて、1) スキップリンクを設置する方法と、2) 見出し要素や WAI-ARIA ランドマークを適切にマークアップする方法、のふたつがあります (参考 : WCAG 2.0 解説書「達成基準 2.4.1 を理解する (達成方法及び失敗例)」)。

このうち後者 (適切なマークアップ) は真っ当なウェブサイト制作をしていれば自ずと実現できるとして、前者 (スキップリンク、つまりウェブページの冒頭にページ内リンクを設けてメインコンテンツにジャンプできる機能) はアクセシビリティを担保するうえで必須要件と言えるのでしょうか。今回の記事では、スキップリンクの実効性や必要性といった側面から、ブロックスキップについて考えてみたいと思います。

スクリーンリーダー利用者にとってはスキップリンクは無くても概ね問題ない

「NVDA」や「VoiceOver」をはじめ、今日のスクリーンリーダーの多くは、キーボード操作 (キーコマンド) によって、見出し要素間の移動や WAI-ARIA ランドマーク間の移動ができるようになっています。(日本国内で大きなシェアを持つ「PC-Talker」も、現行バージョンでは見出し要素間の移動に加えてランドマーク間の移動も可能になっています。)

そのため、見出し要素や WAI-ARIA ランドマークが適切にマークアップされていれば、スキップリンクは無くても概ね問題ないと言えるでしょう。

スクリーンリーダーを併用しない利用者にとっては?

スクリーンリーダーを併用せず、一般ブラウザのみを利用するユーザー (目で画面は見えるもののマウスが使えずキーボード操作に依存する人) の場合はどうでしょうか?一般ブラウザの多くには現状、見出し要素や WAI-ARIA ランドマーク間をキーボード操作で行き来できる機能が標準で搭載されていません。単にページを見る (読む) だけなら矢印キーでスクロールすればよいですが、メインコンテンツ内のフォーカス可能な要素 (リンクやボタン、フォーム入力要素など) に [Tab] キーで素早くアクセスしたい、というシチュエーションを考えると、スキップリンクがあると便利かもしれません。

2013年の WebAIM 調査 (ロービジョンおよび肢体不自由の利用者を対象にした、ウェブ利用に関するアンケート調査) によると、ロービジョンの7割、肢体不自由者の6割が、スキップリンクを「便利なもの」と感じています。

ご参考 : Survey of Users with Low Vision ResultsSurvey of Users with Motor Disabilities (いずれも WebAIM)

そして最近、PC 向けの Facebook ウェブサイトが、スキップリンクを搭載して話題になりました (ご参考 : Facebook AX Navbar - Accessibility Wins)。必要なときに [Alt] (Mac の場合 [option]) + [/] キーでいつでも呼び出せる、メインコンテンツ (タイムライン) だけでなく様々なセクション (検索、サイドバーの各機能、投稿作成、など) に飛べる、飛び先が事前に視覚的に明示されてわかりやすい、といった工夫がなされていて、とても完成度が高いものになっています。

PC 向け Facebook サイトに搭載されたスキップリンク
Facebook のスキップリンク

ブロックスキップの設計は難しい

ところで、スキップリンクを実際に設計しようとすると、下記のように多くのことを検討する必要があります。

上記の Facebook の例は、かなりうまくやっていると思いますが、それでもリンクラベルがわかりにくかったり紛らわしかったりします (たとえば「メインセクション」というリンクラベルはウェブ利用に慣れていないユーザーが理解できる用語でしょうか?また「Facebook バナー」「Facebook に移動」というリンクラベルあって、それぞれどこに飛ぶか、予測できるでしょうか?)。Facebook の場合、スキップリンクの選択操作中にジャンプ先が視覚的に囲み表示されるので、ラベルがわかりにくくても何とかなりそうですが、仮にこの機能を (視覚的な手がかりを認識できない) 全盲のスクリーンリーダー利用者が使った場合、多少混乱しそうな気がします。

そもそものページ設計でメインコンテンツ手前のブロックをコンパクトに

このように、スキップリンクの設計では検討すべきことが多いうえに、誰にでも理解可能なリンクラベル表現が可能かなど難しい側面もあります。であれば、コストをかけてスキップリンクを「正しく」設計することに腐心する代わりに、そもそものウェブページ設計において、メインコンテンツ手前のブロック (ナビゲーションメニュー) をコンパクトにすることを検討する、というのも合理的な解決なのかなと考えます。

このような工夫を組み合わせることで、スキップリンクを設けなくても、さほどストレスなくメインコンテンツ内をフォーカスできるようになるのではないでしょうか。たとえば 5~7つくらいのメニュー項目で、メインコンテンツにたどり着くまでの [Tab] キーの押下回数が10程度であれば、(サイト独自のスキップリンクの使いかたを学習して操作することと比較しても) そう悪くない気がします。

メニューの項目数を絞ることはユーザーの認知負荷軽減 (選択のしやすさ) という点でも意義があります。また、メインコンテンツの手前をコンパクトにすることはスモールスクリーン (スマートフォン) でのウェブコンテンツ利用という文脈にもマッチします。対処療法的にスキップリンクに頼らざるを得ないケースもあるかもしれませんが、せっかくならユーザビリティの向上も見据えつつウェブページ設計を最適化することも含めて、考えたいなと思います。

記事を共有

Twitter に投稿 Facebook に投稿 はてなブックマークに投稿 Pocket に追加