はじめに

よくアクセシビリティという言葉が使われますが、アクセシビリティとは何なのか、アクセシビリティに配慮したコンテンツを作成するにはどうしたら良いのか、という点に付いて、ここでは触れていきたいと思います。

なお、元としている文書は、W3C で公開されている Web Content Accessibility Guidelines 1.0 を元としています。

アクセシビリティとは、簡単に言うとどれだけ目的のリソースが入手しやすいのか、という事になります。ここでの入手とは、単に手元にデータのコピーを持ってくるという単純なアクセスを意味するものではなく、リソースに含まれている情報に対する入手性を指します。

これはどういうことなのかというと、例えば画像だけで構成されたコンテンツには、画像を閲覧できる人だけが、その画像が持っている情報を入手することができます。こうした場合に、画像の内容を示す、画像の代わりとなる文章が用意されていた場合には、ユーザはその文章を入手することで、画像が持っていた情報を入手することができるようになります。こうした、情報をどうにかしてユーザへ提供することに意を尽くす、ということがアクセシビリティを向上させることとなります。

アクセシビリティの話になると良く言われるのが、障害を持つ人に配慮する、といった言葉ですが、それだけではありません。何の障害も持たない人でも、たとえば i-mode や EZWeb からでも自由に情報を入手できるようにする、細い回線でも快適に情報を入手できるように軽いリソースを提供する、といった行為もアクセシビリティへ配慮したコンテンツ作成と言うことになります。

出来るだけ沢山の人にコンテンツを提供したいと思われる方、微妙な言い方をすると、エンドユーザに対するコンテンツのリーチ性を確保したい方 (主に企業サイトなどでしょうか) には、これは必ず考慮したい事項と言えるのではないでしょうか。

ここでは、HTML 文書を作成する方向を主として書いていきたいと思います。

要点

  • 画像、その他特殊なデータ形式は閲覧できないかも知れません
  • 文章を読むこと、理解することが困難かも知れません
  • キーボードやマウスといった入力デバイスは無いかも知れません
  • 画面が小さかったり、接続している回線が非常に低速かも知れません
  • ユーザが目、耳、口、手などを自由に使えない状態 (運転中など) かも知れません
  • ユーザが古いバージョンの WWW ブラウザや、全く異なる OS を利用しているかも知れません

コンテンツを設計、及び作成する段階で、設計者、及び作成者はこういった事を常に意識しましょう。こうした事に配慮して作られたコンテンツは、制作者、ユーザの双方にとって利益をもたらすでしょう。

あなたの目を信じない

この文章をあなたはどのような形で入手しておられるでしょうか。ほとんどの方は WWW ブラウザを通して、目で見ていらっしゃるのではないでしょうか。実際、私はこのコンテンツを作成する段階において、実際の閲覧イメージを想像しながら書いたり、実際に SeaMonkey や w3m で問題なく閲覧できることを確認したりしながら書いています。ほとんどの方はそうでしょう。

そういう人間がこういう事を言って説得力があるのかと問われたら、その場合にはこう答えることとなります。

「この文章へアクセスした人に対して伝えたい内容とはどういった物なのかを考えながら作成することと、この文章へアクセスした人に対してどのような見た目で見せたいのかを考えながら作成することは全く別の事だ」

見た目から離れる

W3C 信者と呼ばれる人々に「font 要素、 b 要素といったそういった物理要素は使うな」と言われたことがある方もおられることと思います。さて、この物理要素とは一体何なのでしょうか。

物理要素として定義されているものは、以下のような要素があります。

これらは全て、目で見た場合にしか影響されない視覚的な情報を持っています。なぜこれを使うなと言われるのか。それは目で見なければ意味がない情報しか持っていないため、目で見ていない人にとっては全く意味を持たない情報ということになってしまうためです。

ここで問題となってくるのは、コンテンツ作成者はユーザに対して見た目を変えることを伝えたいのか、それとも見た目を変えることによって目立たせた部分に書かれている内容を伝えたいのか、という点です。

なぜコンテンツ作成者は見た目を変えたのかという理由こそが、ユーザに対して本当に伝えたい事ではないでしょうか。目立たせるということは、ユーザに対してより強く印象づけたい、という事でしょう。そのためには、HTML には em 要素が、em 要素よりもさらに強く印象づけたい場合には strong 要素が提供されています。

これらを利用することで、フォントを変更することができないブラウザを使用している人でも、文章を読み上げさせている人でも、何を印象付けたいと思っているのかを理解することができるようになります。また、スタイルシートに対応しているブラウザを利用している方には、これを利用してさらに表現豊かな提示方法を提供することもできます。

