仙台地域における検討成果
「ウェブアクセシビリティ確保に向けての目標」

【1の解説へ】

【1のチェックポイント】

• 画像にはalt属性を必ず付けます。alt属性は単に付けるだけではなく、それを音声で読み上げたとき内容がきちんと理解できるように分かりやすい言葉で記述します。
• 音声や映像などマルチメディア情報の場合は、その内容を表現する文字情報もあわせて提供します。
• 背景色と文字色には、区別し易い（文字が読みやすい）色の組合せを使います。
• フレームは使用しません。
• 文字や画像などの色の違いに頼った表現はしません。
• PDFファイルだけで情報を提供しません。PDF以外の方法でも内容が伝わるように配慮します。ワードや一太郎など、特定のアプリケーションだけに依存したファイル形式を用いるときも同様にします。
• 文書の基本となる文字コードや自然言語を明示します。自然言語については、文書中で切り替わるつど、それを明示します。
• テーブル（表）を使う場合には、セルごとあるいは行ごとに読み上げられても、それを聞いて内容が理解できるようにレイアウトします。
• 体裁を整えるために単語内にスペースを挿入したり、文章の途中で強制改行を行いません。
• リンクを設定している言葉や文章は、リンク先が明確に区別できる表現で記述します。またリンクを設定している画像のalt属性も同様にリンク先が明確に区別できる表現で記述します。

【2の解説へ】

【2のチェックポイント】

• ウェブでこの情報を誰に発信する必要があるのかをよく考え、アクセスユーザが目的の情報を容易に探し出せるようなサイト構成・ページ構成となるよう心がけます。
• ページ毎に適切なタイトルを付けます。
• サイト内で一貫したナビゲーションのための仕組み（位置情報、ナビゲーションバー、サイトマップなど）を提供します。
• 特定の目的を持たせる言葉（戻る／Backや進む／Next、トップへ／ホームへ等）は、サイト全体で統一して使用するようにします。
• ページの内容は適切なまとまりに分類し、分かりやすい見出しを付けるようにします。なお、見出しを正しくマークアップすることで文書を構造化します。
• １ページの情報量は、あまり大きくなりすぎないようにします。もし多くのスクロールが必要になってしまった場合には、必ず目次を用意し、目次と本文とを相互に行き来できるようにします。
• 情報の内容によって図やグラフ等で示した方が視覚的に分かりやすい場合には、むしろ図やグラフ等を使って表現するようにしますが、その場合は必ず代替の伝達手段も提供します。
• パソコン用語をはじめ外来語を多用せず、分かりやすい日本語を使って、明瞭かつ簡潔で、正しい文章を書くようにします。
• 例えば同じ項目なのにページ毎に内容が違っていて読者（アクセスユーザ）を混乱させてしまうことなどが生じないように、関連するページの整合性をきちんと点検します。

【3の解説へ】

【3のチェックポイント】

• コンテンツの作成にあたっては、HTML4.01、XHTML1.0などのDTD（文書型定義）を守り、そのDTDをDOCTYPEで宣言します。
• head要素には文書タイトルや各種メタ情報、連絡先をきちんと記述します。特に文字コードの指定は必ず行います。
• 見栄えなどの表示方法を制御するためには、スタイルシートを使用します。ただしスタイルシートが適用されない場合でも内容が伝わるように、正しく構造化されたコンテンツを作成します。
• フォントサイズを絶対単位で指定しません。その他、表示サイズや位置を指定する場合には、相対的な指定を行います。
• 機種依存文字（丸数字やローマ数字など）は使用しません。
• ASCIIアートや顔文字は使用しません。
• 新しいウィンドウが自動的に開くようにはしません。ただし、一時的に別ウィンドウに表示させた方が良いと判断される場合には、必ずアクセスユーザに新しい別ウインドウが開くことを知らせ、また開いたウインドウが一時的ウィンドウであることを分かるようにします。
• 画面上のアイコンや文字を明滅（点滅）させることや、内容自体（文字等）も自動的に更新・スクロールさせることはしません。
• BGMなどの音声や映像が自動的に再生するようにはしません。
• １ページとして表示される全ファイルの合計サイズは、大きな画像を使わないなど、なるべく小さくするように心がけます。ダウンロードデータを提供する場合も同様です。

【理由】

WWW（ワールドワイドウェブ、以下ではウェブと略称します）は、高齢者や障害がある人たちにとっても重要な情報源になっています。例えば全盲の人はウェブによって、その量や入手のタイミングも健常者と変わりなく必要な情報にアクセスすることが可能となりました。

では、全盲の人はどのようにウェブにアクセスしているか知っていますか？

もちろん彼らは、HTMLで表現されたコンテンツを見ることで、そこに記されている情報を把握しているわけではありません。ウェブのコンテンツに書かれているテキスト情報を、音声で読み上げてくれるソフトウェア（音声ブラウザといいます）を使い、耳で聞いて理解しています。

