そもそもHTMLはリンクのためにある(といっても過言ではない)
HTMLは、ハイパーテキストを表現するためのシンプルな方法である
『Webの創成』(Tim Berners-Lee)p.51
利用者がリンク先を参照するかどうかを選択できるリンクを扱います。主に以下の二つですが、areaに関しては、そのalt属性を対象として読み替えてください。
a要素 | URL、フラグメント識別子(#のリンク)、ファイル、メールアドレスへのハイパーリンクを作成する |
---|---|
area要素 | 画像のホットスポット領域を定義し、ハイパーリンクを作成できる。map要素の中で用いる |
埋め込みのリンク | iframe要素、img要素 |
---|---|
外部リソース参照のリンク | link要素、meta要素 |
ページ移動をするリンクの場合は、リンク先のtitle要素もしくは見出し文字列を用いるのが無難です。
mailto:のリンクはPCのメーラを起動し、新規メール作成が連動することがあります。この挙動は予測されることが望ましいです。
メールアドレスをウェブサイトに記載すると、メールアドレス収集プログラムによって収集され、スパムの標的になることがあります。これを回避するために、alt属性を空にした画像を置くノウハウがありますが、視覚障害のあるスクリーンリーダ利用者にはメールアドレスがわからなくなってしまいますので、あまり良いノウハウではありません。
メールアドレスの収集を忌避しつつ、問い合わせ方法を確保したい場合は、メールフォームの設置を検討した方が良いかもしれません。Googleフォームなどで、無料で作成できます。
tel:は、スマートフォンにおいては電話機能を連動することがあります。
リンクがファイルをPDFやExcelなどのファイルをダウンロードする目的の場合は、どんな種類のファイルでどれくらいのファイルサイズなのかをリンク文字列に含めると良いです。
<a href="apply.pdf">参加申し込み</a>
といったリンクは、リンクを機能させることで、どこか別のページに移動するのでなく、じつは3MBという無視するにはやや大きいサイズのダウンロードが始まることを事前に知らされるべきです。とくに、上限設定のあるスマートフォン回線やそれを用いたテザリング利用者にとっては重要な情報です。
<a href="apply.pdf">参加申し込み(PDF, 3MB)</a>
「ダウンロードの仕方を知らない利用者にダウンロードをさせることができる」というのは、言い換えると、「利用者からダウンロードしないで閲覧する」という選択肢を奪う側面があります。
また、このリンク文字列では、ダウンロードするのかどうか、という挙動は利用者にとって十分に予測可能と言えるか怪しい側面があります。
download属性を用いる場合は、予告として「ダウンロードします」、あるいはリンク文字列中に「参加申し込み(PDF, 3MB)をダウンロード」とするのが、良いかもしれません。
Twitterの@robert_KIMATAさんのdownload属性についての言及も参考にしてください。
a[href$="pdf"]のようにCSSの属性セレクタとcontentを併用して、アイコンを表示するというような小技もあり、これはこれで直観的なのですが、この小技だけに依存してファイルの種類を伝えるのは、「晴眼者にわかるが、スクリーンリーダの利用者にわからない」という点で、「1.3.1 情報と関連性」の観点からNGなので、リンク文字列内にテキストを書くことをお勧めします。
リンクが、新しいウィンドウ(タブ)を開く場合は、事前にわかるようにしましょう。
<a href="">参考資料(新しいウィンドウで開きます)</a>
a[target="_blank"]のようにCSSの属性セレクタとcontentを併用して、新しいウィンドウ(タブ)で開くことを予告する、ということもできますが、「ダウンロードされるファイルについての説明を加える」と同様の注意を払う必要があります。
同じリンク先には、同じリンク文字列を用い、一貫した識別性を保つようにしましょう。
ブラウザではタブキーを使用することで、ページ内のリンクを巡回できます。スクリーンリーダ利用者は、しばしばこの機能を利用して、リンク先を探しますが、そのときのリンク文字列が 「こちら」「ここをクリック」というようなものだと、リンク先を想像しづらくなります。
2.4.4 リンクの目的(コンテキスト内)が参考になります。また、aria-labelやtabindexを効果的に用いることができるかもしれません。
「日々の更新」ではなく、CMSがこういったリンクを自動生成する場合は、CMSのテンプレート作成者に改善を依頼しましょう。
<a href="http://example.com"></a>
<a href="http://example.com"><img src="foo.png" alt=""></a>
画像を視認できる人には問題がないかもしれませんが、スクリーンリーダ利用者にとって利用できないリンクになってしまいます。
<area shape="rect" coords="184,6,253,27" href="http://example.com" alt="" />
こちらも視認できるので、晴眼者のみを想定すると見落とす場合があります。
<a href="http://example.com" class="pdf-icon"></a>
最近のスクリーンリーダだとcontentプロパティで文字を付与しているとき、読む場合もあるようですが、古式ゆかしき構造とプレゼンテーションの分離の観点からはCSSに依存しない方が良いでしょう。
a要素の内容およびarea要素のalt属性は空にしないように注意しましょう。
リンク文字列は正確な意味を伴って発話できるべきです。以下のようなリンク文字列は、おそらくこう記述した人の予想を裏切る読み上げが行われます。
<a href="http://example.com#annotaion">▶</a>
<a href="http://example.com#annotaion"><img src="annotation.png" alt="▶"></a>
<a href="https://www.facebook.com"><span class="fab fa-facebook"></span></a>
しばしばi要素を用いてマークアップされますね(Iconだから?)。こういった場合、aria-labelが有用かもしれません。
この問題に対してはaria-labelが解法の手がかりになるかもしれません。また、場合によってはimg要素も使えるかもしれません。
チラシの縮刷画像をimg要素で配置し、チラシをクリックしたらそのPDFがダウンロードできる……といった実装は、alt属性に「チラシPDF(100KB)をダウンロード」と書くのでは不十分です。スクリーンリーダ利用者にとっては、リンクが何をもたらすか予測できますが、逆に晴眼者には(場合によると、そこがリンクであることすら)わかりません。
グローバルナビゲーション部分や、フッタなど位置的にリンクが並んでいることがわかる場所でなければ、デフォルトで付いている下線を除去したり、リンク文字列の色を地の文と同じにすべきではありません。リンクの識別性が著しく損なわれることがあります。
また、既訪リンクについても、その機能を奪わないようにするのがベターです。
img要素をリンクにする場合、それがバナーやアイコンでないとき、リンクだと気づいてもらえないことがあります(画像の拡大やファイルダウンロードでしばしば見かけます)。
デフォルトの見栄えを大きく改変しないことをお勧めします。
この項目は、ほとんどの場合外部のCSSファイルで設定されていることなので、あまり「日々の更新」で対応を考えることではありません。業者に改善を依頼しましょう。
小さいリンクや密接したリンクはマウスおよび代替マウスもしくはスマートフォンなどで操作しづらくなります。
最近ではページネーションなどでよく見られます。
<a href="?p=1">1</a><a href="?p=2">2</a><a href="?p=3">3</a>...
リンク間には、十分な隙間を用意し、リンク領域もある程度の大きさを確保しましょう。
クリックする位置が同一でもリンク先やラベルが変化するリンクは、操作や理解に時間のかかる人にとって、たいへん使いづらいものになります。また、リンクの利便性の問題を超えて、「2.2.2 一時停止、停止、非表示」(非干渉)にも抵触する場合があります。常に動くことで利用者の注意を奪い、他の一切を利用できなくなる危険性があります。
「見積もり無料」と「XX工房」という文字列を交互に表示するアニメーションバナーは、仮にalt属性が「見積もり無料 XX工房」となっていても、リンク先の理解に時間がかかる場合があるのでNGです。
ループのアニメーションバナーを使わないようにしましょう
カルーセルがクリック可能な際、クリックを意思決定したときと、クリックしたときとで、リンク先が変化してしまう恐れがあります。これは個々の投稿がリンクとして有効になっているSNSの埋め込みコンテンツにおいても、同様の問題があり得ます。
マウスオーバ時には切り替わらないようにする、といった措置が一定有効ですが、そもそも自動で切り替えないようにするのがよいかもしれません。
この項目は、ほとんどの場合JavaScriptで制御されていることなので、あまり「日々の更新」で対応を考えることではありません。業者に改善を依頼しましょう。
特に障害者にとってというわけでなく、ユニバーサルに不便であるため、WCAGではアクセシビリティの要件としては求められていないのですが、リンク切れおよびリンク先の内容の確認は重要です。
リンク先を確認しましょう。
「リンク切れ」の類縁にあたる問題です。リンクのラベルとリンク先が一致していないと問題です。
<a href="https://www.yahoo.co.jp">Google</a>で検索してください。
例は、半ば冗談ですが、リンク先がファイルの場合など、キャッシュが原因で、意図しないリンク先になることもあります。注意しましょう。
やはりリンク先を確認しましょう。
HTML5より前では、a要素を除いた、いわゆるインライン要素が許容されていましたが、HTML5では、a要素に含められるものが増えました。p要素やblockquote要素、h1〜6要素などもまとめてリンクに含めることができます。
<a>: アンカー要素 - HTML: HyperText Markup Language | MDN
<a href="http://example.com">
<h2>foo</h2>
<p>The quick brown fox jumps over the lazy dog</p>
</a>
a要素の中に複数の要素がある場合、更新担当者の予想を裏切る挙動があり得ます(参考資料「テスト: リンク文字列」)。
少し古い資料ですが、こういった資料でも、不思議な振る舞いを確認できます。
a要素の中をなるべくシンプルに保つようにしましょう。
ブラウザあるいはCMSが、文字列を勝手にリンクにすることがあります。この機能に実害があるというよりも、この機能に依存することについては注意した方がいいかもしれません。
accesskey | リンクなどにキーボードショートカットを割り当てます。idの重複に気をつけてください |
---|---|
tabindex | タブキーの巡回順序を指定します。みだりに設定しな方が良いですが、繰り返されるリンクにtabindex=-1を指定することでスクリーンリーダ利用者の利便性を高めるノウハウがあります(全文読みでは読み上げます)。 |
title | ツールチップ(小さい吹き出し)として用いられることがありますが、スクリーンリーダの読み上げの対象となる場合があります。また、スマートフォン環境では、期待通りにならないこともあるので、最近では不用意に用いない方がいいかもしれません。 |
target | リンク先の開き方を指定します。新しいウィンドウ(タブ)で開く際の注意事項に留意してください。 |
aria-hidden | スクリーンリーダから存在を隠蔽します。注意深く扱ってください。 |
aria-label | スクリーンリーダ用のテキストとして機能します。アイコンフォントなどと併用すると効果的かもしれません。 |
aria-labelledby | スクリーンリーダ用のテキストとして機能します。日々の更新ではあまり使うことはないかもしれません。 |
「日々の更新」バナシはここまでです。
「日々の更新」を超える要件については、JavaScriptの発火、CMSによって自動生成されるリンク文字列などがあります。
というようなものがありました。
くれぐれもWCAG 1.0を推奨するものではありません。仕様は常に最新の仕様を参照すべきです。
NPO法人 木野環境さん。プロジェクタを貸してくれてありがとうございます。