WebデザイナーのためのWebアクセシビリティ導入ガイド

※このページでは広告のリンクを含みます

Webデザイナー必見！アクセシビリティを取り入れたサイト制作のコツやポイントを詳しく解説。全てのユーザーに使いやすいウェブサイトを作るための実践的ガイドをお届けします。
初心者から経験者まで、質の高いデザインを目指す方への必読記事です。

Webアクセシビリティのアクセシブル（accessible）は、「access」+「able」で「アクセス可能」という意味です。
つまりWebコンテンツをすべての人がアクセス、情報を得たり、サービスを利用できるようにする考え方です。

視覚や聴覚障害者、高齢者、新技術になじみのない人まで、多様な人々がウェブを利用する現代では、WebアクセシビリティはWebデザインの基本であり、良好なユーザー体験を提供するための必須要件となっています。

Webアクセシビリティは、Webデザインの基本であるとはいえ、Webデザインの学習で学ぶ機会は少ないです。
なぜならばデザインの基礎知識がメインのため、Webアクセシビリティのためのデザインのお作法まで学ぶ網羅することが難しいと感じています。

ここでは、Webアクセシビリティのガイドラインと実際おこなう作業を解説していきます。

Webアクセシビリティをどのように実現すれば良いのかは、WCAG（Web Content Accessibility Guidelines）という国際的なガイドラインで詳しく説明されています。

このガイドラインは「達成基準」という具体的な指標を提供しており、Webアクセシビリティをどの程度達成しているかを評価するのに役立ちます。

Webアクセシビリティには、3つの適合レベル（レベルA、レベルAA、およびレベルAAA）があります。適合部分によってWebコンテンツがどの程度アクセシブルであるかを測定するための標準です。下記に3つのレベルの達成基準項目を解説していきます。

ひとつずつ解説していきます。

適合レベルAは最も基本的なWebアクセシビリティ特性を示します。

文字情報の代替テキストの提供や、自動再生される音声の停止機能の提供など、全25項目が含まれます。これらはWebサイトを使うすべての人にとって基本的なアクセシビリティを確保するための要素です。

これは画像、チャート、アイコンなどの非テキストコンテンツがウェブサイト上で適切に理解され、使われることを確保するための項目です。

これらの要素は視覚障害を持つ人や画像を読み込むことができない人にも理解できるようにするため、適切な代替テキスト（alt属性）を提供することが求められます。

文字を含む画像に代替テキストは適切に入れる。

<img src="webdesignerstart.png" alt="Webデザイナー入門ガイド" width="100" height="100">

画像に文字の意味が入っていない装飾画像と代替テキストと、画像付近に画像のテキストがある場合 (グラフと表、図版と説明文章など) 、画像の代替テキストは空とします。

<img src="webdesignerstart.png" alt="" width="100" height="100">

HTMLのコードを確認し、画像タグ（img）に適切なalt属性が含まれていることを確認します。
Chrome拡張機能「Alt & Meta viewer］を使うと一括確認できて便利です。

［Alt & Meta viewer］ボタンをクリックして（下図1）、［画像のAlt表示］を選択する（下図2）と全画像のAlt情報が表示されます。

この項目は音声だけのコンテンツ（例：ポッドキャスト）や映像だけのコンテンツ（例：アニメーション）が、聴覚障害を持つ人や視覚障害を持つ人にも理解できるようにするためのものです。

音声だけのコンテンツは、テキストのトランスクリプトを提供すること、映像だけのコンテンツは、音声ガイドまたはテキストの説明を提供することが求められます。

音声・映像コンテンツに代替コンテンツを入れ込んでいく。音声、映像によって下記の対応方法があります。

• 音声のみ：テキストに書き起こされているか
• 映像のみ：テキストや音声によって代替されているか
• テキストの代替として映像のみ：簡潔な説明テキストによってラベルをつける

音声コンテンツや映像コンテンツの近くに、適切なテキストのトランスクリプトや説明が提供されていることを確認します。

これは動画コンテンツにキャプション（字幕）を提供することを求める項目です。

キャプションは聴覚障害を持つ人が動画コンテンツを理解するために非常に重要です。また、ノイズの多い環境で音声を聞くことが難しい場合や、非ネイティブスピーカーがコンテンツを理解するためにも有用です。

誰が話しているのか、どんな効果音が鳴ったのか、など映像を理解するために必要な情報を、画面の状況にあわせて（同期して）提示する。