もちろん、古いブラウザを利用している人へ同じ様に見えることが必要だ、という方もおられるでしょう。そういった場合に font 要素などを利用することを否定するつもりはありません。しかし、font 要素だけを利用するのではなく、font 要素併用することで、ユーザへのアクセシビリティを高めつつ、古いブラウザでも同様の表示を得られるという、両方の要求を満たすコンテンツを作成することができるようになるわけです。

なお、あなたが見やすいと思って選択した色合いは、色を判断する能力が弱い方にも正しく判別できるかどうかを考えてみましょう。その方は、押し付けられた配色よりも自分の見やすい配色を利用して閲覧することを望むでしょう。

こうした場合の為に、CSS に対応したブラウザでは、ユーザスタイルシートという機能を用意しているものが多々あります。代表的なブラウザとして利用されているのは Internet Explorer、Firefox、Opera といったものがありますが、これらは全てユーザスタイルシート機能を持っています。

この機能を利用しているユーザの場合、font 要素による文字の大きさの変更や色の変更、フォントの変更などを全て無効にしている場合もあります。(私もやっています)

こうした事を考慮すると、font 要素などの物理要素のみを頼りに文書内のある一部分を目立たせるといったことが、役に立たない事は十分に考えられるという事がお分かりいただけると思います。

文章の形で提供する

ユーザにとって、最も利用価値の高い情報は文章で提供されるものです。というのも、文章の形で提供される場合、ユーザにとってもっとも処理のしやすいものとなるからです。文章の形で提供された情報は、見る、印刷する、読み取らせる、展示プリンタで印刷して読むといったように、ユーザが任意の形に加工して読み取ることができます。

画像で提供される情報は、画像を処理できないユーザエージェントでは情報価値は無くなってしまいます。たとえば、文章を読み上げる形でユーザがアクセスしている場合、画像だけではユーザにとっては情報が得られません。しかし、画像と同等の情報を文章の形で一緒に提供した場合、画像を処理できるユーザは画像で、画像を処理できないユーザは文章で情報を入手できるため、ユーザは何らかの形で情報を入手することができるようになります。

もちろん、これは画像に限ったことではありません。Flash や音声データによる情報の提供は、Flash を再生できない環境や、音声データを再生できない環境では全く情報が提供されないこととなってしまいます。

HTML の場合には、img 要素や object 要素を利用した情報提供を行った場合に、この問題が出てきます。

img 要素の場合には、画像が埋め込まれるべき場所に画像が表示できない場合には alt 属性を利用した代替となる文章の提供ができるようになっています。また、alt 属性では説明しきれないような、長い文章による詳細な説明を行いたい場合には、longdesc 属性を使用することで、説明文を提供しているリソースを提示して画像の説明をユーザに提供することができます。

なお、例えば単なる飾りに使われている画像など、特にユーザに対して情報として提示する必要がない項目については alt="" と、情報が無いことを明示することが必要です。画像が情報を含む場合には、その情報を代替として提供される文章にも含むことが要求されます。例えば、リンクスポットにした画像が犬に関する情報として提示されている場合、代替となる文章には "犬に関する情報" "犬に関して" といった文章がふさわしいでしょう。

object 要素の場合には、属性と内容として持つ param 属性により、object 要素として埋め込まれるデータ、および実行されるオブジェクトに渡されるパラメータが指定されますが、これと共に、内容として object 要素が処理できない環境に対して object 要素の代わりに提供される情報を持たせることができるようになっています。たとえば Flash データを object 要素で提供し、Flash データを処理できない環境では img 要素を内容として持つことで、処理できなかった環境に対する情報を提供することができます。Flash などでメニューを提供したい場合などには、代替としてイメージマップを提供し、イメージマップを処理できない環境のために、イメージマップと共に文章の形でメニューを提供する、というのがもっとも望ましい提供形式となるでしょう。

より容易にアクセスできるようにする

ユーザが制約を受けた環境で情報を入手しやすくするために、コンテンツ制作者は構造と表現を分離することが望まれます。これは先にあげた見た目から離れることと関連します。

低性能な環境でも情報を入手することができるようにしたり、ユーザが容易に関連する情報へアクセスできる手段を提供するようにしましょう。

チェックポイント

ここでは、Web Content Accessibility Guidelines 1.0 で挙げられているチェック項目を説明します。ややわかりにくそうなものについては、さらに詳しく説明も付けてみました。

