なぜ必要？まずはWebアクセシビリティについて知ろう 後編

5. 押さえておきたい15のWebアクセシビリティチェックと考え方

Webアクセシビリティについての総括的な考え方・ノウハウをまとめつつ、制作側の意識も底上げをするガイドラインのような記事が書きたかったので、実質本編がメインという位置づけです。

プロダクトに対する「○○ができていますか？」という質問に対して、要件・考え方、相当する適合レベル+αで回答していく形式になっています。

JIS X 8341-3の3つの適合レベル
・レベルA ... 支援技術を駆使すればアクセスできる。最低限対応したい
・レベルAA ... 支援技術がなくても多くの環境でアクセスできる。可能なら全適合を目指したい(いわゆる推奨レベル)
・レベルAAA ... 支援技術がなくても多くの環境でアクセスしやすい発展的なもの、達成が難しいものを含む。困難なため全適合は非推奨

レベルAAが基本的に目指したいアクセシビリティ達成の推奨レベルにあたります。公的機関にはこのレベルAAの適合が総務省によって推奨されています。実際の試験実施やアクセシビリティ試験結果の記載方法については、下記のガイドラインを一度参照してみてください。

JIS X 8341-3:2016 試験実施ガイドライン
JIS X 8341-3:2016 試験実施ガイドライン（達成基準チェックリストの例）
ウェブコンテンツの JIS X 8341-3:2016 対応度表記ガイドライン

Webアクセシビリティの対応をするうえで、筆者的に以下の15項目はぜひ知って意識しておいて頂ければ、というものをピックアップしました。少し量が多めですが、Webアクセシビリティにおける最低限の品質チェックをする際にぜひ少しでも参考に、また役立ててもらえれば嬉しいです。
(大きく変えませんが、少しずつ補足や図版を追加するなど改定していく予定です)

-----

デザイン工程でのアクセシビリティチェック

● チェック1：
テキストが視認できるよう最低限のコントラストを確保していますか？

・太字でないフォントサイズ24px未満のテキストには「4.5 : 1 (文字/前景色 : 背景色)」以上のコントラスト比が必要です
・太字、フォントサイズ24px以上のテキストには「3 : 1」以上のコントラスト比が必要です
・コンテンツ上で意味を持たない装飾目的の文字や、ロゴタイプなど付随的なテキストは対象外です

考え方：
・弱視(ロービジョン)や色覚多様性の人、あるいは強く光が差し込むような環境では通常より文字等の可読性が低く、読みづらくなることがあります。この理由からコントラストの確保は大切です
・大きい文字や太字のケースでも極力「4.5 : 1」を目指すのが無難です
・パステル調のトンマナや、フォームのプレースホルダーテキストなど薄い文字色が使用され、低いコントラスト比になっていることが多くあります。できる限り低くならないよう意識したいところです
・OS標準のハイコントラストモード機能が存在しますが、サイト/アプリ側で類似の機能(ダークモード/ナイトモード等)を実装するケースも見受けられるようになってきました

適合レベル：
コントラスト (最低限): 達成基準 1.4.3 を理解する (レベル AA)

制作に使えるツール：
・WebAIM: Color Contrast Checker　... Webサービス
・Web Accessibility Guidelines　... Webサービス
・Color.review　... Webサービス

-----

● チェック2：
テキスト(おもに見出し、本文等)に対し、一般的に読みやすいとされる文字サイズを指定していますか？

コンテンツの文字サイズは16〜24px相当を(CSS指定単位はemまたはrem推奨)、行の高さは150〜200%(line-height: 1.5;以上)を目安とすると良いでしょう。
これはWCAG、Googleによる推奨サイズを基準としています

考え方：
・文字を小さくすることのデメリットは、多くの人、なかでも弱視や高齢の人が読みづらくなることです。また拡大表示の手間も生じます。逆に、文字を小さくすることのメリットは思い付きません。省スペースより可読性を大事にしましょう
・補足：段落の幅(80文字以内/全角40文字以内)、段落の間隔、文字サイズの拡大、均等割り付け(両端揃え)にしないなども押さえて可読性に配慮したいところです。次の文献が分かりやすく参考になります
Ameba | Accessibility Guidelines 1.4.8 テキストの可読性を担保する

参考：
・WCAG 2.1 | 達成基準 1.4.12 テキストの間隔
・WCAG 2.0 | 視覚的提示: 達成基準 1.4.8 を理解する