動画コンテンツを再生し、適切なキャプションが提供されていることを確認します。

この項目は、視覚障害を持つ人が視覚的な情報を理解できるようにするためのものです。

視覚的な情報（例：映像やアニメーション）に対して音声解説を提供したり、テキストの代替コンテンツを提供することが求められます。

講演の収録映像などでは「聴衆のざわめき」「（笑い）」など含めた書き起こしてテキスト化させます。

映像コンテンツを再生し、視覚的な情報に対して音声解説が提供されているか、または適切なテキストの代替コンテンツが提供されていることを確認します。

この項目はウェブページの情報とその関係性がプログラム的に解釈可能でなければならないことを求めています。たとえば、表やリストは適切なマークアップを使用して構築されるべきです。

見出し・強調・リスト・段落などに適切なHTMLの要素を使います。

HTMLのコードを確認し、情報の関係性を示す適切なマークアップ（例：テーブルタグやリストタグ）が使用されていることを確認します。
Chrome拡張機能「Web Developer」のアウトライン機能を使って見出し・強調・リスト・段落を確認する時に便利です。

「Web Developer」のアウトライン機能は、Chrome拡張機能［Web Developer］ボタン（下図1）をクリックして［Outline］タブ（下図2）を選択します。Outline内の［Outline Block Level Elements］（下図3）をクリックするとブロックごとにラインで確認できます。

この項目はウェブページの内容が正しい順序で提示されることを求めています。

視覚的な順序とコードの順序が一致している必要があります。これにより、スクリーンリーダーのような支援技術を使用する人々が内容を正しく理解できます。

HTMLソースのマークアップ順に読んだ時に情報が正しく伝わる記述にする
具体的には下記のような記述式はNGとします。

<h1>デ ザ イ ン</h1>

<h1>デ<br>ザ<br>イ<br>ン</h1>

ページの読み込み順と視覚的な表示順が一致していることを確認します。
Chrome拡張機能「Web Developer」でCSSを無効にすると便利です。

「Web Developer」のCSSを無効の仕方は、Chrome拡張機能［Web Developer］ボタン（下図1）をクリックして［CSS］タブ（下図2）を選択します。CSS内の［Disable All Styles］（下図3）をクリックするとブロックごとにラインで確認できます。

この項目は色、形、位置などの感覚的な特性だけに頼らずに情報を伝達することを求めています。

形や位置のみに依存した表現だけで使用することは避ける。
たとえば、「赤色のリンクをクリック」と指示するのではなく、「"お問合せ"と表示されているリンクをクリック」と表記します。

Webサイト上の指示や情報が感覚的な特徴だけに依存していないことを確認します。

この項目は色を情報の伝達手段としてだけ使用してはならないことを求めています。たとえば、「赤字の項目が必須項目です」といった指示は、色覚異常の人にとっては理解しづらいかもしれません。

Webサイトが色だけを情報伝達の手段として使用していないことを確認します。

例えば、必須項目は色だけでなく、「*」などの記号も用いて表示されていることなどを確認します。

テキスト、図版を目視で確認します。

Webページが自動再生音声を含む場合、ユーザーがその音声を停止、またはミュートにできるようにすることを求めています。

音声コンテンツが自動的に再生される場合、その音声を一時停止、または停止できるか。

Webページで自動再生音声がある場合、それを停止またはミュートするコントロールがあるか確認します。

音声が出ていることを確認します。

すべての機能がキーボードだけを使用してアクセス可能であることを求めています。

これは、マウスを使用できないユーザーがWebサイトを利用できるようにするためのものです。

Webページのすべての機能がキーボードで操作可能な状態にする。

Tabキーによりページ内の各要素をフォーカス、またマウスオーバーしてJavaScriptによる挙動を確認します。キーボードだけを使ってウェブサイトの全ての機能にアクセスできるかを確認します。

キーボードを使用してWebページを操作するときに、「キーボードトラップ」がないことを求めています。つまり、キーボードのみを使用するユーザーが特定の部分に閉じ込められ、他の部分に移動できなくなるような状況を避ける必要があります。

キーボードフォーカスが特定の要素に固定されていない状態にします。ただし、下記のようなものは例外です。