したがって、「場所は以下の地図を見てください。」といって地図の画像ファイルを掲載しても、全盲の方には必要な情報を伝えることができません。画像を音声で読み上げるような技術が無いから当然です。

そこで、ウェブコンテンツを作る際には、必要な情報を画像だけで伝えようとしてはいけません。画像には必ず代替テキストを付けるといった配慮が必要となります。これは、全盲で音声ブラウザを利用しているウェブアクセスユーザへの配慮としての一例です。

ウェブで情報を発信するということは、情報を伝えたい、あるいは伝えなければならないという要求なり必要性があるはずです。

したがってウェブで情報を発信する人は、どのような人達がいて、どのような手段で自分の発信している情報にアクセスしているかをよく知り、すべてのウェブアクセス者に対して必要な情報を必ず伝えられるようにウェブコンテンツを作る必要があります（情報伝達の保証）。

ステップ１：

まずは以下のウェブサイト等で、どのようなウェブアクセスユーザがいるのかを理解しましょう。

• みんなのウェブ「高齢者・障害者がウェブを利用するときの問題点」
• 日立製作所デザイン本部「Webユニバーサルデザインガイドライン」
• マイクロソフト「アクセシビリティWebサイト／障害別ガイド」

ステップ２：

すべてのウェブアクセスユーザに必要な情報を必ず伝えられるよう、以下のチェックポイントを遵守してコンテンツを作ります。

【各チェックポイントの解説】

(1) 画像にはalt属性を必ず付けます。alt属性は単に付けるだけではなく、それを音声で読み上げたとき内容がきちんと理解できるように分かりやすい言葉で記述します。

［理由］

音声ブラウザやテキストブラウザを使っているユーザは、画像情報を認識できません。alt属性で指定される代替テキストがないと、そこに何が表示されているのかがわかりません。意味のない画像であれば必要ないのですが、その場合は明示的に省略して下さい。ただ画像があることだけしか分からないのでは、とても不安な気持ちになります。

［対応のPoint!］

• すべてのIMG要素に、alt属性は必須です。
• リストの先頭に置くワンポイント画像など、意味のない画像でも必ずalt属性は必要です。しかし読み上げては逆に煩わしい意味のない画像の場合には、alt=""（あるいはalt=" "(半角スペースあるいは全角スペース)、alt="＊"等）とします。
• ただし、リンク画像には必ずリンク先が分かるaltテキストが必要です。
• alt="地図"とかalt="グラフ"では意味が通じません。どのような道順を表す地図なのか、どのような結果を示すグラフなのかの説明が必要です。説明が長くなる場合には、alt属性ではなくlongdesc属性を使い説明文へのリンクを埋め込むか、あるいは画像からあまり離れていないそのコンテンツ内に、直接テキストで画像を代替する内容を記述するようにします。

(2) 音声や映像などマルチメディア情報の場合は、その内容を表現する文字情報もあわせて提供するようにします。

［理由］

聴覚障害者は、オーディオファイルなど音声情報の内容が理解できません。また画像同様に、視覚障害者には映像情報の内容が理解できません。

［対応のPoint!］

• 音声情報では、同等の内容が記されたテキストを用意します。もし時間の流れを伴う映像と同期させる必要がある場合などでは、その映像のトラックと同期する字幕をSMIL技術（脚注）などで実現します。
• ムービーやアニメーションなど映像情報では、同等の内容が記されたテキストを用意します。もし時間の流れと同期する必要がある場合には、映像トラックの音声による説明などを実現します。

(3) 背景色と文字色には、区別し易い（文字が読みやすい）色の組合せを使います。

［理由］

日本人の1割以上の人が、ある色とある色の組み合わせが判別できない、または判別しにくいという、何らかの色覚障害を持っていると言われています。また、高齢になるにつれ色の識別が困難になることがあります。こうした人達にとっては、地の色と文字の色のコントラストが低いと文字が読みづらいため、内容の理解が困難になります。区別し易い色の組合せを使うように心がけます。ただし、コントラストをはっきりさせるために派手な色遣いをしたり模様の入った背景画像を使ったりしますと目が疲れますので、また注意が必要です。

［対応のPoint!］

• 文字が読みやすく、かつ目に負担のかからないような配色を心がけてください。簡易的にコントラストを確認するためのツールとして「カラーコントラストチェッカー」などが公開されています。
• 背景画像を使う場合には、複雑な模様など、文字が読み難くなるような画像を使ってはいけません。

(4) フレームは使用しません。

［理由］

フレームに対応していないブラウザでは、内容を正しく表示できません。また音声ブラウザでは、フレーム内ページごとを独立したページとして扱うため、フレーム間を行き来するのが難しくなります。NOFRAMES要素を使っての対応も可能ですが、完全に同期させることが実際は困難ですので、最初から使わないようにします。