見やすいスタイル  |  Web  |  Google Developers

制作で使えるツール：
WhatFont　... Google Chrome拡張機能

-----

● チェック3：
1. フォームに入力項目を説明するラベル(項目名)は必ず存在していますか？
2. テキスト入力フォームのプレースホルダー(placeholder)がラベルの役割を持ち、ユーザーが文字入力するとき見えなくなる仕様になっていませんか？

1：コンテンツが利用者の入力を要求する場合は、ラベルか説明文が提供されていることが必要です

考え方：
・2：プレースホルダーテキストはフォーカス時に見えなくなるため、ラベルとして使用するとユーザーから見えなくなる、間違いの検証・チェックがしづらいなど、ほかにもさまざまな問題があります。ラベルにする使用方法は控えましょう
・2：プレースホルダーテキストがフォーカス時にアニメーション移動する「フローティングラベル」というテクニックで一応上記問題が解消可能です
フローティングラベルの参考デモ

適合レベル：
ラベル又は説明: 達成基準 3.3.2 を理解する (レベル A)

-----

● チェック4：
クリックorタップで操作可能なターゲット要素(リンク/ボタン)は、適切なサイズを確保したデザインになっていますか？

・WCAGやAppleのiOSヒューマンインターフェイスガイドラインでは、最低サイズ44×44pt(px)が推奨されています
・Google Web Fundamentalsでは、推奨される最小タッチターゲットサイズは48dip(デバイス非依存ピクセル)=48×48pxで約9mm(人の指の腹部分に相当)となっています
・特にスマートデバイス向けコンテンツでは、タップターゲットに水平/垂直方向約8pxの間隔を置くことが推奨され、ユーザーの意図しないタップ(誤タップ/操作ミス)を防ぐつくりにしましょう

考え方：
・サイズの小さいリンクやボタンはユーザーにとって見つけにくいだけでなく、押しづらく誤操作を招きやすいです。実寸のプロトタイプなどで実際に押しやすいかどうかを検証するのが確実でしょう
・重要度の高いターゲットアクションには、”ユーザーに操作確定を確認するダイアログ表示”などを検討しても良いかもしれません

参考：
WCAG 2.1 | 達成基準 2.5.5 ターゲットのサイズ

-----

● チェック5：
リンクはリンク、ボタンはボタンであるとユーザーが判別・認識できるようなデザインになっていますか？
また、サイト内共通の分かりやすい現在地表示はありますか？

サイト/ページ内を通して、リンクに使うラベルやUIパーツが意味的に一貫しており、ユーザーを惑わせないようになっていることが求められます

考え方：
・段落テキストの中に下線付きテキストがあればリンクであることが分かります。また、ボタンは”押せそう”であるというアフォーダンスに則ったデザインにすることが重要です
・機能が同じなら見た目や文言の同一性・一貫性をできる範囲で保ちたいところです(すべてを同じにするということではありません)
・逆に役割・機能が違う場合、見た目の明確な違いを事前にユーザーに分かりやすく提示し、誤解を与えないこともまたデザインの役目ではないでしょうか

適合レベル：
一貫した識別性: 達成基準 3.2.4 を理解する (レベル AA)

参考：
WCAG 2.0 | 現在位置:達成基準 2.4.8 を理解する

-----

● チェック6 (ライティング)：
1. コンテンツの内容を的確に表したページタイトルになっていますか？
2. 見出し、キャッチなどはユーザーが理解しやすく、本文の意味が的確に伝わる間違いのない内容になっていますか？
3. リンク先が分かりやすく伝わるようになっていますか？

1：コンテンツに関連し、Webページを特定できるtitle要素になっているかを確認します
2：内容が端的に分かるように見出しなどをつける必要があります

考え方：
・1：title要素は検索結果ページ(SERPs：Search Engine Result Pages)にも表示される重要な要素です。シンプルに内容を伝えるために”[検索(してもらいたい)語句] | [Webサイト名]”あるいは”[Webサイト名] | [検索語句もしくはページ名]”とする形式が良いでしょう
・2：見出し(hx要素)に主語がなかったり、本文要約になっていなかったりする場合は情報が伝わりにくいので文章を見直しましょう。特に、スクリーンリーダーユーザーは目次のような形で見出しをたどり、コンテンツの内容を参照していることが多いようです
・全般的に、アクセシブルな名前(accessible name)や説明を意識したライティングをすることで、SEOと同時にあらゆるユーザーにとって情報取得しやすいコンテンツになります