• リアルタイムで進行するイベント、例えばオークションにおいては、制限時間が絶対的要件となっており、それに代わる選択肢は存在しません。
• あるコンテンツにおいては、制限時間がその機能の不可欠な部分であり、延長することが該当コンテンツの正常な動作を損なう可能性があります。
• 制限時間が20時間以上と設定されている場合

Tabキーを押下してページ全体を一巡し、フォーカスを外すことのできない場所が無いことを確認します。

タイムリミットが設定されているコンテンツの場合、ユーザーがそのタイムリミットを調整できることを求めています。

入力操作や内容の把握にコンテンツに制限時間を設けないようにします。

Tabキーを押下してページ全体を一巡し、フォーカスを外すことのできない場所が無いことを確認します。

自動更新や自動スクロール、自動再生など、時間によって制御されるコンテンツがある場合、それらをユーザーが一時停止、停止、または非表示にできるようにする必要があります。

動画やスライドショーなど、自動的に再生されるコンテンツは、ユーザーが一時停止、停止、または非表示にできるようになっているか。

自動更新や自動スクロールなどの要素が一時停止、停止、または非表示にできることを確認します。

Webページが閃光性発作を引き起こす可能性のある閃光を含まないことを求めています。

閃光を伴う表現は目に痛く感じられますが、人によっては気分が悪くなったり、時には光過敏性発作を起こして倒れてしまうこともありますので、注意しましょう。

1秒間においても3回を超える閃光が発生しない状態にします。

ページ上のすべての閃光要素が特定の閾値以下（3回を超える閃光が発生しない状態）であることを確認します。

再帰的なブロックをスキップするメカニズムを提供することを要求しています。これにより、キーボードユーザーが容易にコンテンツにアクセスできます。

メニューや重要でないコンテンツなどをスキップして本文コンテンツに直接移動できようにします。

Webページに再帰的なブロック（例：ナビゲーションメニュー）が存在する場合、それをスキップするためのリンクやボタンが提供されているかを確認します。

各Webページがその内容を正確に反映したタイトルを持つことを求めています。これにより、ユーザーはページの内容を理解しやすくなります。

Webページで意味のあるタイトルにする

各Webページのタイトルがそのページの内容を適切に表現していることを確認します。
Chrome拡張機能「Alt & Meta viewer」を使うと一括確認できて便利です。

［Alt & Meta viewer］ボタンをクリックして（下図1）、［Title Meta 表示］を選択する（下図2）と全画像のAlt情報が表示されます。

キーボードでナビゲートするときのフォーカス順序が、コンテンツを理解するのに意味がある順序であることを要求します。

フォーカスが論理的かつ直感的な順序で設定する。

キーボードでWebページをナビゲートし、フォーカスの順序が理解しやすい順序になっていることを確認します。

リンクテキストまたはリンクテキストとその周囲のコンテキストからリンクの目的が明確にわかることを要求します。

リンクの目的や対象が、あるいはその前後の文脈だけ予測できるようにする。
また、リンク画像の場合はその代替テキスト、あるいはその前後の文章からリンク先が予想できるようにしています。

リンクテキストとその周囲のコンテキストから、そのリンクが何につながるのか明確に理解できることを確認します。

Webページが書かれている主要な言語が明示されることを要求しています。これにより、スクリーンリーダーが正確な発音で読み上げることが可能になります。

Webサイトの言語情報を正しく宣言します。

<html lang="ja">

HTMLコードの<html lang="...">タグでページの主要な言語が明示されていることを確認します。

コンポーネントがフォーカスを受け取るとき、コンテキストの変化を引き起こさないようにする。

フォーカスを受け取ったときにイベントを起動することのできるすべてのコンポーネントは、コンテキストを変化させないようにします。

各コンポーネントにフォーカスを当てて、入力なしで予期せぬ動作が起こらないことを確認します。

ユーザーが入力を行った際に、その入力が予期せぬ変化を引き起こさないことを要求します。

フォームに入力操作により、別のページに遷移してしまう、新しいウィンドウが開く、または、ページ全体がリロードされるなどの状況の変化が起こらないようにします。

各入力フィールドにデータを入力し、予期せぬ結果が起こらないことを確認します。

入力エラーが自動的に検出され、そのエラーがユーザーに明確に示されることを要求します。

適切ではない値が入力されたときに、エラーメッセージが表示、かつユーザーにテキストで説明している。

入力フィールドに無効な情報を入力してエラーを引き起こし、そのエラーがユーザーに明確に示されることを確認します。