優先度 1 とされる項目は、最低限全て満たされなければならないとされる項目です。優先度 2 とされる項目は、満たされる事が望まれる項目です。優先度 3 とされる項目は、満たされるとより良いとされる項目です。できれば、優先度 2 までの項目はできるだけ満たすようにすると、ユーザに対して優しくなるように作成されたコンテンツとなるでしょう。

対応すべき項目 - 優先度 1

  1. alt 属性で説明できる内容のものは alt 属性で、alt 属性で説明しきれない、もしくは同等の内容を提供できない場合には longdesc 属性で指し示されるリソースで、同等の情報やサービスを提供します。これには img 要素、applet 要素、input 要素などが含まれます。また、alt 属性と area 要素を併用したイメージマップも含まれます。

  2. 同等の情報やサービスを文章の形で内容に含ませるようにします。これには、object 要素、 applet 要素、map 要素が含まれます。

  3. サーバサイドイメージマップを利用する場合には、同等のリンクを文章の形式で提供するようにします。

  4. ストリーミングメディアなどのタイミングが重要となる情報では、代替的に提供される情報 (映像メディアの音声説明など) は同期を取るようにします。

  5. 色によって表される情報情報を、色が表示されない、識別できない環境でもアクセスできるようにします。(例えば、赤いボタン → 送信ボタンなど)

  6. 文書中に含まれる言語が変化した場合、これを明示するようにします。HTML や XHTML 1.0 では lang 属性を、XML や XHTML 1.1 では xml:lang 属性を利用します。

  7. 表の各セルでは、表の見出しとなるセル (th 要素) とデータとなるセル (td 要素) を明確に区別します。

  8. 表の内部でデータ構造を持つ場合 (例えば見出し部、データ部など)、thead/tfoot/tbody/colgroup/col 要素、axis/scope/headers 属性などを利用し、適切なマークアップを施します。

  9. スタイルシートが適用されなくても、文書内容が正しい順序で提供される構成にします。

  10. CGI などで動的にコンテンツが変更される際、代替となる文章なども正しく変更します。

  11. スクリプト、アプレット、プログラム的なオブジェクトが利用できない環境でも、サービスを正しく提供できるようにします。それができない場合、代替提供されるリソースによって同等のサービスが提供します。

  12. スクリプト、アプレット、プログラム的なオブジェクトを使用することができないためにサービスや情報の提供に致命的な問題が発生する場合、直接実行を可能なようにするか、または代替的な手段により、同等のサービスや情報を提供します。

  13. どうしてもサーバサイドイメージマップでしか提供できないイメージマップを除き、クライアントサイドイメージマップを利用します。

  14. 最善の努力を払っても、ユーザにアクセシブルな文書を提供できない場合には、オリジナルの文書と同じ頻度で更新される代替文書へのリンクを提供します。これは最後の手段とすべきです。一般的に、こうした代替文書はオリジナルほどの頻度で更新されない事が多いためです。こうした場合には、オリジナルの文書の再設計を検討した方が良いでしょう。

  15. フレームの識別や操作を容易にするために、フレームには必ず題名 (title 属性) を付けるようにしましょう。

  16. 平易でわかりやすい表現を使用するようにしましょう。

ユーザエージェントが対応するまでは対応すべき項目 - 優先度 1

  1. 映像のような視覚的な情報と共に提供される同等の情報を持つ文章がユーザエージェントに自動的に音読されるようになるまでは、視覚的な情報の重要な部分を聴覚的な情報として提供するようにします。

  2. ユーザが明滅速度や明滅自体などを制御できるようになるまで、(1 秒間に数回以上の) 高速な明滅を行わないようにします。