適合レベル：
・ページタイトル: 達成基準 2.4.2 を理解する (レベル A)
・見出し及びラベル: 達成基準 2.4.6 を理解する (レベル AA)

制作で使えるツール：
Alt & Meta viewer　... Google Chrome拡張機能

-----

● チェック7：
フォームの入力成功/失敗やボタンの有効/無効状態など、色だけがユーザーに情報を示す唯一の手がかりになっていませんか？

色の違いで情報を伝えているのであれば、同時にテキストでも示す必要があります。また、テキスト色の違いで情報を伝える際は、アイコンなど視覚的な手がかりで補足します

考え方：
・世界人口の約4％、日本人では男性の20人に1人(5%)が色を区別する能力が異なる色覚多様性を有しているという統計があり、赤と緑を区別するのが困難(2型3色覚)といったケースが多くあります
・アイコンもしくはテキストを添えるだけでも情報はより明確になります。ただアイコンだけの場合はさらに音声読み上げ対応も必要になります
・文章中にテキストリンクがある場合は、下線をつけるなどしましょう

適合レベル：
色の使用: 達成基準 1.4.1 を理解する (レベル A)

----------

コーディング工程でのアクセシビリティチェック

● チェック8：
1. a要素とbutton要素の使い分けがマークアップでできていますか？
2. これらのインタラクティブ機能をdiv・span要素に担わせていませんか？

意味のあるマークアップをすることがヒューマンリーダブルとマシンリーダブルにつながります

考え方：
・1：HTMLの用途定義として、a要素は「ページ遷移・移動」、button要素は「ページ遷移・移動以外のアクションボタン」として使い分けて用いるべきです
・2：aやbuttonではなくdivやspanなど意味を持たないコンテナ要素を使用すると、デフォルトでキーボードフォーカスせず、イベントも発火しない上にセマンティック(意味的)ではありません。またrole="button"を付与しないと「ボタン」と音声読み上げされず(ボタンパーツであることが分からない)、JavaScriptのkeyupイベントハンドラの追加が必要になるなど記述が冗長で本末転倒になり、メンテナブルではありません

参考コード：

HTML
<a href="#main">画面遷移もしくはページ内遷移リンクです</a>

<button type="button">ページ遷移・移動以外のアクションボタン</button>
   
<!-- 非推奨マークアップ -->
<div class="js-trigger-button">JSで動作させるリンク・ボタン</div>
<span class="js-trigger-button">JSで動作させるリンク・ボタン</span>

フォーム系要素全般がそうですが、button要素には各ブラウザ独自のボタンスタイルが設定されているので、以下CSS記述でリセット設定をしておきます。

CSS
/* button要素のスタイル初期化 */
button {
  background-color: transparent;
  color: inherit;
  border-width: 0;
  padding: 0;
  cursor: pointer;
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
}

適合レベル：
・キーボード: 達成基準 2.1.1 を理解する (レベル A)
・キーボードトラップなし: 達成基準 2.1.2 を理解する (レベル A)

-----

● チェック9：
a要素のリンク遷移機能を無効化する<a href="javascript:void(0);">という記述をわざわざ用いていませんか？

ユーザーにとって意味のない「javascript:void(0);」という文字列がブラウザ左下/ステータスバーに表示され、アクセシブルではありません

考え方：
・a要素のリンク機能をわざわざ無効化する以前に、マークアップをdiv・spanもしくはbuttonに変更するなど、ほかにできることはありませんか
・それでも特定のa要素のリンク機能を無効化したい場合、preventDefault()をJavaScriptのイベントリスナーに記述しましょう。また、CSSのpointer-events: none;はキーボードイベントを無効化しません。完全なリンク無効機能ではないことを知っておきましょう
・こういった手法は不自然だったり、それほど好ましくない影響が出たりすることがあります。「制作者都合で便利、手っ取り早い」という理由ではなく「ユーザーにとってどうか、影響があるか」で考えましょう

-----

● チェック10：
a要素やbutton要素など対話型コンテンツの要素セレクタに、outline: none;を指定してフォーカスリングを消していませんか？