(5) 文字や画像などの使用にあたって、色の違いに頼った表現はしません。

［理由］

テキストブラウザや音声ブラウザを使っている場合、あるいは色覚に障害のあるウェブアクセスユーザは、色の違いを認識できません。そうした場合に、例えば「時刻表の赤字は特急です」といった色によってしか区別できないような表現をされると、内容をまったく理解することができません。

［対応のPoint!］

• 色の違いだけに依存する表現を使ってはいけません。注意を促すためなどに色を使い分けることは良いことですが、色だけではなく、例えば下線や記号なども併用して、色だけに依存しない表現を使いましょう。
• 特にスタイルシートを使ってリンクテキストの表示をコントロールする場合に、下線を消して色だけに依存するようなことは止めましょう。

(6) PDFファイルだけで情報を提供しません。PDF以外の方法でも内容が伝わるように配慮します。ワードや一太郎など、特定のアプリケーションだけに依存したファイル形式を用いるときも同様にします。

［理由］

PDFはたいへん便利なデータフォーマットです。決して使って悪いわけではありません。ただし、音声ブラウザには対応していませんし（英語版では対応も進みつつあります）、PDFリーダーをすべての人が使っているわけでもありません。

［対応のPoint!］

• PDFファイルを掲載する場合には、テキスト版あるいはHTML版を併せて掲載するようにします。
• PDFファイルにリンクするHTMLのページには、それがPDFファイルである旨と、ファイルサイズを明記するようにします。

(7) 文書の基本となる文字コードや自然言語を明示します。自然言語については、文書中で切り替わるつど、それを明示します。

［理由］

ページの中に文字コードが指定されていない場合に、ブラウザは文字コードを自動判別しますが、常に正しく機能するとは限りません。もし文字化けが発生すると、その制御方法を知らないユーザはページの内容をまったく理解できなくなりますので、文字コードは必ず明示します。また、自然言語（日本語や英語などの文書で使用している言語のこと）をlang属性を用いて明示することにより、音声ブラウザや点字ブラウザは、たとえば同じ綴りをする別の言語の単語でもより正確に変換することが可能となります。

［対応のPoint!］

• HTML文書のヘッダの中にmetaタグを置き、その中に文字コードを記述します。これはmeta要素内のできるだけ先頭に置くようにします。なお、XHTML1.0ではXML宣言で文字セットを指定しますが、古いブラウザとの互換性を考慮してmeta要素でも指定するようにしてください。

  （例）Shift_JISの場合は<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">のようにします。

• 文書内で基本と使用される言語をhtml要素にlang属性で指定します。lang属性の値には、jp（日本語），en（英語），en-US（アメリカ英語），fr（フランス語）,de（ドイツ語）のようなISO639の言語コードを使用します。

  （例）日本語なら<html lang="ja">とします。

• １つのページで複数の異なる言語を使用している場合には、言語が切り替わるたびに、それをlang属性で明示するようにします。

  （例）英単語が出てきた場合に<span lang="en">sunflower</span>とします。

(8) テーブル（表）を使う場合には、セルごとあるいは行ごとに読み上げられても、それを聞いて内容が理解できるようにレイアウトします。

［理由］

音声ブラウザでは、テーブルはセル（脚注）ごとに、行の左から右に向かって一行ずつ読み上げます。もしレイアウトにテーブルを使っている場合、最も重要な情報に行き着くまでにたいへんな寄り道をしなければならないことがあります。また、適切なタグ付けがなされていない見出し項目数の多いテーブルは、読み上げられているうちに見出し項目間の関連づけが理解できなくなってしまうため、内容を把握することが非常に困難です。

［対応のPoint!］

• レイアウトにテーブルを使う場合には、読み上げられる順番に配慮して、そのページの主たるコンテンツを配置するようにします。またセル内では、適切に文章を構造化するようにします。文書の構造化により適切に見出し付けされていると、音声ブラウザを使っていても見出しの飛ばし読み機能が使えれば、より主目的の情報に到達し易くなります。
• データ表の場合には、caption要素で表題やsummary属性で要約を付けるようにしてください。これにより、データ表を視覚的に確認できない人に対しても、内容をより正しく伝えることができるようになります。レイアウトに使っている場合でも，summary属性をつけるようにします。summary属性でテーブルの構造を書き記しておけば、ユーザが必要に応じて参考にすることができます。
• データ表では、行ごとに読み上げられても内容が理解し易いように、行列の配列を工夫します。
• データ表では、データセルとヘッダを明確に区別できるよう、TD要素とTH要素を使い分けるようにします。

(9) 体裁を整えるために単語内にスペースを挿入したり、文章の途中で強制改行を行いません。

［理由］

文書の体裁を整えるために、氏名という漢字が「氏　名」のようにスペースを入れて記載されていたり、br要素を使って強制改行されていることがあります。しかしこれを音声ブラウザなどで読み上げると、文字が離れていたり改行されているために一つの単語や文節と認識されず「し」「な」等と一文字ずつ読み上げられ、意味が通じなくなります。したがって、文書の体裁を整えるために、単語内や文章の途中にスペースや強制改行を置いてはいけません。

