アクセシビリティメモ/書籍「Webアクセシビリティ ~標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践~」 第1章 http://www.ark-web.jp/accessibility/164.html
このページは? †
Webアクセシビリティ -標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践-
http://www.amazon.co.jp/dp/4839922209
- 第1章:「Webアクセシビリティを理解する」のサマリーです。
参考ページ †
第1章に関しては翻訳者の渡辺隆行さんが全文を公開しています。
- 第1章:Webアクセシビリティを理解する(第1章全文)
http://www.comm.twcu.ac.jp/%7Enabe/UAI/Chapt1/
また、第1章を使った「Webアクセシビリティ概論」のページもあります。
- 「Webアクセシビリティ概論」(UAIセミナー) (1)
http://www.comm.twcu.ac.jp/~nabe/UAI/20080515/nabe/
サマリー †
Webアクセシビリティの必要性 †
- 障害者が社会に参加する機会をWebはもたらしてくれる。
- アクセシブルなWebサイトでは、障害者も普通のことができる。
1. Webアクセシビリティとは何か? (P44〜) †
- Webアクセシビリティの最重要点は、障害者がWebを利用できること。
- 障害者がWebを知覚し、理解し、ナビゲーション(Webサイトのページ間やページ内を移動したり見てまわったり)し、インタラクション(Webに入力したり情報を受け取ったり)できること。
- Webアクセシビリティは、Web利用に影響する全ての障害を含む。これらは、視覚障害、聴覚障害、肢体不自由、発話障害、認知障害、脳機能障害を含む。
- Webアクセシビリティは、障害を持たない人にも利点がある。
- Webアクセシビリティで最も重要な原則は、ユーザーによって異なるニーズに柔軟に適合するようにWebサイトをデザインすること。
→ 一般的なユーザビリティも向上し、障害を持たない人も各自の好みに応じてWebを利用できるようになる。
- Webアクセシビリティで最も重要な原則は、ユーザーによって異なるニーズに柔軟に適合するようにWebサイトをデザインすること。
1-1. Webアクセシビリティの例:代替テキスト (P46〜) †
- 今日、多くのWebサイトがナビゲーションのために画像を使用しているが、そのようなサイトで代替テキストが欠けていると、そのサイトはまったく使えない。
- 代替テキストを付与することでアクセシビリティが向上するが、このとき、Webサイトの見た目は変わらないことに注意されたい。
- 実際のところ、アクセシビリティを向上させる修正のほとんどは見えないところで機能し、障害を持たない人間がWebを使う際のユーザー体験に影響を与えない。
見た目以外への配慮。見えない人のユーザー体験をイメージする。
1-2. Webアクセシビリティの他の例 (P48〜) †
- オーディオ・キャプション
- 検索エンジンはオーディオファイルの中身を調べないが、文字による書き起こしとしてキャプションをつければ、その情報は検索エンジンにも利用できる。
- デバイス非依存
- Webサイトは、特別な種類の装置、たとえばマウス、を用いなくても利用できるようにデザインするべきである。マウスが付いていない携帯電話やその他の機器を使用している人々の助けにもなる。
- 明確で一貫したデザインとナビゲーション
- 障害者ではないけれども携帯電話やPDAなどの画面が小さい機器を使用している人の助けにもなる。
2. Webアクセシビリティは機会均等に不可欠 (P50〜) †
- Webは、これまでになかった人との関わりをもたらす機会にもなり、障害者がより積極的に社会参加できるようになる。
情報を共有することで人々がコミュニケーションできるような、共通した一つの情報空間が、Webが夢見る世界である。 ― Tim Berners-Lee、ワールドワイド・ウェブの発明者、 “The World Wide Web: A very short personal history” (www.w3.org/People/Berners-Lee/ShortHistory)
- Webをアクセシブルにすることで人々の暮らしが劇的に改善し、全体として、社会に利益をもたらす。
- Webアクセシビリティが社会的な問題だということを理解すれば、組織、特に企業の社会的責任(CSR)に関与している組織にWebアクセシビリティを位置づけることができる。
- アクセシブルなWebサイトがあるだけで企業の社会的責任を示すことになる。
3. 障害者以外への利点 (P51〜) †
- 高齢者
- たとえば、加齢が原因で視力が衰えた多くの人は、前景色と背景色の十分なコントラストの恩恵を受ける。
- 読み書きが不得手な人、その言語に堪能でない人
- 特に、認知障害者に対するWebアクセシビリティ上の配慮の多くは、Webで使われている言語をよく知らない人の役に立つ。
- ネットワーク接続の帯域が狭い人、古い技術を使っている人
- 文字による画像の説明は、ダウンロード時間をスピードアップするために画像表示をオフにしている人や、画像を表示しない機器やソフトウェアを使っている人の役に立つ。
- スタイルシートを使ってコンテンツと表現を効果的に分離すれば、ファイルサイズが小さくなりダウンロードが容易になる。
- スタイルシートなしでも閲覧できるように作成されたWebサイトは、古い技術の一部はスタイルシートを処理できないので、そういう技術を使っている人の役に立つ。
- Webの初心者
4. 相互依存しているWebアクセシビリティの構成要素 (P53〜) †
- Webが障害者にアクセシブルになるためには、Web制作とインターラクションに関する構成要素すべてが協調することが絶対に必要。これらの構成要素がそれぞれの役割を果たさなかったら、それ以外の要素に対する負担が大きくなり、Webのアクセシビリティは低下する。
4-1. 構成要素の解説 (P54〜) †
- 構成要素を考える方法のひとつは、技術と人間の二つのグループに分けること
- 技術的な構成要素
- Webコンテンツ:
- 技術仕様(XHTML+CSS/Web技術とかマークアップ言語)
- オーサリングツール
- 評価(テスト)ツール
- ユーザーエージェント(Webブラウザ、メディアプレーヤなど)
- 支援技術(Web利用を改善するために障害者が使うソフトウェアやハードウェア。スクリーンリーダーなど。)
- 人間に関する構成要素
- ツール開発者
- ユーザー
- コンテンツ制作者
4-2. 実装サイクルにおけるアクセシビリティ (P57〜) †
- 構成要素間の相互依存性は、アクセシビリティ機能を先に実装するのはどちらかという「卵が先か鶏が先か」問題を今まで引き起こしてきた。
- ある構成要素がアクセシビリティ機能を欠いている場合、ほかの構成要素がその機能を実装してもユーザーのアクセシビリティを高める結果につながらないなら、ほかの構成要素は、そのアクセシビリティ機能を実装しようとは思わない。
- ひとつの構成要素にアクセシビリティ機能が有効に実装されると、ほかの構成要素がそれらのアクセシビリティ機能を実装する可能性が高くなる。
アクセシビリティは1つの構成要素で実現するものではなく、互いに依存しているもの。誰が先ではなく、それぞれが始めることが、アクセシビリティ実現の近道。
4-3. アクセシビリティ対応が弱い部分の補償 (P57〜) †
- オーサリングツールやユーザーエージェントがアクセシビリティ機能を持たない場合、コンテンツ制作者ができること。
- オーサリングツールがアクセシブルなマークアップをしない場合、コンテンツ制作者が自分で直接(X)HTMLファイルに書き込んでマークアップできる。
- ユーザーエージェントがコンテンツ構造に沿ってナビゲーションする機能を提供しない場合、コンテンツ制作者は、Webコンテンツにナビゲーション機能を追加できる。
- 時にはユーザーが、ブラウザやコンテンツに欠けているアクセシビリティを、同じWebページであっても、違うユーザーエージェントや支援技術を組み合わせて用いることにより、補うことができる。
- 残念ながら、多くのアクセシビリティ問題ではユーザーが取れる回避策がなく、コンテンツはアクセスできない。
4-4. 構成要素をまとめる (P59〜) †
- W3C WAI(www.w3.org/WAI/)は、国際的なWebアクセシビリティ取り組みの協調を進め、技術面と人間面の構成要素に関して考慮すべき点をひとつにまとめている。
- アクセシビリティ・ガイドラインを策定するために協調したこうした努力によって、各構成要素がうまく協調して機能するためのフレームワークが提供される。
- このフレームワークにより、各構成要素が他の構成要素に何を期待できるかが明らかになるので、卵が先か鶏が先か問題の解決にも役立つ。
- オーサリングツール・アクセシビリティガイドライン (ATAG)
- オーサリングツールを障害者にもアクセシブルにする方法を説明し、Web制作者がオーサリングツールを用いてWCAGに適合したWebコンテンツを作成するのを手助けをする方法を明確にしている。
- ウェブコンテンツ・アクセシビリティガイドライン (WCAG)
- コンテンツ制作者に対して書かれているもの。障害者に対してWebコンテンツをアクセシブルにする方法を説明している。
- ユーザーエージェント・アクセシビリティガイドライン (UAAG)
- 主としてユーザーエージェントの開発者向け。
5. Webアクセシビリティ実現の方法 (P62〜) †
http://www.comm.twcu.ac.jp/~nabe/UAI/Chapt1/#approach
障害者に対するアクセシビリティの重要性や障害者以外に対するアクセシビリティの利点が、組織や個人がアクセシビリティに取り組む方法に考慮されることは滅多にない。Webプロジェクトの多くは、アクセシビリティ・ガイドラインや評価テストの報告を制作サイクルに組み込むのが遅い。ただそれだけに注目するのではなく、アクセシビリティ向上作業の中心に置くべきガイドラインはある。
5-1. 今すぐに始めよう †
- アクセシビリティ対応はWebプロジェクトの最後まで放置されることが多い。プロジェクトの最後に対応したのでは、より費用がかかり、重荷となってプロジェクトを挫折させる。
- Webサイトを制作あるいは改訂する際、最初からアクセシビリティを考慮すれば、プロジェクトの最後に考慮するよりも、はるかに簡単で、より有効的で、費用もかからない。
5-2. 問題を理解するところからはじめる †
- アクセシビリティ標準だけを用いる(チェックリストを用いてチェックするだけ)と、プロジェクト達成には時間がかかり、不満が増し、そして有効な結果をあまり生まない。
- アクセシビリティの効果がない努力に時間を費やさずにすむもっとよい方法がある。
ガイドラインに飛びつく前に、そして評価ツールの結果を分析する前に、まず問題点を理解しなさい。 障害者がWebを使う様子の基本的なところを勉強しなさい。
5-3. 障害者を制作プロジェクトに加える (P63〜) †
背景知識をいくらか勉強した後、アクセシビリティ問題を理解する最もよい方法は、何人かの障害者と一緒に実際に働いて、彼らがどのようにWebを利用しているかや、支援技術を使う様子を学ぶことである。これにより、アクセシビリティ問題や解決方法の実地体験ができる。
(注)具体的な方法は本を参照してください。
5-4. アクセシビリティとユーザビリティの関係を理解する (P67〜) †
- ユーザビリティの問題
- 能力(障害のあるなし)に関わらず、全てのユーザーに同じ影響を与える。つまり、ユーザビリティ問題によって、障害のあるユーザーが障害を持たないユーザーより大きな不利を被ることはない。
- アクセシビリティの問題
- 障害者のWeb利用を妨げる。障害者が、障害を持たない人と比べて不利ならば、それはアクセシビリティ問題である。
- アクセシビリティとユーザビリティは重なる部分が多い。
- 両者の関係のニュアンスは、ほとんどのWeb制作(これらは、すべての人に対するアクセシビリティとユーザビリティの両方を目標とすべきである)に影響しない。
- いくつかの特殊な状況、たとえば法的な方針においては、両者を区別することが重要である。
- これは油断できない問題である。この問題を扱うときは注意すること。
アクセシビリティに取り組む基礎としてUCDとWCAGの両方を用いることで、技術レベルとユーザー・インターラクション・レベルの両方において、幅広い問題がよくカバーされるようになる。
5-5. ガイドラインの重要な役割を理解する (P69〜) †
- WCAGは、広範囲のアクセシビリティ問題をカバーしている包括的なガイドラインであり、可能な限り、あらゆる状況下でのあらゆる障害に言及している。
- たいていの場合、WCAGの文書群がアクセシビリティに関する情報の主要な参考文献となる。
- WCAGはアクセシビリティ解決の案内役であるべきであるが、アクセシビリティのゴールはガイドラインのリストにチェックマークをつけることではない。
- アクセシビリティのゴールは、Webサイトをアクセシブルにすることである。
- WCAGを用いることで全ての問題が取り上げられていることが保証され、
- 障害者が参加することで有効かつ効果的にそれらの問題が取り上げられる助けとなる。
6. Webアクセシビリティに関する有害な思い込み (P73〜) †
新しい技術によって、視覚的にも魅力があって複雑でダイナミックで、しかもアクセシブルなWebサイトを制作できるようになった。
6-1. 文字だけにすればよいという思い込み †
- 文字だけのバージョンの多くは、一部の障害者に対してアクセシブルではない。
- 文字だけのバージョン主バージョンに比べ、更新されないことが多い
文字だけのバージョンを作るより、主バージョンをアクセシブルにするべき
6-2. アクセシブルなサイトは冴えなくてつまらないという思い込み †
- 「アクセシブルなサイトは、視覚的にも技術的にも単調でつまらない」というのは時代遅れの思い込み
- Web制作者は、アクセシビリティに対する要求やガイドラインを、実際よりも制限が多いものだと誤解してきた。
- WCAG 1.0はJavaScriptの使用を禁じているとか、新しいウィンドウを開いてはいけないなどと誤解されてきた。
- 実際にWCAG 1.0が要求していることは、
- スクリプトが果たしている機能をスクリプトなしでも提供できるような代替手段(を用意すること)も必要
- 新しいウィンドウを開くときは、それをユーザーに伝えることが必要
- 障害者がWebを使う様子を最初に学んでいれば、ユーザーが気付かない場合、新しくウィンドウが開いたり(フォーカスが)別のウィンドウに変わったりすると問題が生じることがわかるだろう。
6-3. アクセシブルにするのは大変でお金がかかるという思い込み †
- 低コストでアクセシビリティを実現する方法
- アクセシビリティ対応をWeb制作プロジェクトの最初から開始する。
- 問題を理解するところから始める。その際、Webアクセシビリティに関連する複数の要素を考慮する。次に、“Understanding WCAG 2.0” (www.w3.org/TR/UNDERSTANDING-WCAG20/) を用いて、全ての問題をカバーする。
- 始めから終わりまで、障害者に参加してもらう。
- サイトの部分ごとと問題ごとに優先度を付ける。
6-4. Web制作者だけがアクセシビリティに責任があるという思い込み †
- 「4. 相互依存しているWebアクセシビリティの構成要素 (P53〜)」であるようにアクセシビリティの向上はコンテンツ制作者以外にも依存している。
6-5. 全盲の視覚障害者だけがアクセシビリティの対象であるという思い込み †
6-6. 評価ツールを使えばアクセシビリティを判断できて標準に適合しているかどうかもわかるという思い込み †
- ツールを人間による評価の代わりと考えるのではなく、ツールを人間が評価するときの補助と考えよう。
- 評価ツールで自動的にチェックできるポイントはツールを使い、ツールでは判断できないチェックポイントは人間がチェックする。
ツールが万能ではない例としてスペルチェッカーで考えてみると... スペルチェッカーは、本当は正しいのに間違っていると判断することもあるし、本当は間違っているのに 正しいと判断することもある。たとえば、”good test tool”とタイプするつもりで”good text tool”と タイプしてしまったら、スペルチェッカーはそれを間違いとは判断できないだろう。 同様に、評価ツールが見つけられないエラーがたくさんある。
6-7. ガイドラインはアクセシビリティに不十分だという思い込み †
7. ビジネス面から見た付加的な利点 (P83〜) †
7-1. 技術面の利点 †
- サイト制作と管理の時間短縮
- (ページの見せ方である)表現をスタイルシートで定義し、コンテンツの構造を(たとえばXHTMLで)正しくマークアップすることで、サイト全体の表現を変更する際に必要な作業時間と作業量が削減される。
- サーバーの負荷軽減
- ページごとに表現をマークアップする代わりにスタイルシートで表現を定義することや、画像文字の代わりに文字を使うことで、各ページのサイズが小さくなる。
- 相互運用性の向上
- Webアクセシビリティにより、Webコンテンツがいろいろな構成(さまざまなブラウザやOSや表示端末など)でレンダリング(表示)されたり利用されたりできるようになる。
- 先端技術への準備
7-2. 経済的な利点 †
- 検索エンジンへの最適化
- サイトをアクセシブルにすることで、SEO(Search Engine Optimization)の効果がかなり向上する。
- Webサイトの利用増
- Webサイトの利用が増えることによって、直接的および間接的に経済的な利益を得る可能性があることである。
- 直接的な経費削減
- アクセシビリティによりサイトの管理が長期的に減少すると、サイト管理のための人件費が減る。
- アクセシビリティがサーバーの負荷を減らせば、必要とされるサーバーの処理能力が削減でき、追加するはずだったサーバーの費用を節約できる。
- アクセシビリティによってコンテンツがさまざまなデバイスで利用できると、デバイスごとに異なったバージョンのサイトを多数作成する必要性が減る。
- アクセシビリティによってWebの先進技術を利用できて将来現れるWeb技術にも対応できると、新しい技術にアップグレードする費用が減る。
8. はじめよう (P88〜) †
- 価値ある挑戦
アクセシビリティを、競争相手に対して差別化をはかり、市場で会社の特徴を出すものと捉えたら!
- 相互依存しているWebアクセシビリティの構成要素がそれぞれに始めることで、全体が促進される
- Webブラウザ、メディアプレーヤ、支援技術、そのほかのユーザーエージェントがアクセシビリティ機能を備えていたら、ユーザーがそのアクセシビリティ機能を必要とする可能性は高くなり、Web制作者が自分たちのWebサイトでそのアクセシビリティ機能を提供する可能性も高くなるだろう。
- Web制作者があるアクセシビリティ機能を提供したいと考えたとき、彼らが使っているオーサリングツールがその作業を容易にしてくれることを要求する可能性も高くなるだろう。
- オーサリングツールが、簡単に使えるアクセシビリティ機能を持つようになったら、Web制作者はそれを使う可能性も高くなるだろう。
- アクセシビリティ機能が多くのWebサイトに実装されたら、 Web制作者とユーザーはブラウザなどのユーザーエージェントがその機能をサポートすることを要求する可能性も高くなるだろう。
アクセシビリティの伝道者になろう!