フォームやコンポーネントなど、各要素がユーザーにとって理解しやすい形でラベル付けや説明がされていることを要求します。ラベルがなければ、入力欄が何を意味しているのかわかりませんので、何を入力すればよいか分からなくなります。

フォームやコントロールに対して適切なラベルや説明をする。

フォームフィールドや操作可能なコンポーネントが、それぞれの目的や機能が明確に理解できる形でラベル付けや説明がされていることを確認します。
（例「必須」「任意」などの補足情報は入力欄より前にある）

HTMLマークアップが正しく形成されていることを要求します。具体的には、開始タグと終了タグのペア、要素の入れ子構造、一意のIDなどが正しく設定されていることを確認します。

文法にエラーが無いようにします。

HTMLバリデータツールを使用して、ページのHTMLが正しく記述されていることを確認します。
「Validator」にて構文チェックできます。

［Address］欄（下図1）にURLを入れて［Check］ボタン（下図2）をクリックすると結果が出てきます。

すべてのユーザインターフェイスコンポーネント（特にアクセシビリティAPIを使用できるコンポーネント）が、適切な名前、役割、値を持つことを要求します。

インタラクティブな要素やコントロールには、適切な名前、役割、および値を提供している。

例えばお問い合わせフォームにあるラジオボタン（下図1）には、HTMLタグ（下図2）に名前（name）と値（value）を記載しています。

ブラウザの開発者ツールやアクセシビリティテスティングツールを使用して、各UIコンポーネントが適切な名前、役割、値を持っていることを確認します。

適合レベルAAは、より多くのユーザーに対応するための追加要素が含まれます。
カラーパレットの選定や、音声ガイドの提供など全13項目があります。このレベルを達成することで、より多くの特定のニーズを持つユーザーに対応することが可能になります。

ライブ配信の映像コンテンツに対してリアルタイムで字幕（キャプション）を提供することを求める項目です。

これにより、聴覚障害者や音量を調整できない環境（例えば、静かな図書館やオフィス）の人々もライブコンテンツを理解できます。

ライブ映像へのキャプションを付与する。

ライブ映像コンテンツを再生し、リアルタイムでの字幕が提供されていることを確認します。

これは視覚障害者が視覚的な情報を理解できるよう、映像コンテンツに対して音声解説を提供する項目です。映像内の重要な視覚的要素が音声で説明されます。

収録済みのすべての映像コンテンツに対して、音声解説の付与している。

映像コンテンツを再生し、音声解説が提供されていることを確認します。

テキストと背景の間に十分な色のコントラストがあることを要求します。視覚障害者や色覚異常者がテキストを読むのを助けるためのものです。

テキスト及び文字画像テキストと背景の間に一定のコントラストがある。

具体的には下記の通り

• テキストとその背景には、コントラスト比は4.5:1以上にする。
• サイズの大きなテキストとその背景には、コントラスト比は3:1以上にする。
  ちなみに「サイズの大きなテキスト」は18.5px以上の太字（14pt相当）、24px以上（18pt相当）です。

サイズの大きなテキスト及びサイズの大きな文字画像に、少なくとも3:1のコントラスト比がある。

「Colour Contrast Analyser」を用いて前景色と背景色を入力または取得し、コントラスト比を計測する。「Colour Contrast Analyser」を起動させると、前景色、背景色の［スポイトツール］（下図1）で選択します。2つ選択後、コントラスト比（下図2）が表示されます。

ユーザーがテキストを200%まで拡大でき、それでも内容や機能性が失われないことを求めています。

デザインによって拡大すると読めなくなったり、うまく拡大できなくなってしまうことがありますので、注意が必要です。

テキストを200％までサイズ変更できるようにする。

ブラウザのズーム機能（Ctrl++）を使用してテキストを200%まで拡大し、内容や機能が損なわれないことを確認します。

画像を使用してテキストを表現する場合、それには適切な代替テキストが必要であることを指します。ただし、ロゴなどブランドを表現するための画像は例外です。

可能な限り文字画像ではなくテキストにしている。

画像テキストがWebページに使用されている場合、それらに適切な代替テキストが提供されていることを確認します。

ユーザーがWebページのさまざまな部分にアクセスするための複数の手段が提供されることを要求します。
具体的には、サイトマップや検索機能などと複数のナビゲーションの手段を用意することで、ユーザーはさまざまな方法や切り口でコンテンツを探せるよういになります。

