だれもが、どこからでもアクセスできるウェブアクセシビリティとは?

だれもが、どこからでもアクセスできるウェブアクセシビリティとは?

本のまとめ

▼読んだ本は?
■デザイニングWebアクセシビリティ: アクセシブルな設計やコンテンツ制作のアプローチ
■太田良典さん, 伊原力也さん
http://amzn.asia/d/3H4xERn
▼ウェブアクセシビリティって?
■そのウェブサイトにユーザーが「アクセスできる」状態を目指すこと
■障害者や高齢者など「誰もが」アクセスできる
■さらに「どんなデバイスからでも」アクセスできる
▼ユーザーエージェントって?
■WEBサーバーにアクセスして、さまざまな処理をユーザーの代わりにやってくれるもの
【1】ビジュアルブラウザ
└サイトをレンダリングして、テキストや画像、動画を表示する

【2】テキストブラウザ
└Lynxやw3mなど、テキストだけで表示する

【3】ダウンローダー
└コンテンツをダウンロードする

【4】ロボット
└フィードリーダーなど、人が操作せず、サイトに自動的にアクセスして情報を取得する

【5】クローラー
└検索エンジンなど、自動的にリンクをたどってページの情報を取得する

【6】スクリーンリーダー
└「PC-Talker/JAWS/NVDA」など、画面の内容を、合成音声で読み上げるソフトウェア

▼アクセシビリティの標準は?
■2008年にW3Cが勧告した「Web Content Accessiblity Guidlines」(WCAG)が世界標準
■日本では、2010年に日本工業規格が「JIS X 8341-3」としてWCAGガイドラインをほぼそのまま規格化
■「JIS X 8341-3」には以下3つのランクがあり、WCAGが用意する「Easy Checks」で簡単なチェックができる
【1】シングルA
└最低限となる25項目の基準を達成
└これを満たせていないと、環境によっては全くアクセスできないレベル

【2】ダブルA
└シングルAの25項目に加えて、追加13項目の基準を達成
└望ましいといわれるレベル

【3】トリプルA
└シングルA/ダブルAの合計38項目に加えて、追加23項目の基準を達成
└発展的といわれるレベル