対応されるべき項目 - 優先度 2

  1. 画像を使う場合、色を判別する能力が弱い方や、モノクロなどの判別できない環境でも十分に判別可能な前景色、背景色のコントラストを持つようにします。

  2. 情報を表すのに適切なマークアップ言語がある場合、そちらを利用します。たとえば数式に関しては MathML を、文章や制御レイアウトなどの整形にはスタイルシートを利用するようにします。また、文章を画像で提供することは避け、代わりに文章とスタイルシートを組み合わせて利用します。

  3. 規格化されている正式な文法に則って文書を作成します。たとえば、XHTML 1.1 DTD などです。また、この際、正しく文書型宣言を行うようにします。

  4. レイアウトや表現の制御にはスタイルシートを利用します。HTML の font 要素の利用を避け、CSS の font プロパティなどを利用するようにします。

  5. マークアップ言語の属性、スタイルシートのプロパティには絶対値の利用を避け、相対値で指定するようにします。CSS などの場合には、pt や cm といった絶対単位では指定せず、em やパーセンテージによる指定を行うようにします。絶対値で指定する場合、妥当性の検査を行っておくことが必要です。

  6. フォント効果、レンダリング効果などを期待して h1~h6 要素、blockquote 要素、ul 要素、ol 要素、dl 要素などを利用してはいけません。論理的整合性が失われます。

  7. 表を適切に解釈してレンダリングすることができないユーザエージェントを想定し、表によるマークアップを無視して解釈した際に適切な順序を保持できない場合を除き、レイアウトのために表を使用しないようにします。それができない場合には、同等の代替となるものを提供します。

  8. 表をレイアウトのために利用する場合、構造を示す要素を視覚的な表現を期待して利用してはいけません。HTML の仕様書では、th 要素などがどのようにレンダリングされるかを規定していません。

  9. スクリプトやアプレットで、イベントがデバイスに依存しない構成にします。これは全てのデバイスに対応することを要求するものではありません。

  10. フレームを利用できないユーザエージェントのために、noframes 要素を提供します。

  11. 動的なコンテンツをアクセスできるようにするか、もしくは代替手段で提供します。場合によっては、クライアントサイドスクリプトよりも、サーバサイドスクリプトの方が有効な場合もあります。

  12. スクリプト、アプレット、プログラム的なオブジェクトを使用できないことによりサービスや情報の提供に重要ではないものの問題が発生する場合、直接実行を可能にするか、または代替的な手段により同等のサービスや情報を提供します。

  13. 独自のインタフェースを持つ要素は、デバイスに依存しない方法で動作できることを保証します。

  14. スクリプトでは、独自デバイスに依存するイベントではなく、論理的なイベントハンドラを利用します。これにより、ユーザアクションなどが抽象化され、似たようなアクションに対してまとめて処理を行えるようになります。例えば、フォームの submit ボタンに対して onclick イベントを使用するよりは、フォームの onsubmit イベントを使用します。

  15. W3C で提供されている技術で、作業にとって適切であり、なおかつ最新のバージョンが利用可能であるならば、それを使用します。

  16. 破棄された要素、もしくは破棄されるとされた W3C 技術の利用は避けます。例えば font 要素は XHTML 1.1 で完全に破棄されました。また、XHTML 1.1 において、style 要素及び style 属性は破棄される要素とされましたので、これらの使用を避けます。

  17. フレームを利用する目的とフレーム間の関係が title 属性だけでは理解しにくい場合、longdesc 属性などを利用してユーザによりはっきりとした説明を提供します。

  18. select 要素の内容は option 要素を optgroup 要素に含めることでグループ化する、form 要素の内容は fieldset 要素と legend 要素を利用してコントロール群をグループ化する、といった形で、情報の大きなカテゴリを、よりユーザにわかりやすい形で小さくまとめるようにします。

  19. フォームのコントロールにはラベル (label 要素) を付け、for 属性を利用して関連付けを明示的に指定します。

  20. リンク部分を示す文字列は、リンク先の内容を分かりやすく提供するようにします。例えば「ここ」や「こちら」といった文字列はリンク先の内容が分からないため、「W3C」や「FreeBSD 4.4-RELEASE のリリース情報」といった文字列を使用します。

  21. 文書やサイトに意味情報を追加するメタデータを提供するようにします。HTML の link 要素や RDF といった情報を提供することで、こうしたメタデータをユーザへ提供します。

  22. サイトマップや目次など、サイト全体のレイアウトを示す情報を提供します。サイトレイアウトを説明する際、アクセスに利用できる機能を強調表示して説明します。

  23. ナビゲーションの機構は、サイト全体で一貫した方法で提供するようにします。

ユーザエージェントが対応するまでは対応されるべき項目 - 優先度 2

  1. ユーザが自由に点滅を制御できるようになるまで、コンテンツの点滅を行わないようにします。blink 要素による点滅は HTML の仕様に含まれていません。使わないようにしましょう。

  2. ユーザがコンテンツの移動を制御できるようになるまで、コンテンツの移動は行わないようにします。marquee 要素による移動は HTML の仕様に含まれていません。使わないようにしましょう。

  3. ユーザがリソースの自動更新を制御できるようになるまで、コンテンツ自身によるコンテンツの自動更新は行わないようにします。

  4. ユーザが自動リダイレクトの機能を制御できるようになるまで、スクリプトなどを利用したコンテンツのリダイレクトは行わないようにします。代わりにサーバ側のリダイレクト機能を利用しましょう。

  5. ユーザが新しくウィンドウを作成されたりしないようにできるようになるまで、ポップアップウィンドウや他のウィンドウを表示しないようにしましょう。また、現在のウィンドウをユーザに通知せずに変更してもいけません。

  6. ラベルとフォームコントロールの明示的な関連付けをサポートするまで、ラベルが関連付けられているすべてのフォームコントロールについて、ラベルが適切な位置に表示されるようにします。