ページへの導線リンクを複数にします。具体例として、以下のような方法がある。

• メニュー
• グローバルナビゲーション
• パンくず
• サイトマップ
• 検索フォーム

Webページの各部分にアクセスするための複数の手段（ナビゲーションメニュー、サイトマップ、検索機能など）が存在することを確認します。

見出しやラベルがそのセクションや項目の目的を適切に表していることを要求します。

適切な見出しがないと、必要な部分を斜め読みすることが困難になります。

見出しやフォームのラベルは、関連するコンテンツや機能など内容を表します。

すべての見出しとラベルがそのセクションや項目の目的を適切に表現していることを確認します。

キーボードで操作している際に、現在フォーカスがあたっている要素が明確に見えるようにすることを要求します。

キーボードのフォーカスを受け取っている箇所が視覚的にわかるようにする。
ユーザーエージェントのフォーカス枠（outline）を利用する。

<style>
/* reset.cssなどで要素全体のoutlineが消されている */
button {
outline: none;
}
</style>

Tabキーなどを押下して、フォーカスが当たっている要素が明確に見えることを確認します。

Webページの一部が主要な言語と異なる言語で書かれている場合、その部分の言語が明示されることを要求しています。

ページの一部分で利用されている言語が指定している。

Webページ内で主要言語と異なる言語が使用されている部分が適切に明示されていることを確認します。
lang属性または、xml:lang属性で指定している。

<html lang="ja">

<html xml:lang="ja">

ナビゲーションメニューがウェブサイト全体で一貫していることを要求します。

ナビゲーションに一貫性がないと、ナビゲーションを見つけられなかったり、違うものに思えたりして混乱し、スムーズな回遊が難しくなります。

Webページ内のナビゲーションメニューやリンクの配置やスタイルを一貫して保つ必要があります。

サイトの各ページでナビゲーションが一貫していることを確認します。

法的、金融的な影響をもたらす、またはユーザーのデータを変更するような操作の前に、ユーザーがその操作を確認・修正・キャンセルできる機能があることを要求します。

法的、金融、データ変更を伴うフォームの送信は以下のいずれかができるか？

法的、金融的な影響をもたらす操作や、ユーザーデータの変更を要求する操作を行う前に、その操作の確認・修正・キャンセルが可能なことを確認します。

適合レベルAAAは、さらに高度なアクセシビリティを追求するためのレベルです。
例えば、音声認識を活用した操作の提供や、詳細なテキスト解説の提供など、全23項目があります。しかし、全てのWebサイトがこのレベルを達成するのは難しいため、具体的なユーザーの要求に応じて適用することが推奨されています。

映像コンテンツに対して手話の翻訳を提供する項目です。これにより、手話を使用する聴覚障害者もコンテンツを理解できます。

手話通訳の付与する。

映像コンテンツを再生し、手話翻訳が提供されていることを確認します。

視覚障害者が映像コンテンツをより深く理解するために、通常の音声解説に加えてさらに詳細な情報を提供する項目です。

動画をいったん停止しても、状況を理解するのに十分な音声解説をする。

映像コンテンツを再生し、拡張音声解説が提供されていることを確認します。

視覚及び聴覚障害者が映像や音声コンテンツを理解できるよう、全ての情報をテキストとして提供する項目です。

ページ内のすべての、音声、映像（音声ありなし）のメディアに対して、正確に表現した「時間依存メディアの代替コンテンツ」を用意します。

映像や音声コンテンツの近くに、それらの全ての情報を含むテキストが提供されていることを確認します。

ライブの音声コンテンツに対して、視覚障害者や音声情報にアクセスできない状況の人々が理解できるよう、テキストのトランスクリプト（会話や音声ファイルを文字に書き起こすこと）をリアルタイムで提供する項目です。

ラジオ放送などライブ音声について正確な代替コンテンツを用意する。

ライブ音声コンテンツを再生し、リアルタイムでのテキストトランスクリプトが提供されていることを確認します。

テキストと背景の色のコントラストが更に高いレベルであることを求めています。これは視覚障害を持つ人々にとって、テキストの読みやすさを更に向上させるためのものです。

テキスト及び文字画像テキストと背景の間に少なくとも 7:1 のコントラスト比を保つようにする。