(10) リンクを設定している言葉や文章は、リンク先が明確に区別できる表現で記述します。またリンクを設定している画像のalt属性も同様にリンク先が明確に区別できる表現で記述します。

［理由］

テキストブラウザや音声ブラウザでは、操作の効率性を高めるために、ページ内のハイパーリンクが設定された部分だけを抽出して一覧表示してくれる機能があります。これは目次としての役割を果たすため、このようなブラウザを使っている視覚障害者にとっては、たいへん便利な機能です。また音声ブラウザを使っている場合には、一度ページ全体を読み終えたのち、再度ハイパーリンク部分だけを飛ばし読みしながら次に進むページを探すという使われ方がされます。

しかし、例えば「ここではAの要件が、こちらではBの要件が確認できます。」といったコンテンツでは（"ここ"と"こちら"がハイパーリンクの場合）、リンク先一覧として「ここ」「こちら」しか示されないため、それぞれのリンク先の区別がつきません。

リンクを示すテキストだけを読んでも、そのリンクの行き先がわかるようにコンテンツを作成します。ただし、あまり長い記述は適しません。

【理由】

ウェブでは内容の更新が容易に行えるため、情報発信者側にとってはとても便利な情報伝達手段と言えます。ただし紙媒体とは違い、ユーザはウェブページ全体にレイアウトされた情報をディスプレイという限られた表示範囲を移動させながら見たり読んだりしなければなりませんし、複数のページを同時に広げて見比べたりすることがほとんどできないため、内容の全体像を把握するには難しい媒体と言えます。これはディスプレイにHTMLを表示させるブラウザでのことですが、音声ブラウザや点字ディスプレイを使っている場合には、もともと一度に把握できる情報が限られますので、なおさらです。

さらに、記憶が衰えがちな高齢者や知的障害のある方、子供達、あるいは音声ブラウザや点字ディスプレイを使っているユーザにとっては、数多くのページが相互に複雑にリンクしあって構成されるウェブサイトの仕組みが原因となって、自分の今いる位置を見失いがちです。そのため、目的の情報に辿り着くことが困難であったり、以前訪ねた場所（ページ）に戻ってくることもままならない状況が発生します。

こうした原因により、ユーザはたびたび目的の情報を探し出すまでに多大な労力と時間を費やさなければならない状況に陥り、場合によっては目的の情報に到達する前にその探し出そうとする行為を止めてしまいます。

そうすると、情報発信者側は情報を発信するという目的なり必然性を果たすことができないばかりか、そのユーザは二度と自サイトを訪れてくれないかもしれません。これは、サービスの低下だけでなく、ひいては信頼の失墜にもつながります。

その情報を発信する意義と目的をよく考え、ユーザが求める情報を容易にかつ的確に把握できるよう、ウェブサイト内のページの構成やページ内のレイアウト、コンテンツの配置やその内容、段落のまとまりや見出しの付け方などにも注意して、分かり易いコンテンツづくりを目指しましょう。

【各チェックポイントの解説】

(1) ウェブでこの情報を誰に発信する必要があるのかをよく考え、アクセスユーザが目的の情報を容易に探し出せるようなサイト構成、ページ構成となるよう心がけます。

［理由］

ウェブでの情報発信の場合には、あくまでアクセスユーザに主体的に情報を見つけ出してもらわなければなりません。アクセスユーザが目的の情報を容易に探し出せるよう、ユーザの立場からコンテンツの分類構成を考え、サイトを構築しまた内容を記述する必要があります。

［対応のPoint!］

• まずは最初にサイトの全体像あるいはページの全体像が把握でき、概要から順次詳細な内容へと繋がる構成がユーザの理解を助けます。
• 利用者がどのような期待（目的）からサイトを訪れているかを考えてください。会社の組織にあわせてコンテンツを分類構成したため、ユーザにとってはとても分かりにくいというサイトがよくあります。ユーザにとっては、その会社が提供してくれるサービスが重要なのであって、そのサービスがどの部署の担当であろうと通常は関係ありません。
• サイトを構成するページの階層をあまり深くしてはいけません。通常は深くても3〜4階層程度にとどめるのが妥当でしょう。

(2) ページ毎に適切なタイトルを付けます。

［理由］

音声ブラウザでは、現在自分がいるページを知りたいときや、以前に見たページの履歴を確認するときに、ページのタイトルを頼りにします。複数のページに同じようなタイトルがついていたり、タイトルが適切でないときには、自分がどのページにいるのかがわからなくなります。

［対応のPoint!］