対応されることが望ましい項目 - 優先度 3

  1. 文章によって提供される情報が、色を判別する能力が弱い方や、モノクロなどの判別できない環境でも十分に判別可能な前景色、背景色のコントラストを持つようにします。具体的には、文字色を白にした場合には背景色に暗い色を使用し、明度の高い色を設定しないようにします。

  2. 文書中で省略語や頭字語が現れた際、省略されない単語を明示して何の省略であるかを明示します。省略語には abbr 要素を、頭字語には acronym 要素によるマークアップを施します。

  3. 文書の主となる自然言語を指定します。HTML や XHTML 1.0 では lang 属性を、XML や XHTML 1.1 では xml:lang 属性を利用します。

  4. 表の要約を提供します。HTML の場合には summary 属性を利用します。

  5. 見出しセル (th 要素) の省略語 (abbr 属性) を提供します。

  6. リンク、フォームのコントロール、オブジェクトに対してはタブ順序 (tabindex 属性) を指定します。

  7. 重要なリンク、フォームコントロール、フォームコントロールのグループへキーボードショートカット (accesskey 属性) を提供します。

  8. ユーザ自身の嗜好 (言語、コンテンツの種別) に合わせた文書を入手できるようにします。可能ならば、コンテントネゴシエーションを利用します。

  9. ナビゲーション機構をユーザへ明示し、ナビゲーションバーによってアクセスできるようにします。

  10. 検索機能を提供する場合、ユーザのレベルや設定に合った複数種の検索ができるようにします。

  11. 見出し、段落、リストなどの先頭に区別するための情報を配置するようにします。

  12. 文書群に関する情報を提供します。link 要素による rel 属性や rev 属性により情報を提供したり、一連の文書群を書庫 (tar や zip など) により提供します。これにより、オフラインブラウジングしやすくすることができます。

  13. 複数行に渡るアスキーアートを読み飛ばせる手段を提供します。

  14. 画像や音声情報などにより、文章をより理解しやすくすることができます。

  15. 文書間で一貫した表現を作成するようにします。

ユーザエージェントが対応するまでは対応することが望ましい項目 - 優先度 3

  1. クライアントサイドイメージマップと同等のサービスを提供する文章によるリンクが、ユーザエージェントによって適切にレンダリングされるようになるまで、クライアントサイドイメージマップのアクティブな領域に対して文章によるリンクを提供します。

  2. 正しくレンダリングされるようになるまで、表を無視して解釈されても正しい順序で提供されないレイアウト目的の表には、表を無視して解釈されても正しい順序となる代替的なリソースを提供します。

  3. 空のコントロールを正しく取り扱うことができるようになるまで、編集ボックスと文章領域には標準の場所を維持するための文字列を入れておきます。

  4. ユーザエージェントが正しく隣接するリンク領域を取り扱えるようになるまで、隣接するリンクの間にはリンク部分とならない印刷可能な文字を入れておきます。

  5. グループ化された関連するリンク項目群を、ユーザエージェントに対してこれらを識別させることができるようになるまで、グループ化されたリンクへバイパスする方法を提供します。

最後に

ここにまとめられた内容は、結局のところ、誰もが制作者の作成した文書やサービスに、自由にアクセスできるようにする様にしよう、というものです。これは個人サイトから企業サイトなど、あらゆるサイトに適用されるものです。WWW サーバ上で公開されている文書は普通、誰かに見てもらうために、読んでもらうために提供されるものでしょう。しかし、自らユーザに対して扉を閉ざしてしまっては意味がありません。

より沢山の人にアクセスしてもらう為には、アクセスしやすくなるように気をつける。それこそがアクセシビリティを高めるということなのです。

こうしてまとめてみると、当サイトの文書群もさほどこの要件を満たしているとは言えない気がします。特に、優先度 2 の要件はほとんどを満たしていないように感じられました。

現在、Web Content Accessibility Guidelines は 2.0 を策定している段階です。今後も、よりアクセスしやすいコンテンツ作成を心掛けていきたいと思います。