キーボードのフォーカス状態まで見えなくなり、選択・入力操作に混乱をきたすのでoutline: none;(outline: 0;)指定は避けましょう。
※ reset.cssで(無自覚に)この指定をしているケースが多いので確認を

考え方：
・対応としてベターなのは、マウスには:hover疑似クラスがあり、タップにはフォーカスの必要がないことから、キーボードのフォーカススタイルのみ生かすことです
・マウスかタップ(touch)かキーボードかなどの入力形式を判定する「what-input」というJavaScriptライブラリを導入すると、キーボード操作以外をoutline: none;にする方法が選択できます
・フォーカスリングを選択的に表示できるものとして、CSSの:focus-visible疑似クラスがありますが、策定段階でCSS4の勧告を待たねばならないようです。Firefoxのみ:-moz-focusringとして対応実装しています

参考コード：

JavaScript
  // ES Modulesインポート
  import whatInput from 'what-input';

CSS
/**
  * what-input.jsによるdata属性を使用
  * マウス/タッチイベント時のフォーカスリングスタイルを打消
  * キーボードフォーカス時のみフォーカススタイル有効
  */
[data-whatinput="mouse"] *:focus,
[data-whatinput="touch"] *:focus {
  outline: none;
}

適合レベル：
・キーボード: 達成基準 2.1.1 を理解する (レベル A)
・フォーカス順序: 達成基準 2.4.3 を理解する (レベル A)
・フォーカスの可視化: 達成基準 2.4.7 を理解する (レベル AA)

-----

● チェック11：
コンテンツ上必要なimg要素に対し、内容が適切に伝わる代替テキスト(alt属性値)は設定されていますか？

・alt属性値にはただ文字の羅列を記載すればいいわけではありません。画像表示エラー時や、視覚障害がある人などにコンテンツの文脈(コンテクスト)が適切に伝わる文章であることで意味を持ちます
・コンテンツの文脈上、説明する必要がない装飾目的の画像はalt=""(値が空)とするか、またはCSS背景画像(background-image)などを使います

考え方：
・時々、alt属性値を書くのは誰の仕事か、誰の責任かといった話題が上ることがあります。制作者であれば誰もがライティングスキルを持ち、コンテクスチュアルな説明文を書けたほうが良いでしょう。そのためには各人のコンテンツ文脈の理解が必要です
・画像はWebページの表示パフォーマンスや制作工数に影響します。まず表現手段として本当に必要か検討したうえで、使用する際は適宜最適化や非同期読み込みなど工夫して用いたいものです

適合レベル：
非テキストコンテンツ: 達成基準 1.1.1 を理解する (レベル A)

参考：

【画像軽量化】WebPにそろそろ対応したほうが良さそうなので現時点で最適方法の考察 - ウェブ企画ラボ

制作で使えるツール：
Alt & Meta viewer　... Google Chrome拡張機能

-----

● チェック12 (フォーム)：
フォーム入力項目(input要素等)すべてにラベル(label要素)が存在し、関連づけられていますか？

ラベルを選択すると入力項目にフォーカスが当たり、選択操作ができるようになっている必要があります

参考コード：

HTML
  <!-- for属性とid属性の値で関連づけ -->
  <label for="name">ラベルテキスト</label>
  <input type="text" id="name">
   
  <!-- labelの入れ子にして関連づけ -->
  <label>
    <input type="radio">
    <span>ラベルテキスト</span>
  </label>  

適合レベル：
・ラベル又は説明: 達成基準 3.3.2 を理解する (レベル A)
・見出し及びラベル: 達成基準 2.4.6 を理解する (レベル AA)

-----

● チェック13 (フォーム)：
チェックボックス、ラジオボタン、セレクトボックス、ラベルなどがカスタマイズの影響でキーボード選択(フォーカスおよび操作)できないものになっていませんか？

フォームの場合、キーボードフォーカスインジケータが表示されないと入力が完遂できなかったり、スクリーンリーダーでも扱いにくくなったり、認識できなくなったりします。デザインのために必要な機能を殺さないようにしましょう

考え方：
・どうしてもカスタマイズしたデザインを適用したい場合は、input type="checkbox"やinput type="radio"自体に.visually-hiddenというCSSテクニックを用いて視覚的に隠し、疑似要素と疑似クラスに紐づいたスタイルを適用する表現があります(visibility: hidden;とは違います)
・上記方法ならスクリーンリーダー読み上げもでき、キーボードフォーカスも殺さずにデザインがカスタマイズできます
・対話型コンテンツ(インタラクティブコンテンツ)でないと、tabindex属性でフォーカスはできても操作(決定)まではできません。divやspanを代替に使う方法はセマンティックでない上に不足が生じます