• タイトルだけ読んでも内容がおおよそ想像できるよう、適切かつ簡潔なタイトルを付けます。
• ページのタイトルは、サイト内で必ずユニーク（唯一）なものにします（同じものが無いようにします）。そのためには、どのような上位の情報に含まれるページなのかを明確にするようにします。たとえば「製品の詳細スペック（脚注）」としても、どの製品のスペックか分からなくなってしまいます。「何々型番製品の詳細スペック」とすべきです。一般的に使用されるページタイトルでは、サイトの固有名称も明示するようにします。たとえば「サイトマップ」というページタイトルでは、ブックマーク（脚注）をするとどのサイトのサイトマップか分からなくなってしまいます。「何々サイトのサイトマップ」あるいは「サイトマップ：何々サイト」などのようなタイトルを付けるのが適切です。

(3) サイト内で一貫したナビゲーションのための仕組み（位置情報、ナビゲーションバー、サイトマップなど）を提供します。

［理由］

サイトマップや目次など、サイト全体の構成についての情報があれば、目的の情報にたどり着きやすくなります。またナビゲーションバー（脚注）などにより、いま自分がサイト内のどこにいるのかが明示されることで、複雑に相互にリンクされたサイトの中でも、比較的容易にページ間の関係が把握でき、次に進みたいページを見極めることができます。

ただし、サイト内で一貫したルール（形や表示される場所など）でその仕組みが提供されないと、ユーザが使用する際に戸惑う原因となります。

［対応のPoint!］

• サイト内で使用する共通テンプレート（脚注）を先に作りましょう。

(4) 特定の目的を持たせる言葉（戻る／Backや進む／Next、トップへ／ホームへ等）は、サイト全体で統一して使用するようにします。

［理由］

ページによって同じ言葉が違う目的で使われていると、ユーザが混乱します。また、ページによって同じ概念を違う言葉で呼ぶことも、ユーザの混乱につながります。たとえば、ホームページへ戻るためのリンクボタンに「トップ」「TOP」「ホームページ」「HOME」のような様々な画像やリンクテキストを混在して使ってはいけません。

［対応のPoint!］

• ページを作り始める前に、基本的な単語については一覧表を作って、一貫してその単語を使うようにします。

(5) ページの内容は適切なまとまりに分類し、分かりやすい見出しを付けるようにします。なお、見出しを正しくマークアップすることで文書を構造化します。

［理由］

いろいろな情報が混ざり合って記述されている文章や、非常にたくさんの文字がいっぱい詰め込まれたコンテンツは、たいへん読みにくく、ユーザがその情報を理解するのが容易ではありません。（マークアップについては脚注を参照してください。）

［対応のPoint!］

• ページ内の文章は、適切な大きさの節や段落で構成されるよう記述します。また、それぞれの節や段落には、簡潔で分かりやすい見出しを付けます。
• 文章のそれぞれの見出しには、正しく入れ子化された見出し要素をタグ付けします（h1要素の中にはh2を、h2の中にはh3という順番を守る）。
• 見出しを画像で表示しようとする場合にも、その部分のimg要素を適切な見出し要素（h1要素やh2要素など）で囲むようにします。ページの主たる見出し（タイトル）をページトップに画像で記載することがありますが、その場合にはその画像にh1要素を適用することが可能です。

(6) １ページの情報量は、あまり大きくなりすぎないようにします。もし多くの画面スクロールが必要になってしまった場合には、必ず目次を用意し、目次と本文とを相互に行き来できるようにします。

［理由］

１ページ内の情報量が多すぎると、長いあいだ集中力の持続が必要で、ユーザがその情報を理解するのが容易ではありません。また、肢体不自由などの理由により画面をスクロール（脚注）するという操作が難しいユーザもいます。

［対応のPoint!］

• １ページが、あまり長くなりすぎないようにします。ただし、たくさんのページに情報が分散しすぎても、移動の操作をしたり印刷をするには不便になってしまうので注意が必要です。
• １ページがどうしても長くならざるを得ない場合には、ページの先頭にページ内の各見出しにリンクする目次を用意し、本文中には適当な位置ごとに目次へ戻るリンクを設置することで、目次と本文とを相互に行き来できる手段を提供します。

(7) 情報の内容によって図やグラフ等で示した方が視覚的に分かりやすい場合には、むしろ図やグラフ等を使って表現するようにしますが、その場合は必ず代替の伝達手段も提供します。

［理由］

情報の内容によっては、図やグラフ等で示した方が視覚的に分かりやすいということがあります。ただし、音声ブラウザやテキストブラウザを利用しているユーザもいますので、必ず同等の役割を果たすテキストをつけるなど、情報を伝える代替手段を提供するようにします。

(8) パソコン用語をはじめ外来語を多用せず、分かりやすい日本語を使って、明瞭かつ簡潔で、正しい文章を書くようにします。

［理由］

インターネット上の情報量は非常に膨大で、その中から必要な情報を見つけだすことがたいへんな作業となる場合があります。コンテンツがアクセスユーザにとって分かり易く、明瞭かつ簡潔で、正しい文章で書かれていることで、情報がより伝わりやすくなります。