Webページのテキストと背景色のコントラストをチェックします。
「Colour Contrast Analyser」を前景色と背景色を入力または取得し、コントラスト比を計測します。

小さな背景音を使用する場合は、ユーザーが音を認識しやすいようにする必要があります。また、背景音がページ上で自動的に再生される場合は、ユーザーが音声を制御できるオプションを提供する必要があります。

コンテンツを、利用者にとって見やすく、聞きやすいものにする。

Webページにオーディオコンテンツがある場合、その背景音が小さいか、または存在しないことを確認します。

少なくとも一つを満たしていることが条件です。

• 音声は背景音を含まない。
• 背景音を消すことができる。
• 背景音は、発話のコンテンツより少なくとも20デシベル以上は低くする。

長いテキストのブロックに対して適切な視覚的な形式（例：段落の分割、使用フォント、行間など）を使用することを求めています。これにより、視覚障害を持つ人々がテキストを読みやすくするためのものです。

テキストブロックの可読性を向上させる。

ページ上の長いテキストブロックが、段落分けや行間設定、適切なフォントサイズを使用して視覚的に整形されていることを確認します。

テキストを画像で表現することを基本的に禁じています。もし必要な場合でも、その画像には適切な代替テキストが提供されるべきです。

画像内に含まれるテキストがある場合、代替テキストを入れる。

テキストが画像として表現されている場合、それが必要かどうかを評価し、必要な場合には適切な代替テキストが提供されていることを確認します。

キーボードだけを使用してウェブサイトのすべてのコンテンツにアクセス可能であることを要求します。ただし、非テキスト入力（例えば、絵を描く）などの機能は除外されます。

ユーザーインターフェースのすべての機能が例外を設けずに、キーボードだけでWebページのすべての機能に対応する。

Webサイトのすべてのコンテンツと機能にキーボードだけを使用してアクセスできることを確認します。ただし、非テキスト入力などの特定の例外を考慮に入れます。

具体的には、Tabキーによりページ内の各要素をフォーカス、またマウスオーバーしてJavaScriptによる挙動を確認していきます。

ユーザーがタイミングによる影響を受けずにコンテンツを完全に理解できることを求めています。

視覚や認知に制約のあるユーザーが、時間に関係なく情報を理解できるようにするために、適切なテキストや代替コンテンツを提供されているか

Webサイトのコンテンツがタイミングによる制約を設けていないこと、あるいはタイミングによる制約が存在する場合でも、その制約が必要な場合以外のコンテンツを理解するのに影響を与えていないことを確認します。

ユーザーがWebページの非予期的なコンテンツの変更やポップアップなどの割込みを制御できることを要求します。

ユーザーがコンテンツの更新（自動的に再生されるコンテンツやタイミング制約のあるコンテンツ）を中断・延期の可能が選択できる。

Webサイト上で非予期的なコンテンツの変更やポップアップなどの割込みが発生する場合、それらをユーザーが制御できるかを確認します。

ユーザーが認証のためのタイムアウトに遭遇した場合でも、データを失うことなく続けられるようにする必要があります。

ユーザーセッションのタイムアウトや再認証の際に、情報の損失なくユーザーが操作し続けるようにする。

タイムアウト後の認証プロセス中にユーザーが入力したデータが保存され、利用者がその場所から続けられることを確認します。

特定の頻度で3回以上の閃光を発生させるコンテンツを含まないことを求めています。

閃光を伴う表現は目に痛く感じられ、人によっては非常に危険で、ユーザーの身体に危険が及ぶ恐れがありますので十分に注意しましょう。

点滅や閃光をユーザーが停止可能にする。

閃光を発生するコンテンツが存在する場合、それが特定の頻度で3回以上の閃光を発生させていないかを確認します。

ユーザーがサイト内のどの位置にいるのかを知る手段を提供することを要求します。
例えば、ナビゲーションバーで現在のページを強調表示するなど。

ページの現在位置がわかるようにする。

ユーザーがサイト内のどの位置にいるかを示す手段が存在することを確認します。

リンクのテキストだけ見ても、リンク先が何であるかがわかるようにすることを求めています。

リンクの目的や対象が、リンクだけで予測ができるようにする。
例えば、リンクには、リンク先のページタイトルを含めるなどをして、リンク先が推測できるようにしましょう。

それぞれのリンクが、リンクテキストだけでその目的が理解できることを確認します。