CSS
/**
　* コンテンツを視覚的に隠し、音声読み上げ機能には読ませる
　*/
.visually-hidden {
  position: absolute;
  white-space: nowrap;
  width: 1px;
  height: 1px;
  overflow: hidden;
  border: 0;
  padding: 0;
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
}

参考までに、見た目をカスタマイズし、キーボードフォーカスもできるサンプルを用意しました。詳しくはこちらを参照してみてください。

適合レベル：
・キーボード: 達成基準 2.1.1 を理解する (レベル A)
・フォーカス順序: 達成基準 2.4.3 を理解する (レベル A)
・フォーカスの可視化: 達成基準 2.4.7 を理解する (レベル AA)

参考：

キーボード操作もできるようにチェックボックスとラジオボタンをCSSでカスタマイズする ｜ Tips Note by TAM

-----

● チェック14 (フォーム)：
ユーザーがフォーム入力する際、文字入力するたびにアラート(バリデーション)表示されるなど、わずらわしいものになっていませんか？

考え方：
・ユーザーはリアルタイムの入力エラー表示を、実際はそれほど歓迎していないという調査結果があります
・フォームにおけるリアルタイムの入力エラー表示は割と複雑な仕組みで制御されています。その上さらにスクリーンリーダー対応などアクセシブルに作るのはかなりハードルが高いです。この機能は「お節介なだけの高等技術」かもしれません
・絶対こうすべきという指針はありません。送信ボタンクリック後いっぺんにエラー表示させる方が、ユーザー自身の「入力モード」「修正モード」の切り替えができ、効率的かもしれないことが示されています(以下記事参照)
・ログインフォームにおける[ ユーザー名(ID) / パスワード ]入力は例外とのこと

参考：

インラインバリデーションがフォーム入力の妨げになるケース

原文：Why Users Make More Errors with Instant Inline Validation

-----

● チェック15：
ユーザーがアニメーションや動画・音声メディアを再生・停止などコントロールできるようなっていますか？

コンテンツが何らかのメディアや、要素に動きがある場合(点滅や自動スクロールを含む)、ユーザーがそれをある程度は停止・再生、非表示にできるようにする必要があります

考え方：
・たとえば電車・バス内など公共交通機関や会議・プレゼンなど、大きな音を立てたくない場所でWebを利用するケースがあるかもしれません。昔よくありましたがページを開くと動画や音楽を自動再生するサイトはこうした場では不適切なので、避けましょう
・文字情報の背景で画像やカルーセルパネルなど何らかの視覚要素が動いていると、文字を読むことに集中できなくなる人もいます。一時停止・再生ボタンを用意して、制御をユーザーに委ねる配慮も必要です
・あまりビカビカ光らせないようにしましょう

適合レベル：
・一時停止、停止、非表示: 達成基準 2.2.2 を理解する (レベル A)
・3 回の閃光、又は閾値以下: 達成基準 2.3.1 を理解する (レベル A)

-----

ここまででWebアクセシビリティの最低限レベルの考え方と対応するべきことをある程度理解し、把握できたかと思います。また、これらの考え方を知り実践できれば、自然とレベルA・AAなど規格の達成等級への対応もそれほど大変ではなくなるはずです。

Webコンテンツの制作は、これらのポイントを押さえたところからがスタート地点だと思います。あとは実践とケースバイケース対応です。対応が必要だと思えるものをリスト化するなり、頭の中の引き出しに入れるなりしておいていただければ幸いです。良きWeb制作ライフを！

参考：
実はできているWebアクセシビリティ 007

ウェブ制作に関わる人に役立つウェブアクセシビリティの基本 - ICS MEDIA

UX and the Importance of Web Accessibility

※補足修正 (2019/10/21)：
各チェック項目「適合レベル」の外部リンク参照先を、waic.jpの「実装チェックリストの例 2012年11月版」配下から「WCAG 2.0解説書」の該当ページへ変更しました。理由としては、情報の古さや更新面などからWCAG 2.0解説書がより適切であろうと現在では考えられるためです。