［対応のPoint!］

• ホームページでは、「NEXT」「INDEX」「HOME」「SITE MAP」といった英語表記が用いられがちですが、パソコン用語や外国語に不慣れなアクセスユーザもいます。もし代替可能でかつ適切な日本語がある場合には、そちらを使うようにします。先の例は、「次に進む」「目次」「トップページへ戻る」「サイトマップ」などに置き換えが可能です。
• アクセスユーザが自分と同じ語彙知識を共有しているとは限りません。普段自分が使っているからといって一般的に馴染みのないカタカナ語を使用すると、ユーザに正しく意味が伝わらない場合があります。もし代替可能な日本語がある場合には、そちらを使うようにします。

  （例）アイデンティティ、インセンティブ、サプリメント、ネチケット、
  　　　　ポータルサイト、ポートフォリオ、コラボレーション、etc

• 外来語と同様に、敢えて難しい漢字を使う必要がない場合は、使わないようにします。
• 文章や段落が長すぎると、主題（テーマ）を把握することが難しくなる場合があります。点や丸を省略せず、文章は読みやすい長さにまとめ、適宜段落を変えるなどして、主題がはっきり伝わるようにします。
• 「〜と予想される」「〜と期待される」といった受動態の表現（受身形）を使いすぎると、文の主体が曖昧になり、内容が正しく伝わらないことがあります。可能な部分では、できるだけ能動態を用いるようにします。

  （例）「alt属性が記述されると、よりアクセシビリティが確保されます。」
  　　　　→「alt属性を記述すると、よりアクセシビリティが確保できます。」

(9) 例えば同じ項目なのにページ毎に内容が違っていて読者（アクセスユーザ）を混乱させてしまうことなどが生じないように、関連するページの整合性をきちんと点検します。

［理由］

例えばコンテンツの更新を繰り返しているうちに、他のページにある関連情報の更新をし忘れて、ページ毎に内容が違ってしまうことがあり得ます。そうすると、読者（アクセスユーザ）に正しく情報を伝えることができません。

［対応のPoint!］

• コンテンツを作成した一番最初は、それを公開する前に再度内容を読み直し不整合がないかを点検しますが、内容を更新した際にも他のページに更新漏れが無いかをよく点検するようにします。
• 同一の内容を、フラッシュ版（脚注）・HTML版・テキスト版などと複数の表現の仕方を用いて提供している場合は、他の版に更新漏れが無いかどうか特に注意が必要です。

【理由】

ウェブコンテンツは、一般的にHTML（Hyper Text Markup Language）という言語で記述されています。これはもともと文書交換を目的とした共通のフォーマットとして開発された言語ですので、基本的にはどのブラウザでも内容把握には問題ないレベルで同じように表示されるはずです。しかし各メーカーが、各社のブラウザを用いた場合のウェブページの表現力を向上させるために、独自要素（タグ）を次々に追加したため、本来の共通性は失われ、ブラウザに依存するコンテンツが溢れ出してしまいました。つまり、特定のブラウザでなければ、内容がきちんと伝わらない状況が発生してしまっています。

そこで、HTMLの標準仕様の策定に取り組む国際研究団体のW3C（World Wide Web Consortium）では、HTML4.0以降、HTMLから表示方法やレイアウトなど表現に関する部分を排除し、表示方法についてはスタイルシートを使用して制御する方針を打ち出しています。

このように、ウェブの世界でも様々な仕様が存在してしまっているため、たとえHTMLで書かれたコンテンツでも、ユーザーエージェントによってはきちんと内容を表示できなかったり、操作できない状況が発生します。こうした問題の発生を最小限に抑えるため、ウェブに関する世界標準として私たちはW3Cのテクノロジー（HTMLやCSSなどの仕様）とガイドラインにしたがってコンテンツ作成するようにします。

ただし、W3Cのガイドラインに完全にしたがったからといって、現時点ではさまざまなユーザエージェントを使用する全てのユーザに不便を強いることはない、とは決して言い切れないということを忘れてはなりません。

【各チェックポイントの解説】

(1) コンテンツの作成にあたっては、HTML4.01、XHTML1.0などのDTD（文書型定義）を守り、そのDTDをDOCTYPEで宣言します。

［理由］

各ブラウザが独自に採用している要素タグを使用すると、他のブラウザではきちんと表示されないことがあります。また、本来の目的以外に要素タグを使用すると、ユーザエージェントによっては適切に変換されず内容が正しく伝わらない場合があります。

［対応のPoint!］