▼要件定義の時のチェック箇所は?
■CAPTCHA機能利用があれば、画像が表示できない環境に備え音声でのチェックや、電話での不正アクセスチェックを追加する
■画像コピー防止のため「右クリック禁止」などブラウザやOSの機能制限はなるべく行わない
■独自機能実装ではなく、ブラウザデフォルトのズーム機能について案内し、そちらを使ってもらうようにする
■本文内に配置するスキップリンクが使いにくくなるため、「見出し」へのリンクを増やして使いやすくする
■独自の音声読み上げ機能は使えないときがあるため、ブラウザデフォルトのスクリーンリーダー機能で読み上げるようにする
■動画コンテンツには字幕をつける
■紙原稿はWEB用に再構成する
■CMSのWYSIWYGエディタを利用する場合、HTMLの記述等が自由に行われないように、ガイドラインなどを予め定めておく
■CMSのアクセシビリティチェック機能が過剰ではないか、CMSの選定プロセスのときに機能をチェックする
▼ナビゲーション設計の時のチェック箇所は?
■ユーザーの行動フロー/ニーズを想定して分類/カテゴライズを行う
■いろいろな分類/カテゴライズから絞り込んで情報をすぐに探せるようにする
■コンテンツ目録やサイトマップを作成して、情報の分散を防ぐ
■中身を推測できるカテゴリ名にする
■ユーザーの実際のサイト内の動きを想定した階層構造にする
■途中の階層を含めて、段階的にページ遷移できるようにする
■ナビゲーションルールをはじめに決めて、位置やデザインを統一する
■ナビゲーションのテンプレートファイルを用意したり、CMSでナビゲーションを管理する
■ナビゲーションの色を変えるなど、現在地表示をつける
■パンくずリストを付けて今どこにいるか分かるようにする
■共通ヘッダーにトップページへのリンクを設置しておく
■ページ全てに最初のページへのリンクを設置しておく
■上位階層に進むためのリンクを定位置に設置しておく
■ページ終わりには関連記事やコンバージョンに関わるリンクを設置して、行き止まりを防ぐ
■検索結果ページで、検索を再度やり直せるようにしておく
■サイトマップ、サイト内検索を設ける
▼インタラクション設計の時のチェック箇所は?
■マウスでもキーボードでも操作できるようにする
■デバイスに依存しない形で操作できるようにする
■スワイプUIとかの場合、切り替えボタンでも操作できるようにする
■標準のスクロールバーを使う
■スクロールを使いすぎず、ページを分割したり、「もっと読む」ボタンを設ける
■行き来する必要のあるリンクを、タブやポップアップにせず、サイト内動線を強化する
■リダイレクトなど自動移動は無しにし、ユーザーの操作にまかせる
■自動で動いたり切り替わったり動かしすぎず、固定の表示にする
■自動で動いても、自分で止められるようにする
■自動で動かすのではなく、なるべくユーザーの手動にする
■動く表現を、目立たせたいところ一箇所だけに絞るなど限定する
■ユーザーの操作で、音声つき動画を再生できるようにする
■動画の音声の大小を、コントロールできるようにする
▼フォーム設計の時のチェック箇所は?
■フォームのタイトルをしっかり表示する
■フォームの入力にかかる時間を表示する
■フォーム入力に必要な準備や情報をはじめに明らかにする
■できるだけ入力に必要な項目を減らす
■入力項目を、可能な限り任意にする
■補完できる内容は、システム側で入力を自動補完する
■チェックボックスやラジオボタンひとつずつにもラベルを付ける
■送信ボタンなどには、具体的な動作が分かるラベルを付ける
■プレースホルダーをラベル代わりにしない
■入力項目はできるだけ縦にならべ、十分なマージンをもうける
■入力文字タイプを柔軟に受け付けて、システム側で変換する
■電話番号などで入力欄を分割せずに、一つに統合しておく
■プルダウンの選択肢の項目の調整、並び順に配慮する
■リセットボタンをなるべく利用しない
■戻ろうとした時アラートを出すなどして、ユーザーの再入力の負荷を防ぐ
■入力欄へのフォーカス移動はユーザーの手動にする
■過去の日付など選べない選択肢は、予めクリックできないようにする
■送信前にエラーチェックを行えるようにする
■エラー箇所をビックリマークなどで明示する
■エラー理由と修正方法を明示する
■エラーがリアルタイムで出るようにする
■送信前に確認画面を挟む
■送信前に入力済み項目の訂正やキャンセルができるようにする
■戻っても入力した内容が消えないようにする
■フォームセッションの有効期限を長めにする
■再ログインで続きから作業できるようにしておく
▼コンテンツ設計の時のチェック箇所は?
■コンテンツの内容が思い浮かぶタイトルをつける
■ツールを使って、検索結果などにタイトルがどんな形で表示されるかを確認しておく
■コンテンツの冒頭に見出しをおく
■コンテンツ内の各セクション見出し(小見出し)を書いておく
■見出しの階層構造を明確化する
■難しい漢字などにはルビをつける
■かっこ書き、脚注で難しい用語は補足説明を入れる
■用語集で別個で説明を入れる
■表組みを使う場合、セル結合をなるべく使わない
■ひとつの表には、ひとつのデータだけにする
■画像を使う時は本文やキャプションで説明する
■画像には代替(alt)テキストを付与する
■リンクがある場合「リンク先の記事タイトル」をつける
■文中リンクはなるべく使わない
■周辺のテキスト内容をリンク名に含める
▼デザインの時のチェック箇所は?
■テキストの大小などテキスト自体にも変化をつける
■円グラフなど色分けした要素には、それぞれにラベルをつける
■スクリーンリーダーでも理解できるよう、打ち消し線はさける
■白と黒など、なるべく強めのコントラストを利用する
■文字を大きく、文字の下に色を敷いたり背景をぼかしたりして文字を目立たせる
■青色リンクや下線リンクなど、リンクには標準的なデザインを使う
■リンクに矢印やアイコンを付けて、リンクであることをわかりやすくする
■行間や段落間の高さ、また行の長さを適切に設定して読みやすくする
■画像を使いすぎず、テキストやWEBフォント、CSS装飾を利用する
■拡大したり印刷しても表示が汚くならない、SVG形式の画像にする
■色や枠線の変更など、フォーカス箇所を強調する
■操作しやすい大きさで、かつ要素間の間隔を十分に空ける
■選択肢のラベルや、要素の一部だけでなく全体をクリックできるようにする
■スマートフォンなどのタッチ操作ができる前提でデザインする
■デザインスタイルを明確化し、ガイドライン化しておく
■アイコンとラベルはセットで表示する
■点滅や明滅など、閃光はできるだけ利用しないか控えめにする
■モーダルなどが画面からはみ出す場合を想定し、スクロールバーなどを付けておく
■スクロール時に追従するナビなどは、幅を取りすぎないよう慎重に検討する
■リキッドやレスポンシブデザインを検討する
■拡大や文字サイズ変更ができるようにする
▼実装/構築の時のチェック箇所は?
■HTMLを書く時はオーサリングツールなどでHTML文法をしっかりチェックする
■W3Cが提供する「The W3C Markup Validation Service」など文法チェックツールを利用する
■h1,h2など見出し箇所の要素を適切にマークアップする
■JavaScriptを利用してリッチな動きを付けたい場合、その要素の役割や状態をコード内に記載できるWAI-ARIAに沿ったコード記述を行う
■代替(alt)テキストが必要な画像は、背景画像ではなく前景におく
■スクリーンリーダーでの読み上げ順番を踏まえて、HTMLの記述順序に気をつける
■すべての画像に適切な代替(alt)画像を付与する
■意味をもたない装飾画像の代替(alt)テキストは、空にしておく
■リンク画像にも代替(alt)テキストを付与する
■不要なテキストは画像化するかWAI-ARIAを利用するなどして、スクリーンリーダーに読み込まれないようにする

思ったこと

視覚や聴覚にたとえ障害があっても、そしてどんなデバイスや環境からでも、誰もがどこからでもWEBサイトにアクセスできることを目指すWEBアクセシビリティについて書かれた本でした。

W3Cから何十項目にも及ぶアクセシビリティの基準項目が明確に提示されていて、そこには「ただアクセスできる」ことを超えて、ナビゲーションやクリックなどインタラクション方法、そしてデザインやコンテンツ設計時の注意ポイントなどを含めて、アクセスできるだけではなく、より使いやすくするにはどうしたらいいという観点がまとめられています。

ただ、大事なのは単純にW3C守ろうぜという話ではなく、より優先したいリッチなデザイン作成などがある場合は、リッチさと、アクセシビリティ観点と、その両方の観点のバランスを取って、適切な答えを見つけていくことが大事なんだと思います。

でも、やっぱWEBサイトの利点って、誰もが世界中からアクセスできることを目指してるだもんな、そういう意味では、アクセシビリティを大事にするというのは、WEBのはじまりからある概念とも言えるのかも知れません。

ありがとうございました!

関連する記事