Webアクセシビリティ普及のため、『Webアクセシビリティ -標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践』（毎日コミュニケーションズ）の1章をWebで公開します。
（原著"Web Accessibility: Web Standards and Regulatory Compliance"の1章も"Understanding Web Accessibility"で公開されています。）
最終修正： 07/10/23 14:34 by 渡辺
『Webアクセシビリティ -標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践』
Shawn Lawton Henry 著 （渡辺隆行 訳）
Webによって、これまでになかった形で、障害者が情報にアクセスし利用することが可能になる。障害者が社会に参加する機会をWebはもたらしてくれる。これはWebなしではできなかったことだ。アクセシブルなWebサイトでは、障害者も普通のことができる：たとえば、子供はWebを使って勉強し、ティーンエイジャーはWebでチャットするなどしてデート相手といちゃつき、大人は生活費を稼ぎ、高齢者は孫の写真が載っているブログなどを読むことができる。Webによって障害者は、今までより多くのことを他人に頼らず自分でできるようになる。全盲の視覚障害者は、（コンピュータの文字を読み上げるスクリーンリーダーを使って）新聞を読める。書かれた情報を処理することが困難な認知障害者もスクリーンリーダーを使えば新聞を読める。聴覚障害者は最新のニュースを入手できる。これは今までならラジオやテレビを聞くことができる人にしかできなかったことである。盲ろう者も（点字ピンディスプレイを使って）最新ニュースを入手できる。手や足を動かすことができない四肢麻痺の障害者は、オンラインショッピングで食料品やガジェットやプレゼントを購入して配達してもらえる。話すことができない障害者は、ブログにコメントするなどしてオンラインの議論に参加できる。
しかし、Webがもたらすこうした可能性は、実際にはどのWebでも実現しているわけではない。問題は、ほとんどのWebサイトにはアクセシビリティの問題があり、障害者がWebを利用するのを困難あるいは不可能にしているところにある。ほとんどのWeb用ソフトウェアは障害者が十分利用できないので、障害者がWebページに書き込むことが困難あるいは不可能だ。これはとても重要な問題である。何百万もの人（訳注：この数字は米国の場合）が、Web利用が困難になるような障害を持っているのだ。
Webアクセシビリティとは、こうした問題を取り除き、障害者がWebを利用したりWebに書き込んだりできるようにすることである。皆さんが自分のWebサイトを改善してアクセシビリティ問題を取り除き、新たな問題を生じさせないようにする手始めとなるのが本章である。
Webアクセシビリティとは、基本的には、障害者がWebを利用できることである。もっと具体的にいうと、Webアクセシビリティとは、障害者がWebを知覚し、理解し、ナビゲーション（訳注：広義には、Webサイトのページ間やページ内を移動したり見てまわったりすること）し、インターラクション（訳注：Webに入力したり情報を受け取ったりしてWebを利用）できることである。
図1-1 ヘッドスティックを使ってコンピュータを利用している、Webアクセシビリティ講座の参加者
Webアクセシビリティは、Web利用に影響する全ての障害を含む。これらは、視覚障害、聴覚障害、肢体不自由、発話障害、認知障害、脳機能障害を含む。Web利用に影響を与える障害と、その障害によって影響を受ける人の実例の一部を下記に示す：
障害者が利用できることがWebアクセシビリティの最重要点であるが、Webアクセシビリティは、障害を持たない人にも利点がある。たとえば、Webアクセシビリティで最も重要な原則は、ユーザーによって異なるニーズに柔軟に適合するようにWebサイトをデザインすることである。この柔軟性により一般的なユーザビリティも向上し、障害を持たない人も各自の好みに応じてWebを利用できるようになる。たとえば、どのブラウザを使いたいかとか、キーボードショートカットを使うかどうかとかを選べるのである。Webアクセシビリティによって、本章の「ビジネス面から見た付加的な利点」の節で述べるような財政的や技術的な利点も、サイトを持っている組織にもたらされる。
障害を持つ人と持たない人に対してWebアクセシビリティがどのような利点があるかについて、本章にもっと多くの例がでてくる。
代替テキスト（alt-text）とよばれる、同等な情報を文字（テキスト）で代替する方法は、Webアクセシビリティのわかりやすい例である。Webページには画像が含まれることが多いが、画像を見ることができない人がいる。Web制作者が画像に等価代替情報を付与していれば、画像を見ることができない人も画像に含まれている情報を取得できる。等価代替情報は、画像が視覚的に示す機能的な情報と同じ情報を文字で示す。画像の代替テキストのマークアップは以下のように書く：
<img src="thunder.gif" alt="storms" />
（ところで、altは属性であって、タグではない。）
代替テキストは、以下のようなときに利用者に示される：
図1-2、1-3、1-4に示すように、代替テキストは、ブラウザの種類やブラウザの設定によって処理のされ方が異なる。図1-2は、マイクロソフト社のInternet Explorerで画像を表示した場合である。マウスを画像の上に持っていくと、代替テキスト（rain）がポップアップ表示される。
図1-2. 代替テキスト“rain”を表示している一般的なブラウザ
図1-3は、Operaというブラウザで、画像表示をオフにした状態で、同じページを表示したものである。代替テキストが与えられている画像は、代替テキストが表示されている。代替テキストが与えられていない場合（中央の画像）、 "IMAGE"と表示されている。
図1-3. 画像が非表示になっているので代替テキストが見える
図1-4は、IBM Home Page Reader（訳注：日本IBMより「ホームページ・リーダー 」が発売されている。）で、代替テキストがない画像を読むように設定した場合の表示を示す。Home Page Readerは音声ブラウザで、スクリーンリーダーと同じくWebページを読み上げる。一番下の欄の文章が、このブラウザを利用している人が聞いている文章を表示している。この画面をキャプチャしたとき、Home Page ReaderはOutlook（お天気概況）の行を読んでいる。代替テキストがない画像に対して、画像のファイル名を読んでいることに注意すること。（ブラウザや支援技術ごとに、欠けている代替テキストの処理方法は異なる。複数の処理方法が用意されていて利用者が選択できるものもある。）
図1-4. 代替テキストがないとき、画像のファイル名が読み上げられている。
これらは、画像ひとつだけに代替テキストがない例である。（残念ながらしばしばあるケースなのだが、）画像すべてに代替テキストがない場合を想像してほしい。そのような場合、画像を見ることができない人は、いつ晴れるのか、あるいは嵐になるのかといった予報がわからないだろう。しかし、もしすべての画像に代替テキストが付与されていたら、見ることができない人も見えている人と同じ情報が得られるだろう。
等価な情報を持つ代替テキストによって、Webページは画像が表示されてもされなくても、同じように役に立つ。
今日、多くのWebサイトがナビゲーションのために画像を使用しているが、そのようなサイトで代替テキストが欠けていると、そのサイトはまったく使えない。
代替テキストを付与することでアクセシビリティが向上するが、このとき、Webサイトの見た目は変わらないことに注意されたい。実際のところ、アクセシビリティを向上させる修正のほとんどは見えないところで機能し、障害を持たない人間がWebを使う際のユーザー体験（訳注：「ユーザー体験（user experience）」とは、Webなどの利用を通じて利用者が認知する使用感のこと。高機能であるとかアクセシブルであるとか以外に、たとえば「楽しい」体験を提供することに視点を当てた考え方。）に影響を与えない。
World Wide Web Consortium (W3C)のWeb Accessibility Initiative (WAI)は、アクセシビリティに欠けたサイトと、同じサイトのアクセシビリティ問題を取り除いたサイトの両方を掲載したデモサイトを準備中である。改良版のサイトでも（ブラウザの設定が一般的な場合）見かけは変わらない。最新版のデモを見るためには、W3C WAIのウェブサイトで、“before after demo”で検索すること。（たとえば、 www.google.com/search?q=site:www.w3.org/WAI+before+after+demo）
代替テキストは、障害者のアクセシビリティ向上以外にも役立つアクセシビリティ技術の例でもある。下記に、障害を持たない人々や（Webサイトを持つ）組織に代替テキストが役立つ場面を示す：
代替テキストの例は全盲の人々に焦点をあてているが、ほかの障害についても触れることが重要だ。下記に、そのほかのWebアクセシビリティ事例を、それがもたらすいくつかの利点とともに述べる。
図1-5 青色の箱で明確に区別されたナビゲーションエリアがあるWebサイト
前述した例はWebサイトにあてはまる。ブラウザに関連するアクセシビリティ問題の例は、キーボードでアクセスできるようにすることや、下記に示すオプションを含む：
オーサリングツール（Webサイト作成ソフトウェア）に関連するアクセシビリティ問題の例は、本章の後で述べる「相互依存しているWebアクセシビリティの構成要素」で紹介する。では、なぜアクセシビリティがそれほど大事なのかを見ていこう。
Webを利用する機会が、毎日の生活や社会の多くの領域に急速に広がっている。多くの国で、政府の情報やサービス、教育とトレーニング、商業、ニュース、職場のやりとり、市民参加、健康管理、レクリエーション、娯楽などでWebが利用される場面が増えている。今までの情報源がWebに置き換わりつつある場合もある。それゆえ、Webがアクセシブルであることが、公平なアクセスと機会均等を障害者に提供するために不可欠なのである。
Webは、これまでになかった形で、障害者が情報にアクセスする機会となる。印刷、音声、そして視覚的なメディアに存在したアクセシビリティ問題の多くは、Web技術を使えばより簡単に克服できる。たとえば、ある情報を得る第一の方法が図書館に行って紙に書かれた情報を読むことである場合、障害を持つ多くの人は、情報にアクセスする際（たとえば図書館に行く、情報源を物理的に得る、情報を読む際など）に重大な困難が生じる。（図書館にあるものと）同じ情報がアクセシブルな形式でWebで取得できる場合、多くの人にとって、その情報を取得することが著しく容易になる。Webのおかげで、Webがなければほとんど不可能なことを障害者ができるようになる場合もある。
Webは、これまでになかった人との関わりをもたらす機会にもなり、障害者がより積極的に社会参加できるようになる。
情報を共有することで人々がコミュニケーションできるような、共通した一つの情報空間が、Webが夢見る世界である。
— Tim Berners-Lee、ワールドワイド・ウェブの発明者、 “The World Wide Web: A very short personal history” (www.w3.org/People/Berners-Lee/ShortHistory)
もともとWebは、情報を共有するメディア、情報を読むだけでなく発信できるようなメディアとしてデザインされた。障害者がWebコンテンツを作成できるようにすることが、Webをアクセシブルにする際に重要な点である。それゆえ、本章の「相互依存しているWebアクセシビリティの構成要素」で述べるように、オーサリングツールもアクセシブルである必要がある。
Webをアクセシブルにすることで人々の暮らしが劇的に改善し、全体として、社会に利益をもたらす。
Webアクセシビリティが社会的な問題だということを理解すれば、組織、特に企業の社会的責任（CSR）に関与している組織にWebアクセシビリティを位置づけることができる。アクセシブルなWebサイトを提供することは、組織が機会均等を約束していることを示す一つの方法である。（そして、アクセシブルなWebサイトがあるだけで企業の社会的責任を示すことになり、アクセシブルでないWebサイトはそれが欠けていることを示す。）Webアクセシビリティが企業の社会的責任やデジタル・デバイドにどのように関連しているかに関するもっと多くの情報は、“Social Factors in Developing a Web Accessibility Business Case for Your Organization”(www.w3.org/WAI/bcase/soc)で入手できる。
企業の社会的責任やデジタルデバイドに関心がある組織ならば、アクセシビリティが下記の人々のアクセスをどのように改善するかを知りたいかもしれない：
下記に、これらのグループの人にどのような利点があるかを述べる。
統計や今後の傾向によると、将来、心身の機能が制限される人の数が増える。年をとるにつれ、ほとんどの人は視力、聴力、身体能力、そして認知能力の衰えを経験する。図1-6に、加齢とともに障害が増えていく様子を示す。図1-7に、高齢者増加の予想例を示す。（図1-6と1-7は、Trace R&D Centerの許可を得て掲載した。データの元は、http://trace.wisc.edu/docs/function-aging/ を参照のこと。）
図1-6 年齢ごとの障害
図1-7 高齢者人口増加の例
図1-7のグラフに示すように、「高齢」と考えられている人の数は劇的に増加しつつある。それゆえ、種々の障害が及ぼす影響を減らす技術に大きな関心が集まっている。高齢者は、インターネットを使っている多数の組織にとって、重要な市場である。
年をとるにつれ、高齢者の視力、聴力、器用さ、記憶能力が変化するのはよくあることだが、本人は自分が障害を持ったとは思っていないかもしれない。しかしながら、障害者にWebをアクセスできるようにするアクセシビリティ対策は、能力が衰えつつある高齢者にも役に立つ。たとえば、加齢が原因で視力が衰えた多くの人は、前景色と背景色の十分なコントラストの恩恵を受ける。高齢者の中には、手を細かく動かすことができなかったり、目と手がうまく協調して動かないために、マウスを使えない人もいる。より詳しい情報は、“Web Accessibility and Older People” (www.uiaccess.com/andaging.html）を参照のこと。
アクセシブルなWebサイトは、読み書きが不得手な人やそのWebサイトで使われている言語に堪能でない人の役に立つことができる。特に、認知障害者に対するWebアクセシビリティ上の配慮の多くは、Webで使われている言語をよく知らない人の役に立つ。さらに、アクセシブルなサイトはスクリーンリーダーで読み上げることができるので、書かれた文字を読むことはできないけれど話し言葉ならわかる人は、スクリーンリーダーで読み上げたWebサイトを音声で聞くことができる。
Webアクセシビリティのいくつかは、ネットワーク接続の帯域（バンド幅）が狭い人にも役に立つ。帯域が狭い原因は、接続技術（たとえば携帯電話やPDA）、場所（たとえば地方）、あるいは経済事情（高速な接続は高価）かもしれない。古い技術の一部はWebページのロードがとても遅く、新しいサイトで使われている機能をサポートしていない。これらは、いくつかの途上国や先進国の一部の地域で普通に見られる問題である。
ネットワーク接続の帯域が狭い人や古い技術を使っている人には、次に示すような利点がある：
社会経済的な理由のため、Webを利用する機会がほとんどない人もいる。初心者やあまり使わないユーザーには、下記のようなアクセシビリティへの配慮が役に立つ：
このほかの例は、“Social Factors in Developing a Web Accessibility Business Case for Your Organization” (www.w3.org/WAI/bcase/soc)の“Web Accessibility Benefits People With and Without Disabilities”節を参照のこと。
Webアクセシビリティは多くの場合、Webコンテンツ制作者によってなされる仕事であるとされてきた。こうした見方は、ブラウザ、支援技術、オーサリング・ツールといった、Web制作とインターラクションに関わるほかの構成要素との重要な相互依存性を見逃している。
これらの構成要素間の相互依存性を理解すれば、下記のことをより適切に遂行できる：
Webが障害者にアクセシブルになるためには、Web制作とインターラクションに関する構成要素すべてが協調することが絶対に必要である。これらの構成要素がそれぞれの役割を果たさなかったら、それ以外の要素に対する負担が大きくなり、Webのアクセシビリティは低下する。たとえば、ブラウザによって機能が異なるためにWebコンテンツの制作者は余計な作業をしなければならないため、ある推計によると、「全Webサイト制作において、少なくとも25%のコスト増加」を招いている。（Web Standards Project, “WaSP: Fighting for Standards,” http://webstandards.org/about/mission/).）
ブラウザ、オーサリングツール、そのほかの構成要素が改善されれば、アクセシビリティ向上に費やす努力が全体として大幅に減り、Webアクセシビリティが大幅に向上するだろう。たとえば、ほんの数百程度のオーサリングツールが十分なアクセシビリティ支援機能を持てば、何百万ものWebコンテンツ制作者の測り知れないほどのアクセシビリティ向上努力を減らすことができ、もっと多くのアクセシブルなWebサイトを生み出すことができるだろう。（オーサリングツールが自動的にすべてのアクセシビリティ問題の面倒を見ることができるわけではない。Webサイト制作者がアクセシビリティ向上のためにしなければならないことは常にある。しかし、ツールがアクセシビリティ向上を支援・促進し、もっと容易に取り組めるようにする方法がたくさんある。）
構成要素を考える方法のひとつは、技術と人間の二つのグループに分けることである。下記が技術的な構成要素と考えられる：
Webアクセシビリティの、人間に関する構成要素には下記がある：
図 1-8. Webアクセシビリティの構成要素
図1-8に、Webアクセシビリティの基本構成要素の関係を示す。コンテンツ制作者は、一般的に、オーサリングツールや評価ツールを使って、技術仕様に準拠したコンテンツを作成する。ユーザーは、ウェブブラウザや時には支援技術を使ってコンテンツを取得し利用する。ツールの開発者は、ユーザーニーズ（というか、実際は市場の要求）に基づいて、彼らが開発するオーサリングツールや評価ツールやユーザーエージェントに機能や特徴を盛り込む。
図1-8、1-10，1-11、1-12は、Michael Duffy, DUFFCOが描いたものを基にしている。www.w3.org/WAI/intro/components を参照。©W3C.
画像に代替テキストを付与してそれを用いる場合を例にとって、Webをアクセシブルにするために構成要素がどのように協調しなければならないかを見てみよう。図1-9に、各構成要素の役割を図示する。
図1-9 代替テキストに対する構成要素の役割
技術的な構成要素は、代替テキストに対して下記の役割がある：
技術仕様： 代替テキストをマークアップするための標準を提供する。たとえば、HTML 4.01の場合、コンテンツに画像を埋め込むためのimg要素には、画像の代替テキストを示すalt属性がある。World Wide Web Consortium （W3C）のHTML 4.01の仕様（www.w3.org/TR/html4/struct/objects.html#adef-alt）は、alt属性について下記のように述べている：
画像、フォーム、アプレットを表示できないユーザーエージェントのために、この属性で代替テキストを指定する。代替テキストの言語はlang属性で指定される。
代替テキストを指定すると、グラフィック表示端末がないユーザーや、フォームをサポートしないブラウザを用いているユーザーや、視覚障害があるユーザーや、音声合成装置を用いているユーザーや、画像を表示しないように自分のブラウザを設定しているユーザーなどの助けとなる。
alt属性は、IMG要素とAREA要素に必ず指定しなければいけない。
WAI（Web Accessibility Initiative）のガイドラインは、いろいろな技術構成要素に、アクセシビリティのために代替テキストを実装する方法を明らかにしている。このWAIのガイドラインは、本章の「構成要素をまとめる」の節で説明する。
人間に関する構成要素は、代替テキストに対して下記の役割がある：
構成要素間の相互依存性は、アクセシビリティ機能を先に実装するのはどちらかという「卵が先か鶏が先か」問題を今まで引き起こしてきた。図1-10に、明確な始まりがない実装サイクルを図示する。
図1-10 アクセシビリティ実装サイクル
ある構成要素がアクセシビリティ機能を欠いている場合、ほかの構成要素がその機能を実装してもユーザーのアクセシビリティを高める結果につながらないなら、ほかの構成要素は、そのアクセシビリティ機能を実装しようとは思わない。たとえば、ほとんどのブラウザや支援技術が一貫して実装しないアクセシビリティ機能、または自分が使っているオーサリングツールで使うのが難しいようなアクセシビリティ機能に、コンテンツ制作者は対応したがらないだろう。同様に、ブラウザの開発者は、ほとんどのコンテンツで用いられないようなアクセシビリティ機能に対応しようという気にはならないだろう。そして、オーサリングツールは、コンテンツ制作者（つまり、オーサリングツールの利用者）が必要としないなら、アクセシビリティ支援機能を追加する気にはほとんどならない。その結果、まったく実装されないアクセシビリティ機能もあれば、すべての構成要素に効果的に実装されるまでに長い時間がかかる機能もある。
ひとつの構成要素にアクセシビリティ機能が有効に実装されると、ほかの構成要素がそれらのアクセシビリティ機能を実装する可能性が高くなる。本章の終わりに述べる「はじめよう」の節で、構成要素全体でアクセシビリティ機能の実装を促進する方法について取り上げる。
技術仕様も、アクセシビリティを念頭において設計されなければならない。そうでなければ、その技術は、必須のアクセシビリティ機能をサポートしないかもしれない。実際のところ、多くのWeb技術が、アクセシビリティに対応することなく開発されてきた。しかし、主に顧客の要求により、PDF（Portable Document Format）やFlashなどの技術は、アクセシビリティ対応を進めてきている。
Web技術に関連する多くの組織が、いまや、明確にアクセシビリティに注目している。W3CのProtocols and Formats ワーキンググループ (PFWG, www.w3.org/WAI/PF/)は、W3Cのワーキンググループと協力して、W3Cが策定する技術仕様のアクセシビリティ対応度を向上させている。PFWGは下記を保証することが仕事である：
ある技術要素のアクセシビリティ対応が弱い場合、ときには、ほかの構成要素が回避策をとることでその弱い部分を補うことができるが、それには、最初の制作時と長期に渡るメインテナンスの両方で、余分な努力が必要になる。図1-11に、ツールに欠けているアクセシビリティ機能を補償する様子を示す。
図1-11 アクセシビリティ対応機能が欠けている状態を補償する
オーサリングツールやユーザーエージェントがアクセシビリティ機能を持たない場合、コンテンツ制作者が、次善の策として、余分な作業をして欠けている部分を補うことができる場合がある。たとえば、オーサリングツールがアクセシブルなマークアップをしない場合、コンテンツ制作者が自分で直接(X)HTMLファイルに書き込んでマークアップできる。ユーザーエージェントがコンテンツ構造に沿ってナビゲーションする機能を提供しない場合、コンテンツ制作者は、Webコンテンツにナビゲーション機能を追加できる。
時にはユーザーが、ブラウザやコンテンツに欠けているアクセシビリティを、同じWebページであっても、違うユーザーエージェントや支援技術を組み合わせて用いることにより、補うことができる。残念ながら、多くのアクセシビリティ問題ではユーザーが取れる回避策がなく、コンテンツはアクセスできない。
W3C WAI（www.w3.org/WAI/）は、国際的なWebアクセシビリティ取り組みの協調を進め、技術面と人間面の構成要素に関して考慮すべき点をひとつにまとめている。図1-12に、WAIの取り組みがWebアクセシビリティの構成要素にどのように対応するかを示す。WAIは下記の組織や人々と共に活動している：
図1-12 Webアクセシビリティの各構成要素をカバーするW3C WAIのアクセシビリティガイドライン
アクセシビリティ・ガイドラインを策定するために協調したこうした努力によって、各構成要素がうまく協調して機能するためのフレームワークが提供される。このフレームワークは、各構成要素がアクセシビリティのために何をする必要があるかを明確にする。このフレームワークにより、各構成要素が他の構成要素に何を期待できるかが明らかになるので、卵が先か鶏が先か問題の解決にも役立つ。
ATAGの一連の文書は、オーサリングツールを障害者にもアクセシブルにする方法を説明し、Web制作者がオーサリングツールを用いてWCAGに適合したWebコンテンツを作成するのを手助けをする方法を明確にしている。プロンプト、警告、テンプレート、そのほかの機能によって、オーサリングツールは、コンテンツ制作者がアクセシブルなWebコンテンツを作ることを可能にし、促進し、支援する。前述したように、障害を持つ人もまた、コンテンツ作成にかかわれるようにすべきである。それゆえ、オーサリングツール自身もアクセシブルでなければならない。
ATAGは主にオーサリングツールの開発者に向けて書かれた文書であるが、ATAGとその関連文書は、政策立案者や経営者などのほかのいろいろな人の要求にも合うようになっている。たとえば下記の人々がATAGを使う可能性がある：
ATAG 1.0 (www.w3.org/TR/ATAG10) は2000年2月にW3Cの勧告（Recommendation）として公開された。ATAG 2.0 (www.w3.org/TR/ATAG20/) が現在制作中であり、ATAG 1.0に見られた小さな問題点を説明し、ほかのガイドラインへの参照を更新した。
W3Cの勧告とは、広範囲にわたって意見が一致した後、W3Cのメンバーとディレクターの承認を得た仕様またはガイドラインのセットのことである。W3Cは、W3Cの勧告が広く用いられることを推奨している。W3Cの勧告は、ほかの組織が発行する標準（Standards）と似ていることに注意されたい。W3Cの技術レポート策定プロセスの詳細については、www.w3.org/2005/10/Process-20051014/tr.html#RecsW3C を参照のこと。
WCAGの文書は、障害者に対してWebコンテンツをアクセシブルにする方法を説明している。WCAGはコンテンツ制作者に対して書かれているが、それ以外にも下記の人々を対象にしている：
WCAG 1.0 （www.w3.org/TR/WCAG10/）は1999年5月にW3Cの勧告として公開された。 WCAG 2.0（www.w3.org/TR/WCAG20/）の文書を現在策定中で、より先進的なWeb技術に適用でき、より簡単に利用したり理解したりでき、より正確に（ガイドラインへの適合性を）テストできることを目指している。
WCAGの最新情報は、“Web Content Accessibility Guidelines (WCAG) Overview” (www.w3.org/WAI/intro/wcag)及び “Overview of WCAG 2.0 Documents” (www.w3.org/WAI/intro/wcag20) を参照のこと。
UAAGの文書は、ユーザーエージェント（ウェブブラウザ、メディアプレーヤ、支援技術）を障害者にアクセシブルにする方法と、特にWebコンテンツのアクセシビリティを向上する方法を説明している。たとえば、UAAGは、ブラウザがコンテンツを表示する方法に関して、ユーザーが制御権を持つべきであり、ブラウザは標準的なプログラミング・インターフェースを用いて支援技術とインターラクションできるようにすべきであると定めている。
UAAGは、主としてユーザーエージェントの開発者向けである。UAAGと補足文書は、政策立案者や管理者など他のいろいろな利用者のニーズにも合うように書かれている。たとえば下記の人々がUAAGを使用するだろう：
UAAG 1.0 （www.w3.org/TR/UAAG10/）は2002年12月にW3Cの勧告として公開された。
障害者に対するアクセシビリティの重要性や障害者以外に対するアクセシビリティの利点が、組織や個人がアクセシビリティに取り組む方法に考慮されることは滅多にない。Webプロジェクトの多くは、アクセシビリティ・ガイドラインや評価テストの報告を制作サイクルに組み込むのが遅い。ただそれだけに注目するのではなく、アクセシビリティ向上作業の中心に置くべきガイドラインはある。本節は、別の取り組み方を提案する。
アクセシビリティ対応はWebプロジェクトの最後まで放置されることが多い。プロジェクトの最後に対応したのでは、より費用がかかり、重荷となってプロジェクトを挫折させる。たとえば、プロジェクトの最後までアクセシビリティへの取り組みを引き伸ばしていると、Web制作に使っているオーサリングツールやCMSによってアクセシビリティ問題が複雑になってしまうことに気づくだろう。一方、アクセシビリティ支援機能に優れたツールを用いていれば、アクセシブルなサイトをデザインすることがもっと容易になるだろう。あるいは、単純な間違いをひとつ犯しただけで、その影響がWebサイト全体に広がっていくことに気づくかもしれない。プロジェクトのはじめから正しくアクセシビリティに取り組んでいれば、あまり努力する必要はないだろう。（あとから）前の段階に戻って修正すると、余分な手間がかなり増える。
Webサイトを制作あるいは改訂する際、最初からアクセシビリティを考慮すれば、プロジェクトの最後に考慮するよりも、はるかに簡単で、より有効的で、費用もかからない。アクセシビリティが最初から考慮されていれば、Webサイト制作の全コストの数パーセントですむことが多い。（すでにWebサイトを持っていて、それをアクセシビリティに対応させようと考えている場合でも、下記に述べるアドバイスの大部分は有効である。そして、本章で述べる「既存サイトのアクセシビリティ問題」の節でも、別の手引きを示す。）
アクセシビリティへの配慮を最終的にはプロジェクトに取り入れたとしても、ほとんどの場合、チェックリストを用いてチェックするだけになる。彼らは標準（standard）に飛びつき、評価ツールを使ってテストし、そして完全に困惑する。ある種の言い方をすれば、彼らは「消防用ホースから水を飲む」ような方法で始めてしまい、「ヘッドライトに照らされた鹿」のように立ちすくんでしまう。
この方法には、（ずぶ濡れになってトラックに轢かれそうな鹿みたいになっていることはさておき）問題もある。アクセシビリティ標準だけを用いると、プロジェクト達成には時間がかかり、不満が増し、そして有効な結果をあまり生まない。
例を示そう。（スクリーンリーダーを使うのがどのようなものか知らない）Web制作者が「すべての非テキストには代替テキストを提供しなければならない。」というガイドラインを読んだとする。このガイドラインを満たすために、Web制作者は次のような代替テキストを提供する：「この画像は、濃い緑色の虫メガネの線描です。これをクリックすると、このAcme会社のWebサイトの検索ページにジャンプします。」このWeb制作者は、このように冗長な代替テキストをWebサイトにある何百もの異なる画像につけて回る。彼は、まったく有効でない解決策のために、時間と努力を完全に無駄にしてしまった。検索ページにジャンプする画像には、「検索」という代替テキストをつければ十分である。このWeb制作者がサイト全体につけた過剰に冗長な説明は、代替テキストを必要としている人にとってはまったく我慢しがたいものだろう。なぜならば、彼らはこれらの無関係な情報すべてを読まなければならないからだ。
私は、実際にあった間違ったアクセシビリティ配慮を収集している。いくつかは、次に示す装飾画像のマークアップのようにおもしろい：<img src=“blue-space.gif” alt=“ ”>。しかし間違った例のほとんどは、おもしろいというよりはがっくりくる。たとえば、たくさんの大きなデータ・テーブルのすべてのセルに手で入力した制作者もいた：
<td row=“1” col=“1”>...
<td row=“1” col=“2”>...
...
<td row=“57” col=“15”>...
Web制作者が多くの時間を費やしているのに、アクセシビリティの基礎知識がないために、そして障害者がWebを利用する様子を知らないというそれだけの理由で、そうした努力が有効でないのは残念なことである。
アクセシビリティの効果がない努力に時間を費やさずにすむもっとよい方法がある。
ガイドラインに飛びつく前に、そして評価ツールの結果を分析する前に、まず問題点を理解しなさい。障害者がWebを使う様子の基本的なところを勉強しなさい。
アクセシビリティ問題を理解することに役立つ無料の情報源をたくさん見つけることができる。たとえば、“How People with Disabilities Use the Web” (www.w3.org/WAI/EO/Drafts/PWD-Use-Web/)は、さまざまな障害がWeb利用に及ぼす影響を詳細に述べ、障害者がどうWebを利用するかが書いてある。また、“Introduction to the Screen Reader” (www.doit.wisc.edu/accessibility/video/intro.asp)は、短いビデオである。金銭的に余裕がある組織ならば、Webアクセシビリティのコンサルタントか、さまざまな障害者がWebを利用する様子を実際に経験している人間を雇おうと思うかもしれない。
背景知識をいくらか勉強した後、アクセシビリティ問題を理解する最もよい方法は、何人かの障害者と一緒に実際に働いて、彼らがどのようにWebを利用しているかや、支援技術を使う様子を学ぶことである。これにより、アクセシビリティ問題や解決方法の実地体験ができる。
障害者がWeb制作プロジェクトに参加することはやっかいな提案に思えるかもしれない。でも、もう少し付き合って欲しい。本章でたくさんの手本を示すし、さらに知るための情報源も示す。小規模なプロジェクトのいくつかでは問題外かもしれないが、もし可能ならば、やってみる価値はかなりある。
障害者がWeb制作に参加できるよう少し努力するだけで、下記のようなたくさんの利点が生まれる：
障害者を2,3人見つけるところからはじめなさい。“Recruiting Participants with Disabilities” (www.uiaccess.com/accessucd/ut_plan.html#recruiting)に、障害者を探すときにコンタクトすべき場所のリストがある。（訳注：このサイトは、実際には、具体的なコンタクト先ではなく、一般的な考慮事項が書いてあるので、日本でも役立つ。）あなたのサイトの「ターゲットユーザー」に近い人を探しなさい。たとえば、大学ローンの申し込みに関するサイトならば、80歳ではなくて18歳の障害者を探すべきである。
Webの利用経験が多い人を探しなさい。テストの後半では何人かの初心者を含めたいと思うかもしれないが、今は、あなたにうまく教えることができる人を必要としている。“Involving Users in Web Accessibility Evaluation” (www.w3.org/WAI/eval/users)の “Users' Experience Interacting with the Web”セクションに、障害者の支援技術使用経験に関して考慮すべき事項について少し書かれている。（プロジェクトの最初からユーザーに参加してもらう場合も、プロジェクトの後半に評価のために参加してもらう場合も、両方の場合に、この話は当てはまる。）
違う障害を持つ二人以上の障害者を含めなさい。障害者も他の人たちと同様に多様であり、様々な経験や期待や好みを持っている。彼らは、様々な利用技術や適応戦略や支援技術の組み合わせを用いる。人間には、視覚、聴覚、身体、発話、認知、脳機能などのいろいろな障害があり、多くの人が重複障害を持つ。
一つの障害だけでもかなりのバリエーションがある。たとえば、「視覚障害」には、生まれつき全盲の人、加齢に伴う病気によって中心視が見えなくなるロービジョンの人、病気や怪我のために一時的にぼんやりとしか見えなくなる人、などが含まれる。よくある間違いは、全盲の人が視覚障害者全体を表していると考えることである。
図1-13、1-14、1-15に、その状態が「ロービジョン」という広いカテゴリーに含まれる二人の障害者の全く異なった必要性を示す。図1-13は、（Webブラウザの）デフォルトの設定で見た通常のWebページである。図1-14は、視野がぼやける（poor visual acuity）障害者の利用例で、ページを読むことができるように文字や画像を大きくすることを必要としている。彼女は、ブラウザのウィンドウも最大化して、Webページが画面幅一杯に表示されて、図1-14に示すように一行の長さが短すぎることがないようにしたい。図1-15は、求心性視野狭窄があるが視力はよい人の利用例である。彼は、文字や画像を小さくして、一度にたくさん見えるようにしている。彼にとっては、一行が短い方が読みやすい。そこで彼は、ウィンドウの幅を狭くして、（図1-15に示すような水平スクロール・バーが必要になるよりも）文字が短い幅に収まるようにしたい。
図1-13 通常のWebサイト
図1-14 視野がぼやける障害者によって、文字サイズなどを大きくして表示したサイト。大きく表示される文字もあれば大きく表示されない文字もあることに注意されたい。また、（文字を大きくしても）本文が表示されている部分の幅は広がらないので、一行の長さが短くなっていることに注意されたい。
図1-15 求心性視野狭窄がある利用者によって、文字サイズなどを小さくして表示したサイト。左側にユーザーが実際に見ている範囲を示す。右側にページ全体の様子を示すが、水平スクロール・バーがあることに注意されたい。
ユーザーのニーズにはこのような多様性があるので、理想的には、異なった障害と特徴を持った何名かのユーザーをプロジェクトに加えることが望ましい。実際には、時間とお金の制約により、人数は限られるだろう。それでよい。なぜならば、障害のこの多様性をカバーする資料（本章の「ガイドラインの重要な役割を理解する」の節で説明するWCAG）があるからだ。どの障害を持つ人をリクルートすべきかについてのいくつかのアドバイスについては、Determining Participant Characteristics” (www.uiaccess.com/accessucd/ut_plan.html#characteristics) を参照のこと。これはユーザビリティ・テスト用に書かれているが、いくつかの情報はプロジェクト初期のユーザー参加にも適用できる。
プロジェクトに参加する障害者の人数を決める際、障害者は一般的なユーザビリティ問題の影響も受けることを考慮しなさい。たとえば、障害者にユーザビリティ・テストを実施すると、アクセシビリティ問題と、（障害を持たないユーザーを含んだ）全ての人に影響を与える一般的なユーザビリティ問題の両方に気付くだろう。障害者が一般的なユーザビリティ問題の影響も受けることを知ることによって、プロジェクトを通して障害者の参加を求めるための予算と時間を手に入れやすくなる。
障害者をリクルートして一緒に働こうと計画するとき、その人が特定の支援技術を用いているなら、一緒に働くときにその支援技術が使えるように準備する必要があることを覚えておきなさい。もし彼女がWebサイトの制作現場に持ち込めるラップトップコンピュータを持っているなら、おそらくそれが一番良い。そうでないなら、現場に支援技術を用意する必要があるかもしれない。しかしながら、支援技術の多くはとても高価でありデモ版は限られている。それに、自分専用にカスタマイズしているかもしれず、あなたの設定では再現することが難しいかもしれない。上級ユーザーの場合、これが問題となる可能性は低い。時には、ユーザーである障害者に現場に来てもらうのではなく、ユーザーの家や職場に出向くことが最善かもしれない。この方法の欠点は、障害者が利用するところを実際に経験できるプロジェクトチームのメンバーの数が少なくなることだ。
障害者と仕事を始める用意ができたら、障害者がコンピュータや支援技術を自分の好みに調整する時間を作ること。次に、彼が利用するうえで問題がないWebサイトを見せてもらうところからはじめなさい。これを最初にするのは大事なことである。これで、うまくいくときはどういう感じかがあなたにわかり、彼もセットアップが期待通りになっていることを確認できる。どういう風に動作しているのかを学ぶためにたくさん質問しなさい。次に、彼に、うまくいかない例を見せてもらうことができる。どんな問題もおそらくWebサイトのマークアップやデザインが原因であることを頭に入れておきなさい。しかし、ユーザーが初心者の場合、支援技術をWebサイトで活用する方法を知らない可能性がある。修正中のサイトがすでにあるならば、そのサイト、特に修正中の箇所を使ってもらいなさい。もし、すでに改善案が頭の中にあるならば、類似したデザイン、たとえばナビゲーション方法が同じタイプ、のサイトを使うように頼みなさい。
あらかじめユーザーに、何をして欲しいか伝えておきなさい。ユーザーに頼んで、よいサイトと悪いサイトをあなたに見せる準備をしてもらいなさい。彼らに、どのサイトを見せて欲しいか、何に集中して欲しいか、たとえばナビゲーションとかデータテーブルとかフォームとかを伝えなさい。彼らがよく準備してくるほど、全員がより快適にテストでき、あなたはそこからより多くの成果を得ることができるだろう。
ユーザーが参加するこの時間を最大限に活かすために、Webプロジェクトのメンバー数人、コードを書くことになるWeb制作者や予算を承認する管理者なども参加させなさい。テストの様子をビデオテープに録画して、テストに参加できなかったメンバーに見てもらうことを考えなさい。もちろん、ビデオ録画に同意してくれるユーザーを見つける必要がある。多数の参加者がアクセシビリティを学ぶことを歓迎するユーザーもいれば、多人数で見れれるのを嫌がるユーザーもいる。
あなたがアクセシビリティ問題を理解するのを助けるためにユーザーをプロジェクトの早期に参加させることに加えて、既存サイトのアクセシビリティ問題の解決法を開発したり新規サイトのプロトタイプを制作したりする際、ユーザーをプロジェクトの終わりまで通して参加させなさい。（フォーム、ナビゲーションの枠組み、ページレイアウトのテンプレート、あるいはこれらの複数に関係しているものすべての）原案があるときは、障害者にテストしてもらいなさい。そうすることで、これらの原案が実際のサイトのあちらこちらで使用される前に、直さなければいけない問題点を修正しておくことができる。
ひとつだけ注意しておきたい。一人の障害者の意見をすべての障害者に適用できると考えてはいけない。ある一人の障害者が、同じ障害を持つほかの障害者がどのようにWebを使っているかを必ずしも知っているわけではない。また彼は、ほかのアクセシビリティ問題について有効な指導ができるほど、ほかの障害について十分知っているわけでもない。
障害者の参加に関するより多くの情報は、“Usability Testing for Accessibility” (www.uiaccess.com/accessucd/ut.html)にいろいろ書かれている。このサイトは、フォーマル・ユーザビリティテスト用に書かれているので、プロジェクト制作の初期に行うインフォーマルな作業には適さないものもあるかもしれない。ほとんどの情報、たとえばテスト設備がアクセシブルであるようにするとか、テストルームのセッティングとか、障害者とのコミュニケーションの仕方とかは実際に適用できる。あらゆることを正しくやろうと心配しなくてよい。礼儀をわきまえて接している限り、障害者のほとんどはあなたの努力を認めて、へまをしても面倒くさがったりしない。
ユーザーが有効に参加する方法についてもっと学ぶには、ユーザビリティ分野とユーザー中心設計（UCD, User Centered Design）に目を転じよう。なお、これらについて、次節に述べる。
UCD（ユーザー中心設計）は、ユーザー・インターフェースのデザイン・プロセスであり、ユーザビリティのゴール、ユーザーの特性、環境、タスク、Webサイトなどのインターフェースのデザインにおけるワークフローに焦点をあてる。UCDは、分析、デザイン、評価において、明確に定義された手法と技術の流れに沿って行われる。UCDプロセスは反復プロセスであり、プロジェクトの第一段階から実装の終わりまで、デザインと評価のステップが組み込まれている。アクセシブルなデザインの技術はこのUCDのプロセスとよく一致する。少しばかり追加と改造をするだけで、デザインチームは、アクセシビリティ面でのデザインに焦点を当ててUCDの実践方法を使うことができる。
アクセシブルなデザインとUCDとユーザビリティは重なるところが多いが、アクセシビリティとユーザビリティの関係は明確ではない。
まず、ユーザビリティ（の定義から始めよう。国際標準化機構（International Organization for Standardization、以後 ISO）はユーザビリティを、「ある製品が、指定された利用者によって、指定された利用の状況下で、指定された目標を達成するために用いられる際の有効さ、効率及び満足度の度合い」と定義している（ISO 9241-11：人間工学－視覚表示装置を用いるオフィス作業－使用性（ユーザビリティ）の手引き）（訳注：ISO 9241-11は JIS Z 8521として翻訳されている。）この定義を用いると、アクセシビリティは下記に焦点を当てている：
もっと簡単に言うと、ユーザビリティとは、Webサイトを有効に効率的に満足させるようにデザインすることである。アクセシビリティも、Webサイトが、より多くの人々、特に障害者にとって、支援技術を含むより多くの利用状況で、有効で効率的で満足がいくようにすることである。
定義を調べるのは簡単なことだ。しかし実際には、ユーザビリティとアクセシビリティの関係はもっと複雑だ。ある人々にとっては、熱い議論がされている話題である。ほとんどの人々にとっては、まったく問題ではない。Webサイトをデザインするとき、ユーザビリティとアクセシビリティを区別するのは、ほとんどの場合有益ではない。
しかしながら、アクセシビリティとユーザビリティを区別することが重要な時もある。たとえば、障害者に対する差別を調べるときや、アクセシビリティに特化した標準を定めるときなどである。両者の区別は、WCAGなどのアクセシビリティ・スタンダード（標準）を定めるときに、依然としてよく議論となる。アクセシビリティ・スタンダードに何を含めるべきか、何が純粋なユーザビリティ問題でありアクセシビリティ・スタンダードに含めるべきでないかは明確でない。
この二つの相違を調べる方法のひとつは、インターフェースの問題を下記のように分類することである：
ユーザビリティとアクセシビリティの差は、認知障害や言語障害を考慮する際に特に難しくなる。認知障害者のアクセシビリティ向上のためのガイドラインの多くは、一般的なユーザビリティのガイドラインと同じである。両者の区別は、下記のような事実により、さらに曖昧になる。つまり、障害者向けの機能は障害を持たない人にも利益になる。なぜなら、そういう人も一時的な制約（つまり、周りの状況や環境や装置により生じる障害。たとえば、片手に寝ている赤ちゃんを抱いていて、もう一方の手で明るい日差しの下で携帯電話を使用しているようなとき）を被るかもしれないから。また、アクセシビリティに対処することで一般的なユーザビリティも向上するからだ。
区別を曖昧にする他の点は、「使いやすいアクセシビリティ（usable accessibility）」、アクセシビリティを解決する方法がいかに使いやすいか、ということである。たとえば、あるサイトがナビゲーションに画像を用いていて代替テキストがなかったら、そのサイトは明らかにアクセシブルではない。もしそのサイトにいらいらするほど冗長な代替テキスト（たとえば。「この画像は、濃い緑色の虫メガネの線描です。これをクリックすると、…」）が付いていたら、代替テキストが付いているので技術的にはアクセシブルだが、代替テキストに書かれた内容がとても悪いので、代替テキストに頼っている人にとっては、サイトのユーザビリティはひどいものだと言うことができる。（このようなことは、あなたがアクセシビリティ問題を理解していて、障害者がプロジェクトに参加していれば生じないだろう。）
人々がユーザビリティとアクセシビリティの区別に関する論争を理解していない場合、問題が生じる可能性がある。たとえば、ある調査報告に、サイトはアクセシブルではなかったけれども、判明した問題は（障害者だけにではなくて、すべてのユーザーに影響を与える）一般的なユーザビリティ問題であると書いてあったとき、その調査はアクセシビリティ・ガイドラインに関して間違った結論を伝える可能性がある。アクセシビリティとユーザビリティに関して学術的に議論するときは、この問題の複雑さを理解していない人々に注意深く提示しないと、アクセシビリティ問題の理解を妨げてしまう可能性がある。
アクセシビリティとユーザビリティの関係の問題の本質は、以下のようにまとめることができる：
アクセシビリティに取り組む基礎としてUCDとWCAGの両方を用いることで、技術レベルとユーザー・インターラクション・レベルの両方において、幅広い問題がよくカバーされるようになる。必要なもののほとんどをWCAGから得ることができる。ユーザーに参加してもらい、UCDの方針を使うことによって、より簡単にうまくいく。
これに関するより詳細な情報は、“The Relationship Between Accessibility and Usability” (www.uiaccess.com/andusability.html)と “Accessibility in the User-Centered Design Process” (www.uiaccess.com/accessucd/)を参照のこと。
では、もっと明確な話題である、Web制作プロジェクトにおけるガイドラインの役割に移ろう。本章では、障害者がWeb制作プロジェクトに参加することについていろいろ述べてきた。障害者の参加にはたくさんの利点があるが、それだけではアクセシブルなWebサイトを制作できない。なぜならば、規模が大きなプロジェクトでさえ、すべての問題を十分カバーできるほど、多様な障害や（読みやすいように大きな文字で印刷するなどの）適応戦略や支援技術を網羅できないからだ。WCAGはこの多様性をカバーしている。WCAGは、世界中の、たくさんの異なったバックグラウンドや経験、視点を持った人々からの貢献により策定された。
WCAGは、広範囲のアクセシビリティ問題をカバーしている包括的なガイドラインであり、可能な限り、あらゆる状況下でのあらゆる障害に言及している。
WCAGの他にもWebアクセシビリティのガイドラインやスタンダードがある。おそらく最もよく知られているのは米国のリハビリテーション法508条であろう。しかしながら、508条のWebに関する規定はWCAGのほんの一部しかカバーしていないこと、そして、508条に適合したWebサイトであっても一部の障害者には完全にアクセシブルであるとはいえないかもしれないことに注意されたい。（訳注：リハビリテーション法508条は、翻訳時点において米国の電気通信・電子情報技術諮問委員会（Telecommunication and Electronic and Information Technology Advisory Committee, TEITAC）で見直し作業が行われており、近い将来改定される予定である。）
WCAG 1.0は1999年に発行され、今でも、安定して参照できる正式勧告である。WCAG 2.0が策定中であり、完成に近づいている。2006年4月にWAIは、ワーキングドラフト最終版としてWCAG 2.0 (www.w3.org/TR/WCAG20/) と、WCAG 2.0を強力に補強する文書である“Understanding WCAG 2.0” (www.w3.org/TR/UNDERSTANDING-WCAG20/)、“Techniques for WCAG 2.0” (www.w3.org/TR/WCAG20-TECHS/)、Overview of WCAG 2.0 Documents (www.w3.org/WAI/intro/wcag20)を公開した。この2006年4月版は十分な完成度を持っているので、Web制作の参考資料として使い始めることができる。一部の詳細は最終版と異な可能性があるが、主な点は不変であり、WCAG 2.0はWCAG 1.0よりもはるかに強固で柔軟である。
ガイドラインよりもユーザー参加から始めることを提案したが、WCAGをWeb制作プロジェクトの中心に置くことも提案する。たいていの場合、WCAGの文書群がアクセシビリティに関する情報の主要な参考文献となる。良くあるパターンは下記のようになるだろう：
WCAGはアクセシビリティ解決の案内役であるべきであるが、客観的に正しく捉えるように注意しなさい。アクセシビリティのゴールはガイドラインのリストにチェックマークをつけることではない。アクセシビリティのゴールは、Webサイトをアクセシブルにすることである。WCAGを用いることで全ての問題が取り上げられていることが保証され、障害者が参加することで有効かつ効果的にそれらの問題が取り上げられる助けとなる。
アクセシビリティに配慮する最善の時期はWebサイト制作プロジェクトの最初であるといえるが、ほとんどのWebサイトは（アクセシビリティを考える時点では）既にできあがっている。それらはアクセシビリティを考慮せずに制作されていて、ある障害者がそのサイトを利用することを困難あるいは不可能にするようなアクセシビリティ問題がある。いくつもの重要な問題を抱えているサイトもあれば、軽微な問題を少し抱えているだけのサイトもある。XHTMLとCSSのようなWeb標準に適合するよう制作されたサイトは、一般的に言って問題点が少ない。
このセクションでは、既存サイトのアクセシビリティ問題解決に特化した方法を述べる。つまり、アクセシビリティ問題を修復、あるいは、アクセシビリティを向上させるよう改良する。前のセクションで述べたことは改良にも当てはまる。
既存サイトのアクセシビリティ問題を解決する作業は、コンテンツの種類、サイトの規模や複雑さ、制作ツールや環境などの多くの要因に応じて、簡単にも複雑にもなりうる。時には、複雑なサイトの方が単純なサイトよりも、テンプレートやCMSを使っているという理由で改良しやすい場合もある。
改良作業のキーワードは、（ずぶ濡れになってヘッドライトの前で立ちすくむ鹿にならないように）優先順位を付けることである。
優先順位付けされた改良計画を立てるためには、まず、既存サイトの全てのアクセシビリティ問題を見つけ出すことが最善であることが多い。しかし、かなり簡単に修復できる少数の重大なアクセシビリティ問題を抱えている場合は、先に進む前にそれらの問題をすぐに片付けることが最善であろう。たとえば、既存サイトのナビゲーションに、代替テキストがない画像が用いられていて、全サイトの元となっているテンプレートに手を入れるだけでそれが改善できるなら、その作業を最初に行いなさい。
改良作業の前に評価を行うのには明白な目的がある。それは、既存サイトのアクセシビリティ問題を同定し、改良プロジェクトを効率的に進める計画を立てるために必要な情報を集めることである。サイトの全ページを隅から隅まで全部評価するよりも、少ない労力でより価値がある情報を得るために、代表的な部分に焦点を当てることができる。たとえば、ナビゲーション・バーやフッターなど、どのページでも同じ要素は、一度評価すれば良く、同じ物が使われている他のページでは評価しなくても良い。評価作業が、Webサイトの各制作者又は制作グループが使っている色々な特徴や機能（たとえば、データ・テーブル、フォーム、スクリプト）をカバーしていることを確認しなさい。
サイトの改良計画の参考にするために、あるアクセシビリティ問題が広範囲な問題か特定箇所だけの問題かを判断するといった、特定のポイントに集中して評価することも可能である。たとえば、データ・テーブルのいくつかだけが必要なマークアップを欠いているならば、品質保証（QA）プロセス（でチェックすべき項目）にテーブルのマークアップを追加する改良計画になるだろう。しかしもし、データ・テーブルのどれ一つとして正しくマークアップされていないならば、（制作者への）教育計画にデータ・テーブルのマークアップ方法を加えるべきだろう。もし、ある制作グループはテーブルを正しくマークアップしていて、他のグループはそれができていないならば、誰を教育する必要があるかがさらに明白になる。
改良の優先順位を付ける際に考えるべきことの一つは、Webサイトのどの部分にまず取り組むかを決めることである。一般的には、そのWebサイトでユーザー体験に与える影響が最も大きい場所を最初に評価し改良するのが一番良い。Webサイトの制作手法に応じて、以下の部分に取り組むことで多数の問題を改善できるだろう：
ある種のページは評価の優先度が高い。たとえば、下記が相当する：
サイトの場所によって優先順位を付けることで、最初に取り組む場所を見通すことができる。次に述べる方法、問題点ごとに優先順位を付けることで、これとは違う見方で、最初に取り組むべき場所を決めることができる。
アクセシビリティの問題は、たいてい、WCAG 1.0のチェックポイントを使って見つけるこができる。チェックポイントごとに優先度（優先度1、優先度2、優先度3）が決まっていて、あるアクセシビリティ問題が与える影響を決めるときに役立つ。サイト改良の方針は、優先度1の問題全部を最初に改善し、それが終わった後で、優先度が低い問題を改善することである。しかしながら、この方法にはいくつか欠点がある。つまり、ページのテンプレートやスタイルシートやページを何回も見直さなければならない。そうすると、簡単に片付く優先度が低い問題を見逃すことになり、たくさんの簡単な問題をさっさと片付ける代わりに、少数の難しい問題に時間をとられてしまう。
たいていの場合、より有効な方法は、ページやテンプレートやスタイルシートなどに取り組む際、影響が大きくてかつ簡単に改善できる問題全部に取り組むことである。その後で、難しい問題に注意を向ける。この方法にはいくつかの利点がある。全体的に見て時間を節約でき、それでもなお多くの問題を迅速に改善できる。この方法によって、Webサイトは早期によりアクセシブルになり、アクセシビリティを向上させたという作業効果をいち早く示すことができる。
アクセシビリティ問題に取り組む優先順位をつける際には、影響と労力という2つの要素を考慮しなさい。アクセシビリティ問題ごとに下記を判断しなさい：
図1-16に示すように、ひとつの軸に障害者に対する影響度を、もうひとつの軸に改善に要する労力をとって、改善点をグラフにプロットすることを考えてみよう。改善プロジェクトは、影響度が大きい改善点と簡単に直せる改善点の両方をカバーしなければならない。影響度が小さい改善点や達成困難な改善点は後回しにしてもよい（再設計のプロジェクトをするときに組み込むこともよくある）。
図1-16 問題点ごとに改善の優先順位をつける：影響度と労力のグラフ
サイトの部分や問題点に応じて優先順位を付け、評価に力を注いで、改善に必要な明確な答えを得ることによって、効果的な改善計画を立てることができる。
Webアクセシビリティに関して神話とでもいうべき間違った思い込みが多数ある。いくつかはなんらかの根拠があるけれども、問題の一面に焦点を当てているだけで、全体像を踏まえて考えるとその根拠がなくなってくる。いくつかは、まったくの間違いである。思い込みの多くは、全体として、アクセシビリティの原因を誤らせてしまう。皆さんが少し時間を割いて真実を理解し、ほかの人が持っている思い込みを解く手助けをして欲しいと思う。
ずっと以前（といってもWeb時間での話）は、視覚的（ビジュアル）に素敵で複雑でダイナミックで、しかもアクセシブルなWebサイトを作るのはほとんど不可能だった。Web技術がアクセシビリティを十分サポートしていなかったし、複雑なビジュアルデザインをエレガントに作る手段としても十分安定していなかった。Webブラウザもまた、アクセシビリティ機能をほとんど持っていなかった。一般的な支援技術もWebページの複雑なデザインを処理できなかった。たとえば、スクリーン・リーダーは画面を横に読むので、新聞紙のようなマルチコラムのレイアウトは使いにくかった。以前は、アクセシブルなサイトを作りたいと思ったWeb制作者は、ページのデザインに大きな制約を加えるか、あるいは文字しか使わないページを別に用意するかを選択せざるを得なかった。
新しい技術によって、視覚的にも魅力があって複雑でダイナミックで、しかもアクセシブルなWebサイトを制作できるようになった。Web技術（XHTMLやCSSなど）、ウェブブラウザ、そして支援技術は進化した。スタイルシートは表現に関するより多くの機能を提供し、ブラウザは文字の大きさを変える機能を備え、支援技術は複雑なテーブルを処理できるようになった。
もはや、アクセシビリティのために文字だけのページを用意する必要はなく、だいぶ前から、そのようなページを作る必要はなくなっている。
本節で取り上げる間違った思い込みの最初の二つの背後には、歴史的な事情が一因としてある。その二つとは、文字だけのページはアクセシビリティの配慮として無難な方法であるという思い込みと、アクセシビリティに配慮すると単調でつまらないサイトになるという思い込みだ。
文字だけのバージョンとは、画像や絵（グラフィックス）を使用しないページのことで、段組を用いないレイアウトであることが多く、ほとんどあるいはまったく色を使用せず、簡単なナビゲーションで利用できる。図1-17に、あるサイトの主バージョンのページ（National Institute of Neurological Disorders and Stroke, NINDS, www.ninds.nih.gov/disorders/repetitive_motion/repetitive_motion.htm）を、また図1-18に、同じページの文字だけのバージョンを示す。
図1-17 NINDSサイトの主バージョンのページ
図1-18 NINDSサイトの文字だけの「アクセシブルなバージョン」のページ
文字だけのページはずっと前に消滅すべきであったが、不幸なことにまだあちこちに残っている。文字だけのバージョンがアクセシビリティ問題の適切な解決法ではないことには、いくつかの理由がある。
文字だけのバージョンの多くは、一部の障害者に対してアクセシブルではない。図1-17では、デザインと色によって、主サイトのナビゲーション部分（訳注：ページ上部や左部にあるナビゲーションメニューなど）を簡単に識別できる。図1-18に示す文字だけのバージョンでは、ナビゲーション部分を識別するのが難しい。ある種の認知障害を持つ障害者は、この文字だけのバージョンを利用できないだろう。なぜならば、彼らはナビゲーション部分をコンテンツ本文と見分けることができないからだ。
別バージョンが元のページと完全に同じであることは滅多にないし、更新されないままになることが多い。二つのバージョンのWebサイトがある場合、文字だけのバージョンは主バージョンほど頻繁に更新されない。（Webサイトを管理運営する）組織や個人が両バージョンの内容を同一に保とうと大いに思っていても、締め切りやリソースの限界という現実の制約が邪魔をする。ひとつのソースから主バージョンと文字だけのバージョンの両方を生成できるツールがあり、二つのバージョンの内容が一致しないという問題を解決できると思われている。すでにあるサイトから文字だけのバージョンを簡単に生成するツールもある。これらのツールによってまったく同じ内容の複数のバージョンを提供できると主張されているにもかかわらず、私は今まで、内容が同じものを見たことがない。私が調べたあるサイトでは、文字だけのバージョンは主サイトと非常に内容が似ていた。しかしながら、文字だけのバージョンには販売促進のコンテンツが欠けていた。したがって、文字だけのバージョンのユーザーは、Webサイトで得られるはずの特別サービスを得られない。内容が同一でないだけではなく、この場合は差別的でもある。
主バージョンが、最も基本的なアクセシビリティさえ満たしていないことが多い。（Webサイトを管理運営する）組織が文字だけのバージョンを作成するとき、普通は、主サイトをアクセシブルにする努力をほとんどしない。障害者の多くは、ほんの少し調整するだけでWebサイトを利用できる。たとえば、ロービジョンの人を例に挙げる。彼女は、ほとんどのサイトがデフォルトで使っている文字サイズよりもほんの少し大きくするだけで文字を読むことができる。彼女は拡大ソフト（拡大ソフトは値段が高い）を必要とせず、ブラウザの設定で文字の表示サイズを大きくするだけでよい。主サイトが基本的なアクセシビリティを満たしていれば、文字だけのバージョン（文字だけのバージョンは図1-18に示すように、一般的には晴眼者にはとても使いにくい）を使わせる代わりに、彼女や彼女のような（障害を持つ）ほかの人もそのサイトを利用できる。いつも主サイトを利用する人も、一時的な障害や状況による制約（たとえば、腕の骨を折ったとか、めがねが壊れたとか、マウスを壊したとか）によりアクセシビリティ問題を抱える場合があるかもしれない。主サイトがアクセシブルでなかったら、彼らは、いつも利用している主サイトとは見た目も動作もかなり違う、文字だけのバージョンを使わざるを得ないだろう。
明らかに、文字だけのバージョンは、Webサイトの主バージョンをアクセシブルにする代替策として許容できない。文字だけのバージョンを提供することに理屈が通った理由があることは滅多にない。文字だけのバージョンを決して提供してはならないと言っているわけではない。主サイトが完全にアクセシブルで、文字だけのバージョンが主バージョンと完全に同一ならば、文字バージョンも構わない。文字だけのバージョンを、主サイトをアクセシブルにしないことの責任回避のために使っていると思われないようにしておくべきだ。
アクセシブルなサイトは、視覚的にも技術的にも単調でつまらなくならざるを得ないという思い込みは、遠い昔に起因する別の思い込みである。もし今でもそう思っているなら、あなたは時代遅れだ。ただし、これは理論的にはいまや間違った思い込みであるが、実際は残念なことに若干の真実が含まれているという点を除けばの話だが。間違った思い込みを正す第一歩として、本節でこの思い込みの原因を見てみよう。
かっては、Webアクセシビリティに力を入れているWebサイトのほとんどは単調でつまらなかった。でもこれは、アクセシビリティがもたらす制限ではない。この主な原因は、このようなサイトを持っている組織が、デザインがよいサイトを作成する十分なリソース（技術あるいは予算）を持っていなかったことにあった。彼らは、限られたリソースを主目的、たとえば特定の障害者に向けてサービスと情報を提供するとかWebアクセシビリティのガイドラインを制作するなどに注力した。アクセシブルなサイトの例を探そうとする人々が見つけたのは単調でつまらないサイトだけだった。不幸なことに、W3C WAIのサイト（www.w3.org/WAI/）もそのようなサイトのひとつだった。世界的に主要なWebアクセシビリティのサイトのひとつがこの思い込みを不滅にしていたのである。我々はこの状態を改善した。2005年、WAIはWebサイトのデザインを見直した。図1-19にデザインを修正する前のWAIのホームページ、図1-20に修正後のホームページを示す。
図1-19 2005年にデザインしなおす前のWAIのホームページ
図1-20 2005年にデザインし直した後のWAIのホームページ
この再デザインプロジェクトのリーダーとして、残念ながらこのサイトは、ビジュアルデザインの輝かしい好例ということはできない（リソースが未だ限られている）。しかしながら、このサイトはもう単調でつまらないサイトではない。（そしてインフォーメーション・アーキテクチャ（情報の論理構造）、ユーザビリティ、そのほかの点は最高である。）アクセシビリティに焦点を当てたほかの多くのサイトも最近彼らのサイトを"改装"し、以前よりも視覚的に魅力あるデザインになっている。
単調でつまらないという思い込みに影響するもうひとつの問題は、Web制作者が、アクセシビリティに対する要求やガイドラインを、実際よりも制限が多いものだと誤解したことだ。WCAG 1.0はJavaScriptの使用を禁じているとか、新しいウィンドウを開いてはいけないなどと誤解されてきた。実際にWCAG 1.0が要求しているのは、Webページは、スクリプトが使えない状況でもアクセシブルである必要があるということだ：
6.3 スクリプト、アプレット、あるいはその他のプログラム的なオブジェクトがオフになっていたり、サポートされていなかったりしても、そのページを利用可能にする。もし、それが不可能な場合には、代替となるアクセシブルなページ上で等価な情報を提供する。
しかし、このチェックポイントはスクリプトの使用を禁じているわけではない。単に、スクリプトが果たしている機能をスクリプトなしでも提供できるような代替手段（を用意すること）も必要だと言っているに過ぎない。たとえば、クライアント側のスクリプトでエラーをチェックしている場合、スクリプトが使用できない場合のバックアップとして、サーバ側でもエラーチェックする必要がある。もし、インターラクティブなナビゲーションなどにスクリプトを用いているならば、スクリプトなしでもユーザーがナビゲーションできるようにしておかなければならない。
WCAG 1.0のチェックポイント10.1は、新しいウィンドウを開くことを取り扱っている：
10.1 ユーザーがユーザーエージェントで新しいウィンドウを開かないように設定できるようになるまでは、ユーザーに知らせることなく、ポップアップあるいは他のウィンドウを開いたり、現在のウィンドウを変更したりしてはならない。
このチェックポイントは、してはならないとは言っていない。このチェックポイントが言っているのは、（新しいウィンドウを開くときは）それをユーザーに伝えなさいということである。WCAGのチェックポイント10.1は、アクセシビリティに取り組むときに、最初はガイドラインや標準を使わずに問題を理解するところからはじめる（べきかである）理由を示すもうひとつの好例である。障害者がWebを使う様子を最初に学んでいれば、ユーザーが気付かない場合、新しくウィンドウが開いたり（フォーカスが）別のウィンドウに変わったりすると問題が生じることがわかるだろう。また、これは、“On Spawned Windows” (www.uiaccess.com/spawned.html)に書かれているように、障害がなくても、Webに慣れていないユーザーにとって大きな問題となることに注意されたい。（制作者への）教育を続け、WCAG 2.0が完成することで、このような有害な誤解が消えることを願っている。
単調でつまらない問題のさらにまた別の原因は、いくつかの「flashy（派手）な」Web技術がアクセシビリティに配慮せずに開発されたことにある。Web制作者は、（これらの技術を使わない）代替バージョンを制作するための余分な作業をたくさんしなければ、これらの新しい流行技術を使用してアクセシブルなサイトを作成することができなかった。この問題を解決するには、下記のことが必要である：
現在のW3Cの全技術は、アクセシビリティをサポートして開発されている。他の技術、たとえばFlashやPDFなどは、アクセシビリティのサポートに向けた大きな進展がなされた。
単調でつまらない問題の最大の原因は、多分もっと文化的な理由だ。WebサイトやWebデザイナー（制作者）は、アクセシビリティで評価されたり報酬が決まったりするわけではない。組織内部の管理者から組織外部の顧客に至るまで、人々は視覚的デザインでサイトを評価し、アクセシビリティ（やユーザビリティ）を考慮しない。ほとんどのWebデザイン・コンクールは、アクセシビリティを評価ポイントに含めていない。たとえば、私が2006年2月に、South by Southwest Web大賞の最終候補に残ったサイトをざっと見たところ、アクセシビリティは最悪だった。もっとも落胆したのは、「展示されたサイトは、… 標準に準拠したアクセシブルな（HTML）コードです。」というCSS部門にアクセシビリティ問題があることだった。
Web文化として、「クールなサイト」の定義にアクセシビリティであることを含めるよう考え方を変えていく必要がある。管理者は、Web制作者を評価するときに、基準としてアクセシビリティを含める必要がある。Webデザインのコンテストも同様である。消費者としては、サイトを応援するときに、アクセシビリティを基準として用いることができる。これについては、本章の後ろに出てくる「はじめよう」の節に書いてある。
アクセシブルで視覚的にもわくわくするようなサイトをより多く制作し推進することで、アクセシブルなサイトは単調でつまらないという思いこみを打破できる。
確かに、Webアクセシビリティは簡単ではないし費用もかかる。しかし、当初考えていたほど大変でお金がかかるわけでもない。Webアクセシビリティに取り組み始めるとき、費用のほとんどは最前線の知識と技術を習得するところにかかる。これは初期投資だと受け入れて、後で取り戻すことができるような計画を立てよう。
Webアクセシビリティがもたらす付加的な利点は、長期的に見ると費用を削減でき、サイトの利用が増えるために投資した分に対する見返りが大きいということである。財政面と技術面での具体例は、本章の「ビジネス面から見た付加的な利点」の節で議論する。
大変でお金がかかるという思いこみに個々の事例で出会ったときは、その背後（の原因）を考えて見よう。それは誤解であるかも知れない。たとえば、Webアクセシビリティが大変で高価であると思われている理由の一つは、スクリーン・リーダーを使おうとするからだ。スクリーン・リーダーは実際、高価で使い方を学ぶのは難しい。時間とお金と苦労の一部を、下記の方法で節約できる：
アクセシビリティのいくつかの点、たとえばマルチメディア素材にキャプション（字幕）を付けるなどは、どんなに効率的に取り組んでもコストがかかる。しかし、Webアクセシビリティにかかるコストのほとんどは、本章のはじめに述べた方法に従えば、大幅に削減できる。
最後に言っておくが、Webアクセシビリティが障害者への機会均等に不可欠であること（そしていくつかの事例では法律で要求されていること）を考えると、アクセシビリティに対応しないことで、別の点で高くつき困難なことになる。（訳注：米国では、リハビリテーション法508条などで、Webアクセシビリティが法的に要求されている。）
Webコンテンツの制作者には、自分が制作するWebサイトをアクセシブルにする責任が常にある。しかし、コンテンツ制作者は、アクセシビリティのために彼らが本来負うべきよりも多くの作業を今はしている。
本章の「 相互依存しているWebアクセシビリティの構成要素」の節で、Webアクセシビリティに対する複数の役割について述べた。コンテンツ制作者以外の構成要素がアクセシビリティにおいてもっと良い仕事をしたら、コンテンツ制作者はもっと楽になるだろう。たとえば、オーサリングツールによってアクセシビリティに配慮したコンテンツを制作するのがより簡単になり、Webブラウザの標準への準拠（特にCSS）が一貫してもっとよく進んだならば、コンテンツ制作者はブラウザ互換性の問題に多くの時間を浪費せずに済むだろう。本章の終わりに出てくる「はじめよう」の節に、Webアクセシビリティにおける自分の役割を全ての構成要素が果たすことを促進するための手引きが書いてある。
きちんと制作されていないWebサイトには、視覚、聴覚、身体、発話、認知、脳機能障害を含む別の障害を持つユーザーが利用できない問題があるかもしれない。本章で示すいろいろな障害のアクセシビリティ問題の例は、種々のアクセシビリティ上の問題を説明している。
あなたのアクセシビリティ上の努力のほとんどは、全盲の視覚障害者が利用できるようにすることに関連しているだろう。この世界の「重鎮」も、全盲の視覚障害者に焦点を置いたアクセシビリティの研究や発表をしている。全盲に対するこのような注目のため、他の障害者のアクセシビリティ問題を心に留めておくことを意識的に努力する必要があるかもしれない。
他の障害のことを心に留めておく他の方法は、別の障害を持つ障害者のペルソナ（訳注：「ペルソナ」とは、本物の人間ではない想像上の存在ではあるが、ターゲットユーザーを念頭に厳密に詳細に定義された仮想ユーザーのこと。）を用いる方法である。ペルソナを作成する際の参考として、“Accessibility in the Analysis Phase: Personas” (www.uiaccess.com/accessucd/analysis.html)及び“How People with Disabilities Use the Web” (www.w3.org/WAI/EO/Drafts/PWD-Use-Web/)を参照のこと。
Webアクセシビリティの評価ツールとは、Webサイトがアクセシビリティのガイドラインや標準に適合しているかどうかを判断する手助けをするソフトウェアやオンライン・サービスである。評価ツールはとても役に立つものであり、Webサイトの評価にかかる時間と努力を減らすことができる。しかし、あるサイトがアクセシブルでありアクセシビリティ・ガイドラインに適合していると判断できるツールは存在しない。サイトがアクセシブルかどうかの判断には、専門知識を持った人間による評価が必要である。
もっとも有名なアクセシビリティ評価ツールはCAST（Center for Applied Special Technology）が開発したBobbyである。(この業界に古くからいる人は http://web.archive.org/web/20020805071053/bobby.cast.org/html/en/index.jsp を楽しめると思う。）WatchfireはBobbyを2002年に買収し、WebXACTに組み込んだ。
“Selecting Web Accessibility Evaluation Tools” (www.w3.org/WAI/eval/selectingtools)に書かれているように、いろいろなタイプの評価ツールがある。Webアクセシビリティ評価ツールの包括的なリストは、“Web Accessibility Evaluation Tools: Overview” (www.w3.org/WAI/ER/tools/Overview)を参照のこと。このサイトは、100以上のツールのデータベースであり、検索や並び替えができる。
ツールのいくつかは、WCAG 1.0のチェックポイントのような標準一式に対してWebサイトをチェックできる。Webページがチェックポイントを満たしているかどうか評価ツールが自動的にチェックできるチェックポイントもあれば、チェックポイントが扱う問題をコンピュータでは判断できないため、ツールでは判断できないチェックポイントもある。そのようなチェックポイントは人間が判断しなければならない。ツールの多くは、このようなマニュアル・チェックを手助けする機能を持っているが、それでも人間による判断が必要とされる。
ウェブスター辞典における、「ツール」とは「職人や労働者が仕事で使う道具」であるという定義が、Webアクセシビリティ評価ツールの役割を理解する際に役立つ。ツールを人間による評価の代わりと考えるのではなく、ツールを人間が評価するときの補助と考えよう。
スペルチェッカーを、評価ツールと類似させて考えてみよう。スペルチェッカーは、既知の単語一式に対して評価を行い、スペルミスの候補を指摘する。次に人間が、指摘された単語のスペルが本当に間違っているかどうかを判断しなければならない。スペルが正しい固有名詞や技術用語などはスペルチェッカーの単語リストには載っていないだろう。人間はその言語を知らなければならない。その文書が、一般的ではない言葉（たとえば、医学用語）が使われる話題に関するものならば、評価する人間はその話題に関するある程度の知識を持っていなければならない。
スペルチェッカーと同様に、Webアクセシビリティ評価ツールも、（WCAGや508条などの）アクセシビリティ標準一式に対してWebページの評価を行い、アクセシビリティ問題の候補を指摘する。次に人間が、指摘された点が本当に標準に適合していなくてアクセシビリティ問題であるかどうかを判断しなければならない。人間が、アクセシビリティ問題とその解決方法を知っていなければならない。“Using Combined Expertise to Evaluate Web Accessibility” (www.w3.org/WAI/eval/reviewteams)に、Webアクセシビリティを評価する際の推薦知識をリストアップしてある。推奨される知識とは、Web技術、評価ツール、障害者が出会う問題、支援技術と障害者の支援技術の使用方法、アクセシビリティのガイドラインと技術を理解することである。
このアナロジーをさらに進めると、スペルチェッカーは、よく似た単語のリストを示すことでスペルミスの修正を手助けする。文書について理解している人間は、リストから正しい単語を選ぶか、もしリストになければ正しいスペルを自分で書く必要がある。いくつかの評価ツールはアクセシビリティ問題の修正を手助けし、知識を持った人間が問題を正しく手直しする必要がある。スペルチェッカーは、本当は正しいのに間違っていると判断することもあるし、本当は間違っているのに正しいと判断することもある。たとえば、”good test tool”とタイプするつもりで”good text tool”とタイプしてしまったら、スペルチェッカーはそれを間違いとは判断できないだろう。同様に、評価ツールが見つけられないエラーがたくさんある。たとえば、HTMLをチェックするがCSSはチェックしないツールは、CSSでフォントサイズを絶対値で指定していても見逃すだろう。
画像の代替テキストのチェックは、作業効率を上げるためにWebアクセシビリティ評価ツールを使い、人間による判断が必要となる好例である。Webアクセシビリティのガイドラインと標準に適合するためには、画像には、画像と等価な情報を示す代替テキストが付与されていなければならない。評価ツールは代替テキストのチェック作業を手助けする。ツールの多くは、代替テキストが欠けている画像すべての一覧を表示する。疑わしい代替テキストに要チェックマークをつけるツールもある。しかし、代替テキストがアクセシビリティのために必要とされる等価情報を提供しているかどうか判断できるツールはない。代替テキストが等価かどうかを判断するには人間による評価が必要なのだ。代替テキストが等価かどうかを評価する人間の判断を手助けするツールもある。たとえば、WAVEツール(www.wave.webaim.org/)は、画像の隣に代替テキストを表示することで、ページの（前後関係などの）文脈の中で、画像と代替テキストを同時に見ることができるようにしている。ツールによっては、欠如していたり適切でない代替テキストを直すために代替テキスト挿入用のダイアログボックスを開いて、代替テキストをWebページのマークアップに挿入する作業を助けるものもある。
代替テキストは、ユーザーが評価に参加する利点を示す好例でもある。評価ツールは、アクセシビリティ標準に適合しているかどうかを評価することに特化したツールである。評価ツールは、このようにアクセシビリティの技術面に特化しているので、Webを利用する人間面が失われる可能性がある。ユーザビリティ評価技術に障害者を入れて、「使いやすいアクセシビリティ」を評価してもらいなさい。そして、アクセシビリティ問題の修正の仕方がうまくいっていて障害者に使いやすいことを確認してもらいなさい。「使いやすいアクセシビリティ」は、“Another -ability: Accessibility Primer for Usability Specialists” (www.uiaccess.com/upa2002a.html)で導入された用語である。
伝統的なユーザビリティテストに障害者に参加してもらうことにはいろいろな利点がある。しかし、使いやすいアクセシビリティを評価する際、大規模でフォーマルなユーザビリティテストは必要ない。厳密なフォーマル・ユーザビリティテストをしなくても、短いインフォーマルな評価で障害者から貴重な成果を得ることができる。
本章で述べた「障害者に制作プロジェクトに参加してもらう」の節で、Web制作と評価に障害者が参加する際の手引きを述べた。Web制作全体に渡って障害者（「ユーザー」）にアクセシビリティ評価をしてもらうためのほかの手引きは、“Involving Users in Web Accessibility Evaluation” (www.w3.org/WAI/eval/users) および “Usability Testing for Accessibility” (www.uiaccess.com/accessucd/ut.html)にある。後者はフォーマル・ユーザビリティテスト用に書かれているが、多くの資料はアクセシビリティ問題に焦点を当てたインフォーマルな評価に障害者が参加する際にも適用できる。
有効で効率的な評価は、下記を組み合わせることにより得られる：
最近よく耳にする間違った思い込みは、アクセシビリティ・ガイドラインだけではWebサイトを確実にアクセシブルにするのに十分でないというものである。著者は、この思い込みに取り組んでいる最中である。“Myth: Guidelines Aren't Sufficient for Accessibility” (www.uiaccess.com/myth-guidelines.html)を参照のこと。
Webをアクセシブルにする理由は、障害者もほかの人と同等にアクセスできるようにすることであり、それがすべてである。しかし、Webアクセシビリティのたくさんのほかの利点を知っておくことも役に立つ。Webをアクセシブルにすることで潜在的な市場が広がり、維持にかかる労力を減らし、そのほかにもいろいろな利点を生むことを知っていたら、（Webを管理運営している）組織が、アクセシビリティにより多くのリソースを割くことが容易になる場合が多いだろう。
Webアクセシビリティの最大の焦点は障害者がアクセスすることにあるけれども、もっと広くビジネスの視点で見ると、アクセシビリティとは、より多くの人がより多くの状況でWebサイトを有効に使えるようにデザインすることであるといえる。
Webサイトのアクセシビリティを向上させた結果、技術的な性能が向上することが多い。Webアクセシビリティのいろいろな技術的利点の重要性は、その組織や状況によって異なる。たとえば、サーバの負荷が減少することは、大規模で失敗が許されない、トラフィックが多いサイトでは最も重要になるだろう。しかし、最先端の技術を使うことに力をいれているほかの組織は、相互運用性や先進のWeb技術への対応しやすさのほうに興味を示すかもしれない。そしてこれらの同じ技術的な利点でも、小規模で単純なサイトを持つ組織ではそれほど重要ではないだろう。
アクセシビリティは品質が高いWebサイトの一面である。技術標準に適合している高品質なWebサイトの制作を誇っている制作者や組織がある。WCAGなどのWAIのガイドラインは広く認知されている国際標準である。オンライン上のいくつかの情報源は、Web標準に適合する利点やビジネスケースについてより広く述べている。検索エンジンで「benefits web standards」（訳注：日本語ならば「Web標準 利点」）をキーワードに検索して、より詳しい情報を参照のこと。
アクセシビリティ対応によってサイト制作と管理にかかる時間を削減できる。アクセシビリティに対応すると、サイト制作の初期にかかる時間は一般的に増大する。しかし、長期的に見れば、Webアクセシビリティ対応によって、サイトを運営する組織がサイト制作と管理にかける時間を削減できる。
（ページの見せ方である）表現をスタイルシートで定義し、コンテンツの構造を（たとえばXHTMLで）正しくマークアップすることで、サイト全体の表現を変更する際に必要な作業時間と作業量が削減される。表現には、フォントサイズやフォントの種類や背景色やページレイアウトなどのデザインとスタイルが含まれる。表現が外部スタイルシートで定義されていれば、その一つのスタイルシートを修正するだけでサイト全体の表現を変更できる。しかし、表現が不適切にもHTMLページの中で定義されていたら、全ページのすべての表現のためのマークアップをひとつひとつ変更する必要が生じる。
画像文字を使う代わりに、テキストのスタイルとフォーマットに標準的なマークアップとスタイルシートを使うことで、ページを更新する時間が減り、多国語で提供するサイトの場合は翻訳にかかる時間と技術を減らせる。サイトのデザイナーは、特定のデザインで文字を表示するために画像文字を使うことが多い。そのような場合、文字の内容やスタイルを変更したり翻訳したりしようと思ったら、画像ごとに処理しなければならない。文字が画像で表されていなかったら、そして（文字の表示）スタイルがスタイルシートで提供されていたら、画像を修正することなく文字を変更したり翻訳したりし、スタイルの変更はスタイルシートでできる。
Webアクセシビリティ技術はサーバーの負荷を減らすことが多い。その結果、サーバーの数を増やす必要性が減り、ダウンロード速度が増す。ページごとに表現をマークアップする代わりにスタイルシートで表現を定義することや、画像文字の代わりに文字を使うことで、各ページのサイズが小さくなる。
アクセシビリティに配慮することで、構成を変えてもコンテンツを利用することが容易になる。多くの組織が、Webの相互運用性とデバイス非依存性に対する興味を増している。（デバイス非依存とは、複数の技術や閲覧端末などで利用できるWebサイトを制作すること。）Webアクセシビリティにより、Webコンテンツがいろいろな構成（さまざまなブラウザやOSや表示端末など）でレンダリング（表示）されたり利用されたりできるようになる。
W3Cの技術、たとえばExtensible Hypertext Markup Language (XHTML)、Extensible Markup Language (XML)、Resource Description Framework (RDF)、Synchronized Multimedia Integration Language (SMIL)、Cascading Style Sheets (CSS)、Extensible Stylesheet Language (XSL)、XSL Transformations (XSLT)、そしてPortable Network Graphics (PNG)などは、アクセシビリティに対応するように開発されている。W3Cの現バージョンの技術を用いることで、異なった構成でも最良のレンダリング結果が得られるようになる。デバイス非依存を考慮してデザインすることで、電話やそのほかのハンドヘルド機器などのキーボード以外の入力機器を用いている人々だけではなく、障害者の一部も恩恵を受ける。構造にはマークアップを、表現にはスタイルシートを用いることで、ユーザーとユーザーエージェントが、それぞれの能力に適した形でコンテンツを得ることができるようになる。
Webアクセシビリティによって、最先端のWeb技術を活かしたり将来のWeb技術に備えることができる。“Frequently Asked Questions about RDF” (www.w3.org/RDF/FAQ.html#What)の“What is RDF?”節に書いてあるように、メタデータを用いてRDFでそれを表せば、コンテンツを再利用できる。表現をスタイルシートで定義し、適切なマークアップ構造を用い、最新の標準を用いることで、新しい技術に対応することも古い技術との互換性を保つことも容易になる。
自サイトをアクセシブルにするという努力は、経済的な効果を生むことが多い。そしてその結果、投資の成果が上がり、経費を効率化できる。アクセシブルなサイトを提供する組織が得る利点には、Webサイト利用数の増加と直接的な経費削減という経済的な利点がある。
サイトをアクセシブルにすることで、SEO（Search Engine Optimization）の効果がかなり向上する。組織によっては、SEOはとても重要である。そのような場合、アクセシビリティに対応する努力を正当化するビジネスケースをあなたが必要としているなら、アクセシビリティのこのような副次的効果はよいセールスポイントになる。
アクセシビリティ技術のいくつかは、SEOに対する技術とまったく同じである。ということは、アクセシビリティ技術を用いればサイトのページ順位が上昇する可能性がかなり高いということである。たとえば、Googleのウェブマスター向けのガイドライン （www.google.co.jp/webmasters/guidelines.html）には下記のように書いてある：
次のガイドラインに従うと、Googleがあなたのサイトを発見し、インデックスに登録し、ランキングしやすくなる。
- TITLEタグおよびALTタグ[原文のまま]の説明を、わかりやすく正確にする。
- 重要な名前、コンテンツ、またはリンクを表示するときは、画像の代わりにテキストを使用する。Googleのクローラは、画像に含まれたテキストを認識しない。
- 無効なリンクがないかどうか確認し、HTMLを修正する。
- わかりやすい階層とテキストリンクを持つサイト構造にする。
- ページ内のリンク数を適切な数に抑える (100 未満)。
- ユーザーのためにサイトマップを用意する。
- Lynxなどのテキストブラウザを使用してサイトを確認する。なぜなら、ほとんどの検索エンジンのスパイダーがサイトを認識する場合、Lynxと同様の形式で認識するから。JavaScript、クッキー、セッションID、フレーム、DHTML、Flashなどの特殊な機能によりサイト全部がテキストブラウザで表示されない場合、検索エンジンのスパイダーがサイトをクロールするときに問題が生じる可能性がある。
これらのすべての項目はアクセシビリティガイドラインでありベストプラクティス（最良の実践例）である。マルチメディアに付与する等価テキストのように、アクセシビリティ技術がSEOを向上させる例が他にもある。検索エンジンが画像の代替テキストを必要とするように、マルチメディアにも代替テキストが必要なのである。視覚的に表現されたマルチメディアに書き起こしテキストを提供することは、アクセシビリティの要求にもかなうし、検索エンジンがそれらを検索できるようにもなる。
見出しは、アクセシビリティ技術と検索エンジンへの最適化に重複して適用できる別の例である。ある種の認知障害者は、わかりやすい見出しでグループ分けされた情報に大いに助けられる。スクリーンリーダーを使っている人々は、見出しタグ（h1やh2など）で適切にマークアップされた見出しに助けられる。ページを見ることができる人は、ページの見出しを視覚的に流し読みしてページ内容の概観を知ることができる。スクリーンリーダーを使っている全盲の人はこのようなことはできず、一度に語ずつ読み上げてページにアクセスする。見出しが適切にマークアップされていれば、スクリーンリーダーの利用者は、スクリーンリーダーの（見出し読み）機能を使って見出しを流し読みできる。もし見出しがマークアップされていなかったら、全盲のユーザーはこの機能を使えない。
アクセシビリティに対するSEOの利点についてのよい文献をいくつか見つけるためには、Webで「アクセシビリティ 検索 エンジン」と検索すること。
Webアクセシビリティの大きな利点は、Webサイトの利用が増えることによって、直接的および間接的に経済的な利益を得る可能性があることである。Webアクセシビリティによって、ユーザーがWebサイトを探しやすくなったり、アクセスしやすくなったり、利用しやすくなったりする。その結果、ユーザーが増え、利用回数も増える。
より多くの人がWebサイトをうまく使えると、多くの組織は経済的な利益を得る。たとえば、商売をしている会社は売り上げが増えるし、教育機関はより多くの学生を得ることができる。そして非営利団体は、活動の拡大と普及に成功していることを示すことで、より多くの資金を得ることができる。 人を使ったり紙で取引する代わりにWebサイトを用いてカスタマサポートを削減したり顧客がオンラインで取引するようにしたりすることで、Webサイトはますます経費削減に利用されるようになっている。 オンライン取引によって経費を削減した多数の例には、（運転免許証などの）市民のライセンスのオンライン更新や、投資家のオンライン株取引や、学生のオンラインクラス登録などがある。 このように、Webサイトの利用者と利用回数が増えれば、経済的な利益とコスト削減に結びつく。
アクセシブルなサイトは、（本章の「障害者以外への利点」の節で述べたように）より多くの人に使ってもらえるので、市場区分を増やせるし、Webサイトを問題なく利用できるユーザーも増える。多くの組織にとっての重要な潜在的市場は高齢者である。多くの国で、もっとも早く増加している新規Webユーザーは高齢者である。
Webを利用することが仕事の重要な一部であるとき、より多くの人にとってアクセシブルなWebページとアプリケーションは、従業員募集や従業員をつなぎとめることに役立つ。従業員、顧客、そのほかのユーザーが、事故や病気や加齢のため、一時的あるいは永久に障害を持ったり機能が損なわれたりした場合、Webサイトがアクセシブルであれば、そういう人たちもWebサイトを利用し続けられる可能性が高い。
アクセシブルなサイトは一般的に、障害者も障害がない人も、すべての人にとって、より使いやすい。ユーザビリティが向上したということは、Webサイトのユーザーが有効に、効率的に、満足して、目的を達成できるということである。ユーザーがWebサイトでよい経験をしたら、彼らはそのサイト余すところなく利用し、何度も再訪し、ほかの人にも宣伝する（バイラル・マーケティングとよぶ）可能性が高い。アクセシビリティ・ガイドラインの中には、間接的にユーザビリティを増すことができるものがある。たとえば、Webページのロード時間を短くすることなどである。
アクセシビリティ・ガイドラインの中には、すべてのユーザーに対して直接ユーザビリティを改善するものがある。たとえば：
Webアクセシビリティに努力することで、組織のよいイメージを増強する宣伝をする機会になり、それによってWebサイトの利用を増やすことができる。 本章で述べたように、Webアクセシビリティは社会問題であり、CSRの側面を持つ。 財政能力を向上させ、ブランドイメージと評判を増強し、売り上げと顧客のローヤルティ（企業への忠実度）を増し、従業員をひきつけてつなぎとめる能力を増し、資産と財産を公開するために、CSRは示されてきた。 顧客に与える影響を示す統計などのCSRの情報を探すには、「corporate social responsibility」（訳注；日本語なら「企業 社会的責任」）と「corporate citizenship」でWebを検索してほしい。
多くの組織は、Webアクセシビリティを向上させる努力をすることで、Webサイトの利用が増えるところから来る利益のほかに直接的な経費削減ができることに気付いている。Webアクセシビリティのいろいろな面を、技術的な利益を述べた節で議論したが、そうしたいろいろな面が直接的な経費削減をもたらす。
直接、経費を削減できるという可能性は、高額な訴訟費用を請求される可能性が少なくなることや、別形式のコンテンツを用意する費用が減ることや、翻訳にかかる費用が減ることの結果としても生じる。Webサイトがアクセシブルであると保証できることで、Webアクセシビリティの要求事項に適合していないといっておこされる訴追に対処することに伴う高価な法的費用の危険性が減る。
印刷物を別形式（文字が大きなプリント、点字印刷、電子メディア）で配布する組織にとって、人々がWebを利用する方を選択すれば、アクセシブルなWebサイトによって別形式の必要性を減らすことができる。その結果、別形式を作成したり配布したりする費用の一部を節約できる。Webサイトをほかの言語に翻訳する費用は、下記のアクセシビリティガイドラインにより削減できる：
Webアクセシビリティの技術的および経済的な利点の詳細は、“Developing a Web Accessibility Business Case for Your Organization” (www.w3.org/WAI/bcase/Overview)を参照のこと。このページは特定の組織に合わせたWebアクセシビリティのビジネスケースを作成するために作られ、これらの面を特定組織のビジネスケースに組み込む方法を示しながら、Webアクセシビリティのいろいろな面を述べている。
アクセシビリティに対応するということは、組織と個人両方にとっての啓蒙的な自己利益の行為である。個人や組織がアクセシビリティの利点に気づいたら（つまり「啓発」されたら）、彼らは、他人だけではなく自分のためになるようにアクセシビリティ問題に取り組むだろう。たいていの人は、一時的あるいは生涯にわたる障害を人生で経験し、アクセシブルな技術の恩恵を受けるだろう。生まれつき障害を持った人もいれば、事故や病気や疾患や加齢により障害を持つ人もいる。大事なことは、あなたが今は障害を持たなくても、いつか障害を持つ可能性がかなりあるという点だ。
多くの人にとって、アクセシビリティは正しいことであると理解するだけで十分な動機になる。障害者の知り合いがいる人や、自分が参加したサイト制作に障害者が参加していたことがある人や、障害者がアクセシビリティに欠けるサイトを使えない様子とアクセシブルなサイトならうまく使える様子を直に目撃した人の多くは、アクセシビリティに熱意を燃やすようになる。アクセシビリティに欠けるサイトがもたらす社会的な不平等とアクセシブルなWebの障害者に対する影響力を理解すれば、Webアクセシビリティに対して自分の役割を果たしたくなるだろう。
（他人に対して）あなたができるもっとも大事なことは、アクセシビリティに対する積極的な態度を育むことである。
2,3年前、フラストレーションがたまる厄介な法的要件だと思ってアクセシビリティに対応している会社のコンサルティングをした。その会社の制作者たちはできるだけ手間をかけまいと、チェックリストを使ってチェックしようとしているだけだった。そのような方法を取ったために、アクセシビリティ対応と、やり直す羽目になる非効率的な対処に、多くの努力を無駄にしていた。それでは誰も楽しくなかった。 当時、私がコンサルティングをした別の会社は、まったく別の方法でアクセシビリティに取り組んでいた。その会社の経営者はアクセシビリティを、競争相手に対して差別化をはかり、市場で会社の特徴を出すものと捉えていた。制作者たちは、技術者がパズルを与えられたような感じで、難しい問題を引き受けた。 彼らは革新的なアイデアを思いつくことが好きなので、難しいアクセシビリティ問題を見つけることを歓迎していたといってもよいくらいだ。彼らはまた、一組の障害者を定期的にオフィスに招いて、彼らが問題点を理解したり解決案を試してみることを手助けしてもらっていた。これは、参加したもの全員にとって刺激的なプロジェクトだった。
これらの例から、心構えが重要であることがわかる。価値ある挑戦としてアクセシビリティに取り組もう。
あなたがWebアクセシビリティへの取り組みにすでにある程度成功しているなら、その成功体験を共有することで、Web制作のコミュニティ全体に積極的な取り組みを広げることを支援できる。 これはまた、ほかのプロジェクトでアクセシビリティへの支援を受けようとしている人々への助けにもなる。 （インターネットあるいはイントラネットに関わらず）Webサイトのアクセシビリティを向上させることでSEO向上や商売繁盛や管理削減などの利益がどのように生じるかについて述べた、より多くのデータあるいは経験的であってもその証拠が必要である。 会議で発表したりWebに記事を書いたり、あるいはアクセシビリティ関連のメーリングリスト(たとえば、WAI Interest Group：www.w3.org/WAI/IG/#mailinglist や WebAIM www.webaim.org/discussion/)に投稿したりして、あなたの組織で実感したさらなる利点を教えて欲しい。（自分たちの組織の市場価値を、ある程度ここから得ることもできる。）
あなた自身とあなたの組織とWebアクセシビリティ一般の相互に利点をもたらす別の方法は、アクセシビリティの改善をさまざまな要素（ブラウザやオーサリングツールなど）で進めることである。本章で、どの要素が先にアクセシビリティ機能を持つべきかという卵が先か鶏が先か問題について述べた。それぞれを先に進めて、ほかの要素が対応するよう促進しなさい。ひとつの要素にアクセシビリティ機能が効果的に実装されていれば、ほかの要素もアクセシビリティ機能を実装する可能性が高い。
オーサリングツールの顧客として、Web制作者には、ツールをアクセシブルにするようオーサリングツールの開発者に要求する強い影響力がある。あなたが今後オーサリングツールを購入するときの基準は、アクセシビリティ機能を実装しATAGに適合していることであるという電子メールを送ろう。今後の製品に実装して欲しい具体的なアクセシビリティ改良点をオーサリングツールの開発者にフィードバックしよう。
Webをよりアクセシブルにするために、あなたが直接Web制作に関わる必要はない。Webアクセシビリティの重要性と利点をほかの人に伝えることで、誰でも貢献できる。Webサイトがアクセシブルになるように励まそう。販売部、マーケティング部、カスタマサービス部、Web制作部に電子メール（や手紙や電話）を送って、彼らのWebサイトのアクセシビリティ向上を頼もう。アクセシビリティについてもっと学べるリソースのありかを彼らに教えよう。彼らのWebサイトのアクセシビリティ問題が障害者にどのような影響を及ぼすか説明しよう。
どうか前向きに力づけるような態度を取ってほしい。攻撃的だったり脅かしたりあるいは否定的な態度はやめてほしい。否定的な気持ちを持ったとしても、否定的な態度は（サイトを）アクセシブルにしてもらうための最良の方法とはならない。Webサイトのアクセシビリティをある程度向上させた組織が、改善が不十分だといって厳しく批判されたのを見たことがある。ある責任者は激怒して「なぜアクセシビリティ改善を試したことさえ批判されるのか？我々は、最善を尽くしたのに批判された。」Webサイト制作側に対応するときは、彼らが意図して障害者を排除しているというよりは、彼らがアクセシビリティを理解していないと仮定するのが最も当たっていると思う。一般的に必要なことは教育と激励であって、批判ではない。もちろん、これとは異なった取り組みをするのが適した時もある。しかしそれは、もっと協力的な方法で取り組んだ後で使う最後の方法にすべきだ。
そのサイトから購入し、ほかの人にそのサイトのことを話すことで、アクセシブルなサイトに報いよう。アクセシブルなサイトを作ってくれて感謝していることを伝える電子メールを送ろう。こうすることで、アクセシビリティ改善努力の利点を制作側に知ってもらうことができ、今後さらにアクセシビリティを改良していく予算を彼らが得ることを助けることができる。
アクセシビリティの伝道者になろう！
本章では、Webアクセシビリティを理解するための重要点について述べた。これら重要点には、障害者に機会均等を提供するという点でのWebアクセシビリティの重要な役割、ほかの人や（Webサイトを持つ）組織に与える副次的な利点、相互依存している構成要素、サイト制作の始めから終わりまで障害者を交えてWebアクセシビリティに取り組むこと、そしてWebアクセシビリティに関する間違った思い込みがある。本章の最新情報は、www.uiaccess.com/understanding.html を参照のこと。
本章で述べた情報の一部は、W3C WAI (www.w3.org/WAI/)とEducation and Outreach Working Group (www.w3.org/WAI/EO/)の下記の文書を使って書かれた。追加情報や最新情報は、これらのリソースのオンライン版の最新情報をチェックすること。
W3C以外からの参考情報には下記がある：
アクセシビリティに関するよい情報源が今はたくさんあり、ここでは書ききれない。それにその一部をここに掲載すると、掲載しなかったものに悪いと思う。そこで、（ほとんどは）WAIのものと私がほかの場所に書いたものだけをこのリストに含めた、もちろん、この本の残りの章は、本章で紹介した問題を詳しく扱っている。