• HTMLにはバージョンごとに、そのHTMLで使うことができる要素や属性と、それをどのように使うことができるかを詳細に定義したDTD（Document Type Definition：文書型定義）があります。
• HTML4.01には、以下の3つのDTDがありますが、フレームを使用しないことを前提に、より厳格なDTDを採用するように心がけます。
  • Strict DTD：

    理想的なHTML4.01の文書を作成したい場合に使用。

  • Transitional DTD：

    非推奨の要素や属性も使うことができますが、フレームは使用することができません。

  • Frameset DTD：

    Transitional DTDに加えてフレーム関連の要素を使うことができます。

(2) head要素には文書タイトルや各種メタ情報、連絡先をきちんと記述します。特に文字コードの指定は必ず行います。

［理由］

音声ブラウザなどでは、DOCTYPEからそこで使用されているDTDを判断し、それにあわせて変換する機能を有しているものがあります。また、必要なメタ情報（脚注）などをきちんと記載しておくことで、ユーザエージェントによってはユーザを補助する機能が有効に作動するようになります。さらにはサーチエンジンが適切に情報を収集できるため、ユーザが目的の情報を見つけ出しやすくなります。

特に文字コードが指定されていないと、文字化けが発生し、対処方法を知らないユーザには、全く内容が伝わらなくなってしまいます。

［対応のPoint!］

• HTML4.01の仕様では、特に標準となるメタ情報（脚注）を定義していません。しかしmeta要素内で文字セットを指定しておくと、古いブラウザなどと互換性が確保されます。また、キーワード（keywords）や内容の要約（description）は多くの検索エンジンで利用されるため、ユーザが目的の情報を探し出しやすくなります。
• 文書全体で使用する共通のテンプレート（脚注）を作成しておくと、記載漏れが少なくなります。

(3) 見栄えなどの表示方法を制御するためには、スタイルシートを使用します。ただしスタイルシートが適用されない場合でも内容が伝わるように、正しく構造化されたコンテンツを作成します。

［理由］

表示方法（レイアウト）の制御は、内容の構造を示すマークアップ（脚注）から分離しスタイルシートにより実現することで、どのようなブラウザでもより正確にコンテンツの内容を伝達・変換することが可能となります。また、ユーザ側が個々の特性に応じて独自のスタイルシートを適用することができるため、最も自分に適した表示条件で閲覧することが可能となります。

(4) フォントサイズを絶対単位で指定しません。その他、表示サイズや位置を指定する場合には、相対的な指定を行います。

［理由］

フォントサイズ（文字サイズ）を絶対単位で指定にしていると、ユーザが自由に変更することができません。デザインが崩れることを嫌いフォントサイズを固定にする場合がありますが、ユーザによって見やすい字の大きさは様々ですし、使っているOSやブラウザ、ディスプレイの解像度などによっても見え方は違ってきます。同様の課題から、その他の属性値でも表示サイズや位置を指定する場合には、相対的な指定を行います。

［対応のPoint!］

• フォントサイズを指定する場合には、pt（ポイント）、pc（パイカ）、mm（ミリメートル）、in（インチ）など絶対的な長さの単位（絶対単位）を用いてサイズを固定することはせず、em（エム）、ex（エックスハイト）などの相対単位を用いるか、％（パーセント）値で相対的に指定します。なお一部のブラウザでは、絶対単位で指定されていてもユーザがサイズを変更できますが、これは例外です。

  （例）スタイルシートを用いて見出し（h2）サイズをパーセント指定する例
  　　h2 { font-size: 150% }

• フォントサイズ以外にも、文字や画像の配置を設定するマージン指定など、表示サイズや位置を指定する場合には相対単位を用います。ただし、ビットマップ画像など出力媒体の物理的特性がわかっているものに対しては、絶対的な長さの単位を使用できます。
• 大きなデータテーブルでない限り、できるだけテーブルの幅をディスプレイの表示範囲内に収め、横スクロール（脚注）が発生しないようにします。そのために、テーブルの幅は％指定するようにします。
• emは一部のブラウザでおかしな挙動を示すことが分かっていますので、当面は使用を避けた方がよいでしょう。

(5) 機種依存文字（丸数字やローマ数字など）は使用しません。

［理由］

機種依存文字は文字化けの発生原因になりますので、使用しないようにします。

［対応のPoint!］

• 機種依存文字とは、「丸付き文字・丸数字」「ローマ数字」「半角の単位記号」などです。
• 半角カタカナも、UNIX環境でダウンロードした場合に文字化けが発生する可能性があるので使わないようにします。

(6) ASCIIアートや顔文字は使用しません。

［理由］

ASCIIアート（文字や記号で表した絵）や顔文字は、そもそもはテキスト情報であるため、そのままでは音声ブラウザや点字ディスプレイを使っている場合に全く本来の内容と異なった内容として伝わってしまいます。

［対応のPoint!］

• 使わないことを前提としますが、どうしても使用したい場合には、代替する内容をテキストで記述するか、代わりとなるテキストファイルを用意し、そこへのリンクを設定します。

