第3回 京都でウェブアクセシビリティたいらげ会日々の更新からアクセシブルに:よいリンク
WWW(World Wide Web)とリンク
ハイパーリンク:WWWをWWWたらしめる概念
そもそもHTMLはリンクのためにある(といっても過言ではない)
HTMLは、ハイパーテキストを表現するためのシンプルな方法である
『Webの創成』(Tim Berners-Lee)p.51
- 世界共通の1つの情報空間(WWW)を作る基本的な技術
- 連想をたすけ、情報のより深い理解をたすける
今日の目標
- 素敵な技術なので、上手に使いましょう!
- アクセシビリティを軸としますが、アクセシビリティ以外の観点からのあれやこれやも考えたいです。
- また、今回は、基本的には「日々の更新」の場面を想定しますが、「日々の更新」の範囲で対応が難しいものについては、業者に改善を依頼してみましょう。
ここで扱うリンク
利用者がリンク先を参照するかどうかを選択できるリンクを扱います。主に以下の二つですが、areaに関しては、そのalt属性を対象として読み替えてください。
a要素 |
URL、フラグメント識別子(#のリンク)、ファイル、メールアドレスへのハイパーリンクを作成する |
area要素 |
画像のホットスポット領域を定義し、ハイパーリンクを作成できる。map要素の中で用いる |
扱わない「リンク」
埋め込みのリンク |
iframe要素、img要素 |
外部リソース参照のリンク |
link要素、meta要素 |
よいリンク
リンクであることが誰にでも知覚できること
- グローバルナビゲーションなど位置的にわかりやすいこと
- 地の文と色が異なり、下線があること。既訪の機能も維持すること
- バナー、アイコンはalt属性を適切にすること
- アイコン類は文脈上わかりやすくすること
- アイコンの視覚的側面のみに依存しないこと
リンクが何をもたらすのか予測できること
- リンク先そのものを用いる(ページのタイトル、見出し、メールアドレスなど)
- なにをもたらすか予測しやすいリンク(ファイルのダウンロード、新しいウィンドウを開く、画像の拡大など)
リンク先のtitle要素または見出しをリンク文字列にする
ページ移動をするリンクの場合は、リンク先のtitle要素もしくは見出し文字列を用いるのが無難です。
- title要素は、ブラウザのタイトルバーに表示されているものです。ブックマーク登録(Ctrl+Dなど)の過程で取得しやすい。
- リンク先の大見出し(h1要素)。
- ページ内リンクの場合でも、やはり見出し(h2要素など)。
- URLベタ書きをリンクにするよりも、適切なリンクテキストを用いるのが望ましいでしょう。
余禄
- リンクは、一定の検索エンジン対策効果があると言われています。titleを用いることで、リンク先に対して、プラスの効果が期待できるかもしれません。
メールアドレスそのものをリンク文字列にする(mailto:の場合)
mailto:のリンクはPCのメーラを起動し、新規メール作成が連動することがあります。この挙動は予測されることが望ましいです。
- 「お問い合わせはこちら」といった文字列からmailto:でリンクするよりも、メールアドレスそのものを書く方がmailto:の挙動としては予測しやすいです。
- 次善の策としては、「メールを送る」や「メールのアイコン」は、わりと予測しやすいかもしれません。
- 「お問い合わせ」といった文言からのリンクは、サイト内のメールフォームに行くのか、問い合わせ先情報を掲載したページに行くのか、メーラが起動するのか、予測しづらいと考えられます。
注意
メールアドレスをウェブサイトに記載すると、メールアドレス収集プログラムによって収集され、スパムの標的になることがあります。これを回避するために、alt属性を空にした画像を置くノウハウがありますが、視覚障害のあるスクリーンリーダ利用者にはメールアドレスがわからなくなってしまいますので、あまり良いノウハウではありません。
メールアドレスの収集を忌避しつつ、問い合わせ方法を確保したい場合は、メールフォームの設置を検討した方が良いかもしれません。Googleフォームなどで、無料で作成できます。
電話番号そのものをリンク文字列にする(tel:の場合)
tel:は、スマートフォンにおいては電話機能を連動することがあります。
- mailto:と同様に、「お問い合わせはこちら」からのリンクは、この挙動を予測しづらいものです。電話番号そのものをリンクテキストにする方が直観的でしょう。
ダウンロードされるファイルについての説明を加える
リンクがファイルをPDFやExcelなどのファイルをダウンロードする目的の場合は、どんな種類のファイルでどれくらいのファイルサイズなのかをリンク文字列に含めると良いです。
<a href="apply.pdf">参加申し込み</a>
といったリンクは、リンクを機能させることで、どこか別のページに移動するのでなく、じつは3MBという無視するにはやや大きいサイズのダウンロードが始まることを事前に知らされるべきです。とくに、上限設定のあるスマートフォン回線やそれを用いたテザリング利用者にとっては重要な情報です。
<a href="apply.pdf">参加申し込み(PDF, 3MB)</a>
- HTML5であれば、download属性を併せて用いることで、「モディファイアキーとクリック」など、ファイルのダウンロードの仕方を知らない利用者にもダウンロードさせることができます。
注意
a[href$="pdf"]のようにCSSの属性セレクタとcontentを併用して、アイコンを表示するというような小技もあり、これはこれで直観的なのですが、この小技だけに依存してファイルの種類を伝えるのは、「晴眼者にわかるが、スクリーンリーダの利用者にわからない」という点で、「1.3.1 情報と関連性」の観点からNGなので、リンク文字列内にテキストを書くことをお勧めします。
新しいウィンドウ(タブ)を開くことを伝える
リンクが、新しいウィンドウ(タブ)を開く場合は、事前にわかるようにしましょう。
新しいウィンドウ(タブ)を開くことについては、以下のような問題が伴います。
- PC操作に詳しくない人にとっては、新しいウィンドウ(タブ)から、元のページにブラウザの「戻る」で戻れない
- 視覚障害者も、新しいウィンドウ(タブ)に気付きづらい(音による注意喚起はあります)
- 一見してそれとわかる一般的なリンクの見分け方が存在しない
- 「新しいウィンドウ(タブ)で開く」という操作は、モディファイアキーとの併用やコンテキストメニューによって、比較的手軽に実行できるのに対し、「同じウィンドウ(タブ)で開く」という操作(設定)は、難度が高い
まず、新しいウィンドウ(タブ)で開く操作に一貫性を持たせましょう。
- サイト外へのリンク集のページは、ページ冒頭に「リンクは新しいウィンドウを開きます」と予告している
- サイトが用語集を備えており、ページの現在位置を確保したまま、用語集を参照する際に、新しいウィンドウを開くが、その旨を説明している
- リンク文字列中に挙動を含める
<a href="">参考資料(新しいウィンドウで開きます)</a>
注意
a[target="_blank"]のようにCSSの属性セレクタとcontentを併用して、新しいウィンドウ(タブ)で開くことを予告する、ということもできますが、「ダウンロードされるファイルについての説明を加える」と同様の注意を払う必要があります。
同じリンク先には、同じリンク文字列を用いる
同じリンク先には、同じリンク文字列を用い、一貫した識別性を保つようにしましょう。
- リンク先example.com/aboutusに対して、「組織概要」と、「私たちについて」との別の文字列からリンクすると、利用者を戸惑わせます。
- また逆に、あるリンク文字列は「お問い合わせ」でフォームにリンクし、同じ「お問い合わせ」という文字列で、住所や電話番号を掲載したフォームでないページにリンクする、というような実装も利用者を混乱させます。
- これはサイト外へのリンクについても、同じことが言えます。わからない人にとっては、https://waic.jpへのリンクが、「WAIC」と「ウェブアクセシビリティ基盤委員会」という別の文字列からリンクされているとわかりづらいと感じられるかもしれません。
べからず:こちら、ここ、続きを読む、learn moreといったリンク
ブラウザではタブキーを使用することで、ページ内のリンクを巡回できます。スクリーンリーダ利用者は、しばしばこの機能を利用して、リンク先を探しますが、そのときのリンク文字列が 「こちら」「ここをクリック」というようなものだと、リンク先を想像しづらくなります。
- ひとつの見出しの中の一連の文脈の中で「こちら」というようなリンクが使われている場合などは、問題は少ない場合がありますが、一連の文脈の中であっても、複数の「こちら」があると混乱しますし、日々の更新の作業としては、そもそも忌避した方が安全です。
- 対策
- 2.4.4 リンクの目的(コンテキスト内)が参考になります。また、aria-labelやtabindexを効果的に用いることができるかもしれません。
「日々の更新」ではなく、CMSがこういったリンクを自動生成する場合は、CMSのテンプレート作成者に改善を依頼しましょう。
べからず:空のa要素(空のalt属性を含む)
リンク文字列は空であってはいけません。だれにとっても利用できないリンクになり得ます。
<a href="http://example.com"></a>
a要素の中にimg要素がある場合、そのalt属性を空にしてはいけません
<a href="http://example.com"><img src="foo.png" alt=""></a>
画像を視認できる人には問題がないかもしれませんが、スクリーンリーダ利用者にとって利用できないリンクになってしまいます。
area要素のalt属性が空
<area shape="rect" coords="184,6,253,27" href="http://example.com" alt="" />
こちらも視認できるので、晴眼者のみを想定すると見落とす場合があります。
CSSのcontentプロパティも要注意です
<a href="http://example.com" class="pdf-icon"></a>
最近のスクリーンリーダだとcontentプロパティで文字を付与しているとき、読む場合もあるようですが、古式ゆかしき構造とプレゼンテーションの分離の観点からはCSSに依存しない方が良いでしょう。
- 対策
- a要素の内容およびarea要素のalt属性は空にしないように注意しましょう。
べからず:発話できないa要素(発話できないaltを含む)
リンク文字列は正確な意味を伴って発話できるべきです。以下のようなリンク文字列は、おそらくこう記述した人の予想を裏切る読み上げが行われます。
<a href="http://example.com#annotaion">▶</a>
alt属性値も同様です。
<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要素も使えるかもしれません。
べからず:altのみで情報を伝えるリンク
チラシの縮刷画像を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で制御されていることなので、あまり「日々の更新」で対応を考えることではありません。業者に改善を依頼しましょう。
べからず:リンク切れしているリンク、リンク先が変更されているリンク
特に障害者にとってというわけでなく、「ユニバーサルに不便(木俣 2016)」であるため、WCAGではアクセシビリティの要件としては求められていないのですが、リンク切れおよびリンク先の内容の確認は重要です。
- リンク先のドメイン保持者の変化により、リンク先の内容が広告など全く異なったものになっていることがあります。最悪、詐欺サイトになっていることもあり、特にサイト外へのリンクに関しては、定期的な確認が必要かもしれません。
- この問題に派生するのが「短縮URL」です。この数年でも短縮URLサービスが停止されたりすることはしばしば起こっています。短縮URLをウェブページでのリンクとして用いるのは避けた方が安全かもしれません。
- 対策
- リンク先を確認しましょう。
べからず:間違ったリンク
「リンク切れ」の類縁にあたる問題です。リンクのラベルとリンク先が一致していないと問題です。
<a href="https://www.yahoo.co.jp">Google</a>で検索してください。
例は、半ば冗談ですが、リンク先がファイルの場合など、キャッシュが原因で、意図しないリンク先になることもあります。注意しましょう。
- 対策
- やはりリンク先を確認しましょう。
要注意:HTML5のa要素
HTML5より前では、a要素を除いた、いわゆるインライン要素が許容されていましたが、HTML5では、a要素に含められるものが増えました。p要素やblockquote要素、h1〜6要素などもまとめてリンクに含めることができます。
<a>: アンカー要素 - HTML: HyperText Markup Language | MDN
- a要素に複数の要素が含まれている場合、スクリーンリーダで、a要素のリンク先は同一であるにも関わらず、あたかも複数のリンクとして読み上げることがあります。
<a href="http://example.com">
<h2>foo</h2>
<p>The quick brown fox jumps over the lazy dog</p>
</a>
要注意:a要素の中のalt属性やテキストの読み上げ
a要素の中に複数の要素がある場合、更新担当者の予想を裏切る挙動があり得ます(参考資料「テスト: リンク文字列」)。
少し古い資料ですが、こういった資料でも、不思議な振る舞いを確認できます。
- 対策
- a要素の中をなるべくシンプルに保つようにしましょう。
要注意:勝手にリンクになる文字列(telなど)
ブラウザあるいはCMSが、文字列を勝手にリンクにすることがあります。この機能に実害があるというよりも、この機能に依存することについては注意した方がいいかもしれません。
- 電話番号と思しき文字列に、ブラウザによって自動的にtel:のリンクを付与される
- http(s)://から始まる文字列があったら、CMSが自動的に当該文字列をリンクにする
- メールアドレスがあったら、CMSが自動的に当該文字列をリンクにする
要注意:リンクに関する属性
accesskey |
リンクなどにキーボードショートカットを割り当てます。idの重複に気をつけてください |
tabindex |
タブキーの巡回順序を指定します。みだりに設定しな方が良いですが、繰り返されるリンクにtabindex=-1を指定することでスクリーンリーダ利用者の利便性を高めるノウハウがあります(全文読みでは読み上げます)。 |
title |
ツールチップ(小さい吹き出し)として用いられることがありますが、スクリーンリーダの読み上げの対象となる場合があります。また、スマートフォン環境では、期待通りにならないこともあるので、最近では不用意に用いない方がいいかもしれません。 |
target |
リンク先の開き方を指定します。新しいウィンドウ(タブ)で開く際の注意事項に留意してください。 |
aria-hidden |
スクリーンリーダから存在を隠蔽します。注意深く扱ってください。 |
aria-label |
スクリーンリーダ用のテキストとして機能します。アイコンフォントなどと併用すると効果的かもしれません。 |
aria-labelledby |
スクリーンリーダ用のテキストとして機能します。日々の更新ではあまり使うことはないかもしれません。 |
「日々の更新」バナシはここまで
「日々の更新」バナシはここまでです。
「日々の更新」を超える要件については、JavaScriptの発火、CMSによって自動生成されるリンク文字列などがあります。
WCAG2.1では?
- 1.3.6 Identify Purpose (レベル AAA)
- In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.
- 用途の特定
- マークアップ言語で実装されたコンテンツでは、ユーザインタフェース コンポーネント、アイコン、領域の用途はプログラムによる解釈が可能である。
- 2.5.5 Target Size
- The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:
- Equivalent
- The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
- Inline
- The target is in a sentence or block of text;
- User Agent Control
- The size of the target is determined by the user agent and is not modified by the author;
- Essential
- A particular presentation of the target is essential to the information being conveyed.
- ターゲットのサイズ
- ポインタ入力のターゲットのサイズが 44 × 44 CSS ピクセル以上である。ただし、以下の場合は例外とする。
- 同等のものが存在する
- そのターゲットと同等のリンク又はコントロールが同じページに 44 × 44 CSS ピクセル以上のサイズで存在する。
- インラインである
- そのターゲットが文章又はテキストブロック内に存在する。
- ユーザエージェントのコントロールである
- ターゲットのサイズがユーザエージェントによって定められており、かつコンテンツ制作者が変更していない。
- 必要不可欠
- そのターゲットを特定の方法で提示することが、情報伝達にとって必要不可欠である。
参考までにWCAG1.0では、どうだっけ?
- 9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. [Priority 3]
- 重要なリンク(クライアント側のイメージマップ内のものを含む)、フォームコントロール、およびフォームコントロールのグループへのキーボードショートカットを提供する。
- 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]
- ユーザーエージェントがユーザーが生成されたウィンドウをオフにできるようになるまでは、ポップアップや他のウィンドウを表示させず、ユーザーに通知せずに現在のウィンドウを変更しないでください。
- 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3]
- https://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-divide-links
- ユーザーエージェント(支援技術を含む)が隣接したリンクを明確にレンダリングするまでは、隣接したリンク間にリンクではなく出力可能な文字(スペースで囲まれた文字)を含める。
- 13.1 Clearly identify the target of each link. [Priority 2]
- 各リンクのターゲットを明確に特定する。
というようなものがありました。
終わりに
NPO法人 木野環境さん。プロジェクタを貸してくれてありがとうございます。