コンテンツのセクションに見出しが付いていることを求めています。これにより、ユーザーは情報を構造的に理解しやすくなります。

見出しを適切に使用して階層構造が整理している。
具体的には、見出し要素の <h1>~<h6>タグを適切に使用する。

各セクションが適切な見出しを持っていることを確認します。

一般的でない用語や専門用語がページ上で使用される場合、それらの定義を提供することを要求します。

一般的に理解されない用語や専門用語を使用する場合は、適切な説明や定義を提供する。

ページ上の一般的でない用語や専門用語について、それらの定義が提供されていることを確認します。

略語が初めてページ上で使われるとき、その全文が提供されることを要求します。

略語の正式名称はかっこ書きで対応します。また、ページ内に同じ単語が繰り返し出てくる場合は、最初に出てきた文言にかっこ書きをつけます。

ページ上の略語について、それらの全文が初めて使用される際に提供されていることを確認します。

Webページ上のテキストが理解しやすいレベルで書かれていることを求めています。一般的には初等教育のレベルで書かれることが推奨されます。

Webページのコンテンツは、広い範囲の読者が理解できるレベルにしている。

ページのテキストが読みやすいレベルで書かれているかを評価します。
これはある程度主観的な評価になりますが、可能であれば客観的な読解レベルの測定ツールを使用することもできます。

ページ上の単語の発音がテキストの理解に重要で、その発音が一般的に予想できない場合、発音のガイドが提供されることを要求します。

読み上げソフトウェアやスクリーンリーダーが、テキストを正確に発音できるようにする。

ページ上の単語の発音が一般的に予想できない単語について、発音ガイドが提供されていることを確認します。

ユーザーの要求がない限り、新たなウィンドウやタブを開いたり、フォーカスを移動させるなどの変化を引き起こさないことを要求します。

Webページ上での状態変化やコンテンツの更新に伴い、ユーザーに適切な通知やフィードバックがあるように対応する。

ユーザーの操作なしで新しいウィンドウが開かない、フォーカスが移動しないなど、予期せぬ変化が発生しないことを確認します。

ユーザーが必要とする場合に、ヘルプ情報を提供することを要求します。

ユーザーが必要な情報やサポートにアクセスできるように、ヘルプやサポート機能を適正につける。
例えば下記の対応は必要とされます。

• Webページ内に、ヘルプページへのリンクさせる。
• 一般的でない文字をマウスオーバーした際に、ツールチップなどで補足説明をする。

ユーザーがアクセス可能なヘルプ情報が存在することを確認します。

すべての入力に対して、ユーザーがエラーを回避できる機会を提供することを要求します。
例えば、データを送信する前にユーザーがレビューできる機会を提供するなどです。

ユーザーがエラーを起こしにくい設計にする。
例えば下記の対応は必要とされます。

• 取消：送信を取り消すことができる。
• チェック：利用者が入力したデータの入力エラーがチェックされ、利用者には修正する機会が提供される。
• 確認：送信を完了する前に、利用者が情報の見直し、確認及び修正をするメカニズムが利用できる。

「3.3.4 エラー回避（法的，金融及びデータ）」と似ていますが、「3.3.6 エラー回避」は全てのエラーを回避するように対応します。

ユーザーがデータを送信する前に、その情報をレビューし、必要な修正を行える機会があることを確認します。

Webアクセシビリティとユーザビリティは密接に関連していますが、異なる点もあります。

ユーザビリティは「どれだけ使いやすいか」を重視しますが、アクセシビリティは「誰が使えるか」を重視します。

そのため、アクセシビリティを考える際は、さまざまな障害を持つユーザーや高齢者など、すべてのユーザーを考慮に入れることが重要です。

著者がWebアクセシビリティを知ったときは、Web制作会社に入った頃でした。しかし、知っていても個人的には全く対応していませんでしたね。

Webアクセシビリティの知識が必要になったのは、レスポンシブデザインを学んだ時期に様々なデバイスに対応していくことになったからでした。

Webアクセシビリティは障害の持ったユーザーに向けての技術と思われがちですが、健常のユーザーでもITリテラシーによってWebサイトの使われ方も違います。ITリテラシーが低いユーザーにも同じ情報を取得できるようにWebアクセシビリティは全ユーザーにとって必要ですのでWebデザイナーは身につけるスキルと思いますね。

ぜひ、Webアクセシビリティを頭に入れてWebデザインしたいものですね。