(7) 新しいウィンドウが自動的に開くようにはしません。ただし、一時的に別ウィンドウに表示させた方が良いと判断される場合には、必ずアクセスユーザに新しい別ウインドウが開くことを知らせ、また開いたウインドウが一時的ウィンドウであることを分かるようにします。

［理由］

新しいウィンドウが開くことで、それを閉じるという行為が必ず必要となりますが、操作が不自由な人にとってはたいへんな負担となります。またメモリが少ないPC環境では、フリーズ（脚注）の原因ともなります。

さらに、新しいウィンドウが開いたことを目で確認できない人や、目で確認できても新しく開いたウィンドウと今まで見ていたウィンドウの区別がつきにくいため、ユーザが両者を取り違えて認識してしまうことがあり、なぜ突然ブラウザの戻るボタンが使えなくなったのか分からず混乱するといった問題が生じます。

(8) 画面上のアイコンや文字を明滅（点滅）させることや、内容自体（文字等）も自動的に更新・スクロールさせることはしません。

［理由］

画面上のアイコンや文字が点滅したりスクロール（脚注）するなどの動きがあると、認識や視覚に障害がある場合に、その動きに対応できない可能性があります。特にフリッカー（ちらつき）やフラッシュするディスプレイ（脚注）は光過敏性のてんかん発作を引き起こしかねません。

［対応のPoint!］

• blinkやMarquee要素は使わないようにします。
• 一定期間ごとに自動更新するページも作らないようにします。

(9) BGMなどの音声や映像が自動的に再生するようにはしません。

［理由］

操作が不自由な環境にある場合、自動的に再生されるオーディオや映像を停止させることが困難です。また音が聞こえないユーザにとっては、自分が知らないうちに音が流れ出し、まわりに迷惑をかけてしまうこともあり得ます。またBGMは、音声ブラウザを使っている場合に読み上げの声とBGMの音が重なり、内容を理解するのが困難になります。

［対応のPoint!］

• BGMなどの音声や映像を再生させたい場合には、アクセスユーザ自身が再生や停止をコントロールできる手段を提供します。

(10) １ページとして表示される全ファイルの合計サイズは、大きな画像を使わないなど、なるべく小さくするように心がけます。ダウンロードデータを提供する場合も同様です。

［理由］

細い回線でアクセスしている場合には、ファイル容量が大きいと表示されるまでに時間がかかり、ユーザは必要な情報になかなか到達できません。またユーザに対して、そのかかった時間に応じた通信費の負担を強いていることを認識する必要があります。

【理由】

先にウェブの標準仕様としてW3Cテクノロジーとガイドラインに沿ってコンテンツを作成することとしましたが、一般に使われているブラウザでは、未だにW3Cテクノロジーがきちんと反映されないことが多いのが現実です。そのため、きちんとしたHTMLでコンテンツが作成されていたとしても、ブラウザごとに表示が大きく異なってしまい、デザイン云々以前の問題として、きちんとした表示がなされない問題が発生することがあります。

また逆に、ブラウザによってはW3Cの仕様にあわない間違ったタグ付けがなされていても、見栄え上は問題なく表示されてしまうことがあります。そのため見た目は変わりなくても、コンテンツ制作者の意図するところとは別の挙動を示すコンテンツになってしまっていたりすることがあります。なお、視覚的ブラウザでは問題なく表示されていたとしても、音声ブラウザなど他のブラウザでは、内容がきちんと伝わる形で再現されるとは限りません。

さらに、アクセシビリティにいくら配慮してコンテンツを作成したとしても、HTMLのソースはたいへん複雑ですので、全ての対処必要項目に対して確実に対応することは、たいへん困難です。

こうした問題の発生を避けるためには、自動的に問題箇所を発見・指摘してくれるツールを使って、作成したコンテンツを機械的にチェックすることが効果的です。こうした便利なツールが、インターネット上ではいくつも無償で公開されています。

【各チェックポイントの解説】

(1) コンテンツを公開する前に、ツールを使って構文チェックを実施します。

［対応のPoint!］

構文チェックのツールには以下のようなものがあります。

• Another HTML-lint（日本語）
• W3C HTML Validation Service（英語）
• W3C CSS 検証サービス（日本語）

(2) コンテンツを公開する前に、ツールを使ってアクセシビリティのチェックを実施します。

［対応のPoint!］

アクセシビリティをチェックできるツールには以下のようなものがあります。

• ウェブヘルパー（日本語）
• BOBBY（英語）
• A-Prompt（英語）

(3) コンテンツを公開する前に、いろいろなブラウザからコンテンツにアクセスし、正しく表示されるか等をチェックします。

［対応のPoint!］

以下のようなブラウザで確認します。

• インターネットエクスプローラー
• ネットスケープナビゲーター
• 音声ブラウザ（IBMホームページリーダー、ボイスサーフィンなど）
• テキストブラウザ（Lynx for Win32 (by patakuti)、w3m、Another HTML-lintのLynxやw3mでの見え方表示機能）