WAIアクセシビリティガイドライン: ページ制作


W3C   WD-WAI-PAGEAUTH-0414

WAIアクセシビリティガイドライン:
ページ制作

W3Cワーキングドラフト     1998年4月14日

このバージョン(原文):
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0414
最新のバージョン:
http://www.w3.org/TR/WD-WAI-PAGEAUTH
以前のバージョン:
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0413
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0410
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0203
編集者:
Gregg Vanderheiden, Trace Research and Development
Wendy Chisholm, Trace Research and Development
Ian Jacobs, W3C
 
協力者の完全な一覧は付録の謝辞の節をご覧ください。

この文書の位置づけ

これはW3C会員およびその他の利害関係者による検討のためのW3Cワーキングドラフトです。この文書はドラフト文書であり、何時にても他の文書によって更新され、置換され、あるいは廃止される場合があります。W3Cワーキングドラフトを参照資料として利用したり「進行中の作業」以外のものとして引用することは不適切です。これは進行中の作業であって、W3CやWAI GLワーキンググループによる裏書きや合意を示すものではありません。

この文書は W3C WAI Activity の一部として生み出されており、アクセシビリティの高いウェブページを制作するための提案勧告の草稿として意図されています。WAI-GL ワーキンググループの目標は私達の憲章の中で論じられています。

概要

この文書は、自分のページを障害のある人々にとってよりアクセス性が高くインデックスロボットに対してより有益にするためにHTML制作者が従うべきマークアップのガイドラインの一覧です。ガイドラインの一覧に続いて、制作者やウェブマスターがページのアクセシビリティを確認するために使うべきチェックリストがあります。HTMLで書かれた文書を生成するツール(オーサリングツール、ファイル変換パッケージその他の製品)は、これらのガイドラインに従った文書を生み出すべきです。この文書は Web Accessibility Initiative によって公開されている一連のアクセシビリティ文書の一部です。

コメント

この文書についての詳細なコメントを w3c-wai-gl@w3.org までお送りください。WAI制作者ガイドラインに関する公開のコメントもこのメーリングリストに送ることができます。

注意. このページはスタイルシートを使用しているため、印字上の問題に遭遇している方々もいます。私達は問題を訂正するように努力していますが、そうした方々には私達の解決策の調査を助けてくださるようお願いします。


目次

イントロダクション
格付け、分類
1. スタイルと構造
2. 画像、イメージマップ
3. アプレット、スクリプト
4. オーディオ、ビデオ
5. テーブル(組み表)
6. リンク
7. フレーム
8. ユーザ入力フォーム
9. 万策尽きたら...
10. よいウェブサイト設計慣習
付録 A - テーブルの例
付録 B - 代替テキスト制作ガイドライン
チェックリスト
謝辞
参照資料

イントロダクション

この文書は、HTML制作者がそのページのアクセシビリティを向上させるために従うべきガイドラインを勧告するものです。ガイドラインの中には HTML 4.0 の機能を利用するものもありますが、多くはそれ以前のバージョンのHTMLにも同様に当てはまります。

アクセシビリティ改良のための方法は、大まかに以下のカテゴリーに分かれます。

構造
表現のために使われるマークアップを大量に含み、構造を伝達するためのマークアップを充分に含んでいないHTML文書は、非視覚的ユーザについてアクセシビリティの問題を課します。制作者は、HTML構造的マークアップを使って意味を伝達し、ページの整形やフォーマットのためにはスタイルシートを使うべきです。
操作性
制作者は、キーボードのみでの操作(ハイパーリンクへのアクセス、リンク間の操作、フォームフィールド間の操作、ページ内部やページ間の操作)を可能にし、わかりやすい方向指示(番号つきリスト、タイトルなど)を推進するページを制作するべきです。
代替的フォーマット
制作者はつねに、画像、音声、アプレット、スクリプトを通じて表示される情報にアクセスするための代替的手段を提供するべきです。たとえば、字幕は聴覚的情報を、それを聴くことができない人々にとってアクセス可能な形式で提供します。画像のテキスト的置換は、その内容の説明にしても機能の説明にしても、それを見ることができない人々にとってアクセス可能な形式で情報を提供します。

以下のセクションは、HTML制作者がそのページのアクセシビリティを向上させるために使用すべき具体的なガイドラインを提供します。


格付け、分類

各ガイドラインにはその重要性を説明する格付けがついています。

[必須]
必須であり、さもなくば1つまたはそれ以上のグループのユーザがページを理解することが不可能になります。
[推奨]
ページをより利用しやすくしたり、理解しやすくします。

ガイドラインにはそれぞれ、1つまたはそれ以上のHTML(や場合によってはスタイルシート言語)の「戦略」によって実装される場合があります。それぞれの戦略は、その適用の要急性に従って分類されている場合があります。

[暫定]
この戦略は、今日のブラウザや補助的技術についてページをアクセシビリティの高いものにするために必要です。
[新規]
この戦略は、(Web Access Initiative 勧告を取り入れた)明日のブラウザや補助技術に組み込まれている機能を利用します。

分類のついていない戦略は、HTML 4.0 以前のバージョンのHTMLについて、また新旧のブラウザについて機能します。


1. スタイルと構造

  1. [必須]
      HTML 4.0 DTD(文書型定義)、CSS1に従ったエレメントやアトリビュートを使いましょう。
    W3Cは、HTML検証サービスを http://validator.w3.org/ で提供しています。これは、サイトがHTML 4.0 DTD(strinc, transitional, frameset の3つがあります.詳しい情報は検証サービスをご覧ください)のひとつに従っているかどうかを測定するのに使うことができるものです。ページが strict 定義に従うことは、推奨はされますが、現在のところは必須ではありません。

  2. [必須]
      スタイルシートなしでもページが読むことができ利用可能であることを確かめましょう。
    これは、スタイルシートをサポートしていないブラウザや、その機能を切っている人々のためである。スタイルシートは新しい現象なので、古いブラウザはそれをサポートしていないでしょうし、新しいブラウザもそれを標準的な方法でさとポートするまでにはしばらく時間がかかるでしょう。

  3. [必須]
      見出しを適切にネストしましょう。
    ユーザの中には見出しを探索することで文書を流し読みする人もいますから、見出しのレベルが正しく増加する(H1 の後には H3 ではなく H2 が続く)ことが重要です。テキストを大きいフォントでフォーマットするといったような、他の目的のために見出しを使うことは、ユーザを誤った方向に導く場合があります。フォーマットのためにはスタイルシートを使いましょう。注意.  この節の項目9、10をご覧ください。

  4. [必須]
      リスト構造やリスト項目を適切にエンコードしましょう。
    HTMLのリストエレメント (DL, UL, OL, LI) は、リストを作成するためにだけ使われるべきです。字下げといったような表現上の効果のためにリスト項目を使うことは避けましょう。

    [新規] 項目間隔の制御には、HTMLアトリビュートよりもスタイルシートを使いましょう。注意.この節の項目7をご覧ください。

  5. [必須]
      ブリンクやスクロールするテキストは避けましょう。
    [暫定] 制作者は BLINK エレメントや MARQUEE エレメントを避けるべきです。まず何よりも、これらのエレメントはHTML 4.0 の一部分ではありません(特定のブラウザ専用の拡張であり、避けられるべきです.項目1をご覧ください)。次に、点滅したり移動したりするテキストは、画面読み上げ器に正しく読まれないか全く読まれず、逆に認識障害をもつ人々に影響を及ぼし得ますし、一般的に人々にとってうるさいものです(Jared Spool の本 "Web Site Usablity" をご覧ください)。制作者は、スタイルシートを使って、違うフォントやサイズや色といったような他の方法でテキストに注意をひくべきです。

  6. [推奨]
      テキストを画像に変換するよりもスタイルシートを使いましょう。
    たとえば、色つきの背景の上にスタイルづけされたテキストは、画像とする代わりにスタイルシートを用いて作成することが可能です。これは、人々がテキストを、自分が読みやすい形式で見るという柔軟性を提供します。たとえは、色つきの背景の上にスタイル指定されたテキストは、画像の代わりにスタイルシートを用いても作成できます。このことは、人々が、自分のいちばん読みやすい形式でテキストを見るという柔軟性を提供します。テキストを拡大したり、黒背景に白といったような特定の色の組み合わせや特定のフォントで表示することが含まれます。

  7. [推奨]
    レイアウトを強制するのに見えない画像や透明な画像を使うよりもスタイルシートを使いましょう。
    注意. 現在(1998年4月)のブラウザは、絶対的位置指定などといったいくつかの型の位置指定のためのスタイルシートの利用をまだサポートしてません。

  8. [推奨]
      批判を受けている表現エレメントやアトリビュート(B や Iも)の利用は避けましょう。
    制作者は視覚的表現を制御する表現エレメント ( TT, FONT) やアトリビュート ("align", "background") の代わりにスタイルシートを使うべきです。制作者は文書に構造を付加するエレメント(STRONG, EM, H1, H2, ABBR などといったもの)を使うよう勧められます。表現にスタイルシートを使っている文書は、個人的なスタイルシートやブラウザ設定を通じて文書の見かけ(大きな印字、色のコントラストなど)をユーザが調整するできるようにします。

  9. [推奨]
      構造を適切に伝達するエレメントやアトリビュートを使いましょう。
    フレーズエレメントにはこのようなものがあります。EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, ACRONYM.
    構造エレメントには、H1, H2, などがあります。
    構造エレメントは文書の中の一貫性を強制し、その他のツール(例.インデックスツール、サーチエンジン、データベースへテーブルを抽出するプログラム、見出しエレメント(H1, H2 など)を使って操作ツールを生成するブラウザなど)に情報を供給します。

  10. [推奨]
      構造エレメントやアトリビュートをレイアウト目的に誤用しないようにしましょう。
    たとえば、引用でない段落を字下げするために BLOCKQUOTE エレメントを使ってはいけません。スタイルシートを使いましょう。テキストの組み表レイアウトを作成するために PRE を使っては行けません。テーブルを使いましょう。

  11. [推奨]
      表現エレメントを構造目的に誤用しないようにしましょう。
    たとえば、水平線 (HR) は、あるユーザには構造の変更を伝達することもありますが、すべてのユーザに伝達しない場合があります。代わりに DIVSPAN で構造を指定しましょう。例:
    <DIV class="navigation-bar">
    <HR title="ナビゲーションバー">
    [ <A rel="Next" href="next.html">次ページ</A> |
      <A rel="Previous" href="previous.html">前ページ</A> |
      <A rel="First" href="first.html">先頭ページ</A> ]
    </DIV>
    
    
  12. [推奨]
      水平線、頭字語、略称にはタイトルをつけましょう。
    例:
    <HR title="新しい節">
    <ABBR title="Idaho:アイダホ">ID</ABBR>
    <ACRONYM title="World Wide Web:ワールドワイドウェブ">WWW</ACRONYM>

ヒント集

もっと知るには:

  1. Style Sheets - Chapter 14 in the Central Reference Document
  2. Style Sheets - the HTML 4.0 specification
  3. Cascading Style Sheets, level 2 -- Working Draft W3C [訳者注:現在は Recommendation として公開されています.]
  4. Text - Chapter 9 in the Central Reference Document
  5. Text - the HTML 4.0 specification
  6. Lists and Outlining - Chapter 10 in the Central Reference Document
  7. Lists - the HTML 4.0 specification

2. 画像、イメージマップ

リンクに関する節にもあたってください。

  1. [必須]
    画像やイメージマップにはすべて代替テキストをつけましょう。

    画像はそれぞれが、グラフィックの機能を表現する代替テキストをもつべきです。視覚的な説明よりも、画像が使われている文脈に基づいた機能的なラベルを心掛けましょう。代替テキストが有益かどうかを判断するためのよいテストは、電話で声を出して文書を読み上げることを想像することです。あなたはこの画像に出くわしたとき、そのページを聞き手に理解できるようにするためにどう言うでしょうか? 代替テキストを提供するための戦略としてあり得るものとしては、このようなものが含まれます。
    1. "alt" アトリビュートは AREA エレメントや IMG エレメントには強制的です。フォーム上の送信ボタンとして使われているボタン(INPUT, BUTTON エレメント)にも使われるべきです。例: <IMG src="magnifyingglass.gif" alt="Search">. しかしながら、代替テキストのための勧告は、グラフィックの使われ方(飾りボタン、リストマーカー、図解など)によって変わります。立ち入った情報は付録 B - 代替テキスト制作ガイドラインをご覧ください。
    2. [新規] OBJECT が使われていれば、テキストを OBJECT エレメントの本体の中に提供することができます。例:
      <OBJECT data="magnifyingglass.gif">Search</OBJECT>

    注意. 画像の外観についての長文説明が提供されてもよいでしょう。解決戦略については次の勧告を見ること。

  2. [必須]
    重要な情報を表現する画像(特に地図、テーブル、解説図)には長文説明をつけましょう。

    代替テキスト(上記の戦略 2.1 を見ること)はたいていは短くて、グラフィックエレメントの基本的な目的を定義するものです。グラフィックそのものをもっと詳細に説明するためには、以下の機構のうちのひとつ(これらの方法のほとんどは追加情報にリンクします)を用いて長文説明を補充します。
    1. [暫定] グラフィックの隣に説明用リンク(Dリンク)を提供しましょう。Dリンクは、グラフィックの長文説明のあるページや、そのページの下部にある文章へリンクするものです。例:
      <IMG src="97sales.gif" alt="1997年の売り上げ">
      <A href="sales.html" title="1997年の売り上げ解説図の説明">D</A>
    2. [新規] IMG エレメントの "longdesc" アトリビュートを使いましょう。例:
      <IMG src="97sales.gif" alt="1997年の売り上げ" longdesc="sales.html">
    3. [新規] OBJECT の本体の内部にテキストを提供しましょう。
      <OBJECT data="sales.gif">
      1997年の売り上げは下記の ...
      </OBJECT>
    4. 画像データファイルのフォーマットがサポートしているときには、画像データファイルの中に内部テキストを組み込みましょう。例.PNG.

  3. [必須]
    イメージマップ情報がアクセス可能であり、キーボードで操作可能であることを確かめましょう。

    この勧告を満足するためのいちばん簡単な方法は、クライアント側イメージマップを使うことです。グラフィックを表示しないブラウザが、AREA エレメントの"alt" アトリビュートや "title" アトリビュートの値を使って、イメージマップグラフィックの代わりにリンクの一覧を表示することができるからです。ブラウザが定義されている領域の座標を知っていますから、イメージマップ内部の領域へのキーボード操作も可能です。

    サーバ側イメージマップを使わなければならないときは、制作者はイメージマップの選択肢の代替的一覧表を提供するべきです。代替的リンク一覧表がイメージマップの後にあれば、制作者は IMG エレメントの "alt" アトリビュートで代替リストの存在と位置とを示すべきです。もっと素直な解決方法は、新しくて後方互換性も乏しいのですが OBJECT エレメントの本体の内部に代替的リンクを組み込むことです(下記の例を見ること)。最後の可能性はアクセス可能な代替ページを制作することです。

    クライアント側イメージマップについては解決戦略がいくつかあります。

    1. AREAMAP エレメントが使われているならば AREA エレメントの "alt" アトリビュートを設定します。たとえば IMG エレメントで
      <IMG src="welcome.gif" alt="ライブラリのエリアのイメージマップ"
           usemap="#map1">
      <MAP name="map1">
        <AREA shape="rect" coords="0,0,30,30" href="reference.html" 
              alt="リファレンス">
        <AREA shape="rect" coords="34,34,100,100" href="media.html"
              alt="オーディオ、ビジュアル工房">
      </MAP>
      
      
    2. [新規] 同じアイデアですが、今度はより多くの情報を組み込める柔軟性のある OBJECT エレメントを使います。
      <OBJECT data="welcome.gif" usemap="#map1">
       ライブラリには
       <A href="reference.html">リファレンス</A>
       や <A href="media.html">オーディオ、ビジュアル工房</A>
       を含むエリアがあります。
       もっとテキストを続けたり前に置いたりできます。
      <MAP name="map1">
         <AREA shape="rect" coords="0,0,30,30" 
               href="ref.html" alt="リファレンス">
         <AREA shape="rect" coords="34,34,100,100" 
               href="media.html" alt="オーディオ、ビジュアル工房">
      </MAP></OBJECT>
      
      
    3. [新規] MAP エレメントを A エレメントと一緒に使って、アクティブな地域形状を指定し、文脈的情報を提供することができます。
      <OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
      <MAP name="map1">
      <P>サイトのナビゲーション:
       <A href="guide.html" 
          shape="rect" coords="0,0,118,28">アクセスガイド</a> |
       <A href="shortcut.html" 
          shape="rect" coords="118,0,184,28">進む</A> |
       <A href="search.html" 
          shape="circle" coords="184,200,60">検索</A> |
       <A href="top10.html" 
          shape="poly" coords="276,0,373,28,50,50">トップ10n</A>
      </MAP>
      </OBJECT>
      
      

      この例において、MAP エレメントは OBJECT エレメントの内容であり、代替的リンクはイメージマップ (navbar1.gif) が表示されない場合に表示されるだけであることに注意してください。

  4. [推奨]
    リンクとして使われている画像には説明的な表題をつける。

    リンクとして使われている画像についてより多くの情報を提供するには、A エレメントの "title" アトリビュートを使います。例.
    <A href="home.html" title="XYZ社サイト全体の検索">
       <IMG src="magnifyingglass.gif" alt="検索">
    </A>
    
    
  5. [推奨]
    ASCII アートを避ける。画像と代替テキストとで置き換える。

    避けるべき印刷術的キャラクタや構造でよくあるものとしては、emoticons や、ダッシュと不等号とで構成された矢印(例. -->)などがあります。

もっと知るには:

  1. the Central Reference Document から
    1. 13.1 Introduction to the issues
    2. 13.2 General recommendations
    3. 13.3 Viewing and interacting with static images and image maps
  2. Objects, Images and Applets - the HTML 4.0 specification

3. アプレット、スクリプト

  1. [必須]
    情報を伝達するスクリプト、アプレットにはそれぞれについて代替的な内容の表現をつけましょう。
    1. [新規] NOSCRIPT エレメントは、制作者がスクリプトの内容の代替的表現を補うことを可能にします。例.
      <SCRIPT type="text/tcl">
      ...スポーツのスコアのビルボードを表示するためのTclスクリプト...
      </SCRIPT>
      <NOSCRIPT>
      <P>昨日の試合の結果:
      ブルズ 91 対ソニックス 80  <A href="bullsonic.html">ブルズ対ソニックスの試合の要約</A>
      ...その他のスコア...
      </NOSCRIPT>
      
      
    2. [暫定] APPLET エレメントの内容として説明文を補充しましょう。

      <APPLET code="Press.class" width="500" height="500"
              alt="Java アプレット:温度がどのように圧力に影響するか.">
      温度が風船の中の分子を増加させるにつれて...
      </APPLET>

      注意. APPLET エレメントはHTML 4.0 では廃止されつつあります。

    3. [新規] OBJECT エレメントの内容として説明文を補充しましょう。

      <OBJECT classid="java:Press.class" width="500" height="500"
              title="Java アプレット:温度がどのように圧力に影響するか.">
      温度が風船の中の分子を増加させるにつれて...
      </OBJECT>

      より複雑なバージョンは、OBJECT エレメントが情報の代替的表現を提供するために埋め込まれてよいという事実を利用します。

      <!-- まずアプレットを試します. -->
      <OBJECT title="温度がどのように圧力に影響するか"
              classid="java:Press.class" width="500" height="500">
         <!-- だめならMPEGビデオを試します. -->
         <OBJECT data="pressure.mpeg" type="video/mpeg">
            <!-- だめならGIF画像を試します. -->
            <OBJECT data="Pressure.gif">
               <!-- だめなら説明文と代替物をレンダリングします. -->
               温度が風船の中の分子を増加させるにつれて...
      </OBJECT></OBJECT></OBJECT>
      
      
      
  2. [必須]
    重要な機能を果たすスクリプト、アプレットにはそれぞれについて、情報の表現以外に代替的機構を用意しましょう。

    たとえば、アプレットがデータベース用の情報を集める場合があります。ユーザ入力フォームや電子メールアドレス、電話番号、ファックス番号といったような代替的な情報収集機構が、APPLET エレメントまたは OBJETC エレメントの内容の内部に与えられるべきです。

  3. [必須]
    アプレットが代替的なフォーマットで複製できないユーザの相互作用を要求するならば(例.物理実験の操作の能力)アプレットを直接にアクセス可能にしましょう。

    立ち入った情報は the Java Accessibility page at the Trace Center を通じて入手できます。

  4. [必須]
    移動したり点滅するすべてのオブジェクト、特にテキストを含んでいるオブジェクトをユーザが凍結できる機構を提供しましょう。
    Mark Novak によって作成された例では、Java マーキーがフォーカスを有している間にユーザがエスケープキーを押すとテキストが静止して表示されます。例を見て見ましょう

  5. [推奨]
      各アプレットに代替テキストをつけましょう。
    APPLET エレメントや OBJECT エレメントの本体の内部に内容を提供すること(この節の項目1)は、後方互換性を有しますから、代替テキストを提供する好ましい方法です。
    1. [暫定] APPLET エレメントの "alt" アトリビュートを使う。
      <APPLET code="Duke.class" width="50" height="50" 
              alt="Java アプレット:手を振る公爵.">
      </APPLET>
      

      注意. APPLET エレメントはHTML 4.0 では廃止されつつあります。

    2. [新規] OBJECT エレメントを使うときには、"title" アトリビュートの内部または OBJECT エレメントの内部に代替テキストを指定する(この節の項目1を見ること)。
      <OBJECT classid="Duke.class" width="50" height="50" 
              title="Java アプレット:手を振る公爵.">
      </OBJECT>
      
      
  6. [推奨]
    スクリプトやアプレットをキーボードで操作できるようにする。

注意. この領域ではさらなる探求が必要です。しばらくお待ちください。

もっと知るには:

  1. the Central Reference Document から
    1. 13.1 Introduction to the issues
    2. 13.2 General recommendations
    3. 13.4 Applets
    4. 18 Scripts
  2. Objects, Images and Applets - the HTML 4.0 specification
  3. Scripts - the HTML 4.0 specification
  4. IBM Guidelines for Writing Accessible Applications Using 100% Pure Java -- IBM Special Needs Systems

4. オーディオ、ビデオ

  1. [必須]
    音声情報すべてにテキスト表記をつけましょう。
    完全なオーディオのテキスト表記は、話されたダイアログだけでなく、スクリーン上やスクリーン外のサウンド、音楽、笑い声、拍手などを含むその他の重要な音を含んだものです。これらのテキスト表記がビデオ表現と同期的に表示されるとき、それらは「キャプション」と呼ばれ、ビデオ素材のオーディオトラックを聴くことができない人々によって利用されます。

  2. [必須]
    聴覚的形式ですべてのビデオ情報の解説をオーディオトラックに同調させて提供する。
    ビデオの説明文は主に、目が不自由でビデオ素材のアクションやその他の非聴覚的情報に追従できない人々によって利用されます。解説とは、オーディオやムービーのダイアログを妨げずに、鍵となる視覚的要素のナレーションを提供するものです。鍵となる視覚的要素には、アクションや設定、ボディランゲージ、グラフィックス、表示されたテキストが含まれます。

  3. [必須]
      テキストフォーマットですべてのビデオ情報の説明文を提供する。
    ビデオ説明文のテキスト表記は、勧告 4.2 と同じ情報を提供しますが、これはテキストフォーマットでです。
    このテキスト表記は、完全なオーディオのテキスト表記 (4.1) と結合して、視覚的にも聴覚的にも障害をもつ人々によるアクセスを可能にします。また、これはあらゆる人に対して、オーディオ素材やビジュアル素材に含まれている情報をインデックス化したり検索する能力を与えます。

  4. [必須]
    直接的にでも同期ファイル経由でもかまいませんが、テキスト、ビデオ説明文情報をオーディオ情報やビデオ情報と同期させましょう。
    メディアフォーマットの中には、QuickTime 3.0 のように、キャプションやビデオ説明文をマルチメディアクリップに付加できるようにするものがあります。
    1. [暫定] 問題となっているフォーマットが代替トラックをサポートするまでの間は、キャプションやビデオ説明文つきのものとそれがないものとの2つのバージョンのムービーを利用可能にするのがよいでしょう。
    2. [新規] 将来の技術によって、分離したオーディオやビジュアルファイルを同期ファイル経由でテキストファイルと組み合わせて、キャプションつきのオーディオやムービーを制作できるようになるでしょう。また、ユーザが、複数のキャプションのセットから読解能力に応じた選択ができるようにもなるでしょう。立ち入った情報はSMIL仕様書をご覧ください。

  5. [推奨]
    自動的に再生される音声に視覚的告知をつけましょう。
    これは、サウンドファイルのテキスト表記や説明文へリンクしている、ページ上のテキスト文章の形式で提供できます。字幕へのリンクは、ページの上端といったようによく目立つ位置に現われるものであるべきです。しかしながら、もしスクリプトが自動的にサウンドを読み込んでいるならば、サウンドが現在再生中である旨の視覚的表示も自動的に読み込み、サウンドの説明文や字幕が提供できるはずです。この勧告を巡る論点は、ユーザ設定がそのように設定されていれば、ブラウザは聴覚的形式の代わりに視覚的形式の情報を読み込むべきだということです。しかしながら、その戦略は今日のブラウザでも機能しなければなりません。

  6. [推奨]
    きわめて短いサウンドの簡潔な説明を提供するには "title" アトリビュートを使いましょう。
    例.<A href="mittens.wav"title="にゃお">Calico は「やあ」と言う.</A>

もっと知るには:

  1. the Central Reference Document から
    1. 13.1 Introduction to the issues
    2. 13.2 General recommendations
    3. 13.5 Audio and video
  2. Objects, Images and Applets - the HTML 4.0 specification
  3. NCAM からの例

5. テーブル(組み表)

  1. [必須]
    テーブルのセルを明示的に行や列のラベルと結びつけましょう。
    テーブルが適切にラベルづけされていれば、将来のブラウザや補助技術で自動的にテーブルを直線的シーケンスに変換できることでしょう。
    [新規] セルにラベルをつける方法のひとつは "headers" アトリビュートや "scope" アトリビュートを用いることです。付録にある最初2つのテーブルの例を参照してください。

  2. [必須]
    文書を段組みにフォーマットするためにテーブルを使うことは避けましょう。
  3. [推奨]
    テキストと数字とのテーブルについては、直線的な様式でテーブル情報を表現する代替ページを提供しましょう。

  4. [推奨]
    ページをレイアウトするためにテーブルを使うことは避けましょう。
    [新規] 制作者は、グラフィックスやテキストをポジショニングするためにはスタイルシートを使うべきです。

  5. [推奨]
    長い行や列のラベルには省略形表記をつけましょう。
    [新規] 行や列の見出しの省略形表記("abbr" アトリビュート)は、短くても意味のあるものであるべきです。これは、各セルについて行や列ラベルを読み上げる将来のスピーキング技術にとって特に有益なことでしょう。省略形表記は繰り返しや読み上げ時間を節約します。付録にある例を参照してください。

  6. [推奨]
    テーブルのまとめをつけましょう。
    [新規] テーブル構造や目的のまとめ(TABLE エレメントの "summary" アトリビュート)は、特に非視覚的ユーザにとって有益です。付録にある例を参照してください。

  7. [推奨]
    より複雑なテーブルについては情報をいくつかのカテゴリーにグループ化しましょう。
    [新規] 将来のブラウザは、ユーザが、カテゴリーに基づいたフィルタリングによってテーブルからデータを選択できるようにするでしょう。付録の3つ目の例("axis" アトリビュート)を参照してください。

  8. [推奨]
    グラフィックスをポジショニングするために使われているテーブルの内部では、代替テキストが折り返しをしないことを確かめましょう。
    [暫定] 800 x 600 ピクセルといったような一般的な解像度を使う15インチのモニタに最大限に収まるのと同等のウィンドウサイズを使って、折り返しをテストしましょう。

  9. [推奨]
    テーブルをアクセス可能にできないならば、電話番号、ファックス番号、または電子メールアドレスをつけましょう。

ヒント集

もっと知るには:

  1. Tables - Chapter 11 in the Central Reference Document
  2. Tables - the HTML 4.0 specification

6. リンク

イメージマップに関する節にもあたってみてください。

  1. [推奨]
    読んだときに文脈外でも意味をなしているが、うるさすぎないリンク文を作成する。
    目の不自由なユーザは、ページを斜め読みしたり情報を探したりするときに、リンクからリンクへとジャンプすることがよくあります。これをするときには、リンクのテキスト ("link text") だけしか読まれません。したがって、リンクテキストが周囲のテキストなしで読んだときにも意味をなしていることが重要です。たとえば、制作者は、リンクテキストとして「ここをクリック」を同じページ上で何回も使うべきではありません。このことは、スクリーンリーダーでページをブラウズしているユーザに、リンクの目的を決定するために、リンクごとにリンク全体を歩き、周囲のテキストを読むことを要求します。代わりに、リンクテキストは、「この文書をASCIIテキストでダウンロードする」とか「HTMLの完全版」、「テキストバージョンが必要ならばこのリンクを選択する」といったように、重要な情報を伝えるべきです。

  2. [推奨]
    連続して発生するリンクの間には、非リンクの(スペースで挟まれている)印字可能なキャラクタを置いて分離したリンクがスクリーンリーダーによってひとつのものとして読まれないようにしましょう(例." | ")。
    [暫定] ガイドライン 5.3 に提供されている例をあたってみてください。

  3. [推奨]
    リンクにキーボードショートカットをつけましょう。
    LABEL, A, CAPTION, LEGEND エレメントの "accesskey" アトリビュートは、制作者が、キーボードショートカットを文に結びつけることを可能にします。たとえば、リンクに結びつけられているとき、それはユーザを結びつけられた文書に連れて行きます。<A accesskey="C" href="doc.html">XYZ社ホームページ</A>

もっと知るには:

  1. Links - Chapter 12 in the Central Reference Document
  2. Links - the HTML 4.0 specification

7. フレーム

  1. [必須]
    フレームなしでもページが読むことができて利用可能であることを確かめましょう。
    [新規] 制作者は各 FRAMESET の末尾に NOFRAMES エレメントを組み込むべきです。Central Reference Document のを参照してください。

  2. [必須]
    画像をフレーム内に直接組み込まないようにしましょう -- 分離した文書の中に置きましょう。
    [新規] さもなくば、フレーム内容が変化すれば、フレームタイトル -- この場合に利用可能な唯一の代替テキスト -- はもはや意味をなさないことになります。画像をそれ自身のファイルの中に組み込むことは、制作者が IMG エレメントや OBJECT エレメントに 代替テキストを指定することを可能にします。

  3. [必須]
    各フレームにタイトルをつけましょう。
    [新規] ページを音声的にアクセスしている人々が、フレームがいくつ存在し、どれが現在のフレームかを見失わずにいることがより簡単になるでしょう。例.
    <FRAMESET cols="10%,90%" title="電子文書のライブラリ">
    <FRAME src="nav.html" title="ナビゲーションバー">
    <FRAME src="doc.html" title="文書">
    <NOFRAMES><A href="lib.html" title="ライブラリリンク">
                 電子ライブラリへ行く</A>
    </NOFRAMES>
    </FRAMESET>
    
    
  4. [推奨]
    フレームのレイアウトや目的や、複数のフレームがどのように互いに関連しているかを記述する。
    [新規] FRAME エレメントや IFRAME エレメントで "longdesc" アトリビュートを使って、長文説明を指し示します。

もっと知るには:

  1. Frames - Chapter 16 in the Central Reference Document
  2. Frames - the HTML 4.0 specification

8. ユーザ入力フォーム

  1. [必須]
    グラフィカルな送信ボタンを作るためにイメージマップを使わないようにしましょう。
    代わりに、代替テキストつきの BUTTON エレメントか INPUT エレメントかを使いましょう。

  2. [必須]
    フォーム制御にラベルを結びつけましょう。
    LABEL エレメントの "for" アトリビュートを使ってラベルを明示的に結びつけることができます。

    [新規] LABEL エレメントの "for" アトリビュートは明示的な結びつけを可能にします。例.

    <FORM action="http://somesite.com/adduser" method="post">
      <FIELDSET>
        <LEGEND>個人情報</LEGEND>
        <LABEL for="familyname">姓:</LABEL>
        <INPUT type="text" id="familyname" tabindex="1">
        <LABEL for="personalname">名:</LABEL>
        <INPUT type="text" id="personalname" tabindex="2">
        ...その他の個人情報...
      </FIELDSET>
      <FIELDSET>
        <LEGEND>投薬歴</LEGEND>
        ...投薬歴情報...
      </FIELDSET>
    </FORM>
    
    
    
  3. [必須]
    送信ボタンとして使われている画像には代替テキストをつけましょう。
    例. <INPUT type="image" name="submit" src="button.gif" alt="送信">

  4. [推奨]
    フォーム制御の間に論理的なタブ順を指定する。
    [新規] "tabindex" アトリビュートはフォーム制御の間にタブ操作順を指定します。例.
    <INPUT tabindex="1" type="text" name="field1">
    <INPUT tabindex="2" type="text" name="field2">
    <INPUT tabindex="3" type="submit" name="submit">
    
    
  5. [推奨]
    関連する制御を意味論的にグループ化し、各グループにラベルをつけましょう。
    [新規] 新しい FIELDSET エレメントはフォーム制御をグループ化し、LEGEND エレメントは各グループにラベルをつけます。ガイドライン 10.2 の例をご覧ください。

  6. [推奨]
    長い選択リストについては項目を階層構造にグループ化しましょう。
    [新規] 近い将来、ブラウザは、詳細レベルの展開や折込みを用いて、グループ化されたリストを表示するでしょう。項目をグループ化するには OPTGROUP エレメントを(SELECT エレメントと一緒に)使います。例.
    <FORM action="http://somesite.com/prog/someprog"
          method="post">
    <P><SELECT name="ComOS">
    <OPTGROUP label="Comm サーバー">
    <OPTGROUP label="PortMaster 3">
    <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 + ComOS 3.7.1
      <OPTION label="3.7" value="pm3_3.7">PortMaster 3 + ComOS 3.7
      <OPTION label="3.5" value="pm3_3.5">PortMaster 3 + ComOS 3.5
    </OPTGROUP>
    <OPTGROUP label="PortMaster 2">
      <OPTION label="3.7" value="pm2_3.7">PortMaster 2 + ComOS 3.7
      <OPTION label="3.5" value="pm2_3.5">PortMaster 2 + ComOS 3.5
    </OPTGROUP>
    </OPTGROUP>
    <OPTGROUP label="ルーター">
    <OPTGROUP label="IRX">
      <OPTION label="3.7R" value="IRX_3.7R">IRX + ComOS 3.7R
      <OPTION label="3.5R" value="IRX_3.5R">IRX + ComOS 3.5R
    </OPTGROUP>
    </OPTGROUP>
    </SELECT>
    </FORM>
    
    
  7. [推奨]
      編集ボックスやテキスト領域にはデフォルトの場所確保キャラクタを組み込みましょう。 [暫定]

  8. [推奨]
    情報を送信する代替的手段として、電話番号、ファックス番号、電子メールアドレス、郵政アドレスを組み込みましょう。 [暫定]

  9. [推奨]
    フォームエレメントにキーボードショートカットを備え付けましょう。
    [新規] キーボードショートカットは "accesskey" アトリビュートを用いて割り当てられます。この例は、"U" をアクセスキーとして割り当てています。"U" をタイプすると、ラベルにフォーカスが与えられ、それが制御にフォーカスを与え、その結果としてユーザはテキストを入力できます。
    <FORM action="submit" method="post">
    <LABEL for="user" accesskey="U">ユーザ名</label>
    <INPUT type="text" name="user">
    </FORM>
    
    

もっと知るには:

  1. Forms - Chapter 17 in the Central Reference Document
  2. Forms - the HTML 4.0 specification

9.  万策尽きたら...

もし、最善の努力を尽くしても、なおどれかのページがアクセス可能でないならば、アクセス可能で、同等の情報を有し、アクセス不能のページと同じ頻度でメンテナンスされる代替ページへのリンクを提供しましょう。メンテナンス費用のせいで代替ページが時期遅れになる傾向が強まりますから、代替ページはは勧められた慣行ではありません。もし代替ページを作るのであれば、メインページと同じ頻度で更新され、同等の情報を提供するものでなければなりません。

  1. 代替ページへのリンクの方法:
    1. [暫定] ユーザがそのページのグラフィック版と代替版との間を行き来できるようにするために、各ページの先頭にリンクを提供しましょう。
    2. [新規] ブラウザがそれを自動的に読み込めるよう、主ページのヘッダに(LINK エレメントを用いて)適切な情報を提供しましょう。もしユーザがデフォルトメディア型を "aural", "braille", "tty" に設定していれば、ユーザエージェントは自動的に代替ページを読み込むべきです。例.
      <HEAD>
      <TITLE>バーチャルモールへようこそ!!</TITLE>
      <LINK title="テキスト版"
            rel="alternate" href="text_only.html"
            media="aural, braille, tty">
      </HEAD>
      
      

10. よいウェブサイト設計慣行

一般的なサイト設計のガイドラインに従うことは、アクセシビリティをさらに向上させるでしょう。

  1. ページについて一貫したスタイルを制作する.
  2. 明快で一貫した操作構造を使う.
  3. 操作構造への簡単なアクセスのためにナビゲーションバーを提供する.
  4. サイトの全般的なレイアウト、使われているアクセス機能やその使い方に関する説明を提供する.
  5. サイトマップを提示する.
  6. 異なる技能水準や好みに応じた異なる型の検索を提示する.
  7. サイト内部の何ものもキーボード操作を妨げないことを確認する.
  8. テキストと背景色や背景パターンとがきちんとコントラストを有する(白黒プリンタにページを印字することはよいテスト方法のひとつです).
  9. アクセス機能をサポートしている(また閉じるときにアクセスを除去したりツールを使うのにページを再び開いたりしない)デザインツールを使う.
  10. 区別のための情報を、見出しや段落、リストなどの始めに置いて、重要な情報を見つけるために読者がなすべきふるい分けの量を減少させる. これは、一般的に「フロントローディング」と呼ばれるもので、特にシリアル的に情報にアクセスしている人々にとって助けになります。
  11. 一連の分離したページとして存在する文書については、単一のダウンロード可能なファイルを作成する. これは文書をオフラインで読む人々の助けになります。現在のところは、単一ファイルを作成するにはアーカイバや圧縮プログラムが必要です。近い将来、ユーザエージェントが、ページヘッダ内の情報に基づいて分離したページをページ順に揃えることができるようになるでしょう。以下の例は、リファレンスマニュアルの最初のページがどこに存在し、どのページが現在のページの後に続くのかを示す方法を示しています。
    <HEAD><TITLE>リファレンスマニュアル -- 第1章</TITLE>
       <LINK rel="Start" title="マニュアルの最初のページ"
             type="text/html" 
             href="http://someplace.com/manual/start.html">
       <LINK rel="Next" title="第2章" 
             type="text/html" 
             href="http://someplace.com/manual/ch2.html">
    </HEAD>
    
  12. 少なくとも これらのものを用いてサイトをテストする.
  13. 自動音声化ブラウザ(PWWebspek といったようなもの)でサイトをテストすることも助けになる場合があります.
  14. 次のようなツールを用いてページを検証する.

もっと知るには:

Good Web Site Design Practices - Chapter 25 in the Central Reference Document


付録 A - テーブルの例

  1. "headers" - 以下の例は "headesr" アトリビュートにヘッダ情報を結びつける方法を示したものです。"headers" アトリビュートは、現在のデータセルに結びつけられたヘッダセル(行、列ラベル)の一覧を指定します。これは、各ヘッダセルが "id" を有していることを要求します。
    <TABLE border="border" summary="この表は各評議員が飲むコーヒーの杯数、
    コーヒーの種類(カフェイン抜きやレギュラー)、砂糖の有無を一覧表にしたものです.">
    <CAPTION>各評議員の飲むコーヒーの杯数</CAPTION>
    <TR>
    <TH id="t1">氏名</TH>
    <TH id="t2">杯数</TH>
    <TH id="t3" abbr="種類">コーヒーの種類</TH>
    <TH id="t4">砂糖</TH>
    <TR>
    <TD headers="t1">T. Sexton</TD>
    <TD headers="t2">10</TD>
    <TD headers="t3">エスプレッソ</TD>
    <TD headers="t4">なし</TD>
    <TR>
    <TD headers="t1">J. Dinnen</TD>
    <TD headers="t2">5</TD>
    <TD headers="t3">カフェイン抜き</TD>
    <TD headers="t4">あり</TD>
    </TABLE>
    
    

    音声合成装置は、以下のように話すことでレンダリングをするでしょう。

               見出し: 各評議員の飲むコーヒー
               まとめ: この表は各評議員が飲むコーヒーの杯数、コーヒーの種類
                       (カフェイン抜きやレギュラー)、砂糖の有無を一覧表に
                       したものです.
               氏名: T. Sexton, 杯数: 10, 種類: エスプレッソ, 砂糖: なし
               氏名: J. Dinnen, 杯数: 5, 種類: カフェイン抜き, 砂糖: あり
           
    
  2. "scope" - 以下の例は、先の例と同じヘッダとデータ情報とを結び付けていますが、"headers" よりも "scope" アトリビュートを使っています。"scope" は、以下の値のうちのひとつをとらなければなりません。row, col, rowgroup, colgroup. スコープは、データセルのセットを、現在のヘッダセルに結びつけるように指定します。この方法は特に単純なテーブルのために有益です。この例は、音声合成装置により、先の例のようにレンダリングされるでしょう。
    <TABLE border="border" 
    summary="この表は各評議員の飲むコーヒーの杯数、コーヒーの種類
    (カフェイン抜きやレギュラー)、砂糖の有無を一覧表にしたものです.">
    <CAPTION>各評議員の飲むコーヒーの杯数</CAPTION>
    <TR>
    <TH scope="col">氏名</TH>
    <TH scope="col">杯数</TH>
    <TH scope="col" abbr="種類">コーヒーの種類</TH>
    <TH scope="col">砂糖</TH>
    <TR>
    <TD>T. Sexton</TD>
    <TD>10</TD>
    <TD>エスプレッソ</TD>
    <TD>なし</TD>
    <TR>
    <TD>J. Dinnen</TD>
    <TD>5</TD>
    <TD>カフェイン抜き</TD>
    <TD>あり</TD>
    </TABLE>
    
    
  3. "axis" - 以下の例は、テーブル内部にカテゴリーをどのように作成するかを示したものです。
    <TABLE border="border">
    <CAPTION> 旅行費用の報告 </CAPTION>
    <TR>
    <TH></TH>
    <TH id="a2" axis="expenses">食事</TH>
    <TH id="a3" axis="expenses">宿泊</TH>
    <TH id="a4" axis="expenses">運賃</TH><TD>小計</TD>
    </TR>
    <TR>
    <TH id="a6" axis="location">San Jose</TH>
    <TH></TH><TH></TH><TH></TH><TD> </TD>
    </TR>
    <TR>
    <TD id="a7" axis="date">1997/08/25</TD>
    <TD headers="a6 a7 a2">37.74</TD>
    <TD headers="a6 a7 a3">112.00</TD>
    <TD headers="a6 a7 a4">45.00</TD><TD></TD>
    </TR>
    <TR>
    <TD id="a8" axis="date">1997/08/26</TD>
    <TD headers="a6 a8 a2">27.28</TD>
    <TD headers="a6 a8 a3">112.00</TD>
    <TD headers="a6 a8 a4">45.00</TD><TD></TD>
    </TR>
    <TR>
    <TD>subtotals</TD><TD>65.02</TD><TD>224.00&
    </TD><TD>90.00</TD><TD>379.02</TD>
    </TR>
    <TR>
    <TH id="a10" axis="location">Seattle</TH>
    <TH></TH><TH></TH><TH></TH><TD> </TD>
    </TR>
    <TR>
    <TD id="a11" axis="date">1997/08/07</TD>
    <TD headers="a10 a11 a2">96.25</TD>
    <TD headers="a10 a11 a3">109.00</TD>
    <TD headers="a10 a11 a4">36.00</TD><TD></TD>
    </TR>
    <TR>
    <TD id="a12" axis="date">1997/08/28</TD>
    <TD headers="a10 a12 a2">35.00</TD>
    <TD headers="a10 a12 a3">109.00</TD>
    <TD headers="a10 a12 a4">36.00</TD><TD></TD>
    </TR>
    <TR>
    <TD>小計</TD><TD>131.25</TD><TD>218.00
    </TD><TD>72.00</TD><TD>421.25</TD>
    </TR>
    <TR>
    <TH>合計</TH><TD>196.27</TD><TD>442.00
    </TD><TD>162.00</TD><TD>800.27</TD>
    </TR> 
    </TABLE>
    
    

付録 B - 代替テキスト制作ガイドライン

全般的な勧告

一般的に制作者は、グラフィックや画像の視覚的外観ではなく機能を説明する代替テキストを指定するべきです。制作者は自分自身にこの質問をするべきです。もし文書を電話を通じて声を出して読んでいるならば、この画像やグラフィックに遭遇したときに、聞き手にページが理解できるようにするためにどのように言うでしょうか?

画像についてのテキスト情報を提供するために使うことができる IMG のアトリビュートは3つあります。

注意. OBJECT エレメントで埋め込まれた画像の代替テキストを提供することは異なる獲物であって、将来カバーされるでしょう。

 

装飾的グラフィックス

画像の簡潔なテキスト的等価物を提供します。代替テキストを提供することは必須ですが、長文説明を提供することは推奨事項です。
例. <IMG src="sailboats.gif" alt="静かな水面のヨット" longdesc="sailboatsdesc.html">
そして sailboatsdesc.html の内部には

小さい町の賑やかな通りの端の静かな水面につながれた10艘のヨットの写真

ユーザの中にはグラフィックの短い説明さえも見たくない人もいるかもしれませんから、これはできる限り短くとどめます。私達は将来、ユーザがダウンロードして見たい型の画像を選択できるようにするスタイルシートや class 値、XMLの利用について勧告を作成する予定です。

 

リストマーカー

  1. リスト項目は正しくマークアップする。
  2. マーカーで追加的な情報が与えられない順序なしリストについては、代替テキストとして "Item" を使う。代替テキストを画像に結びつける方法が見つかるまでの間は、スタイルシートを使って代替的なマーカーを提供することは避ける(例2を見ること)。

    例1.
    <STYLE ...><!-- UL { list-style: none }-->
    <UL>
    <LI><IMG src="star.gif" alt="Item:">オードリー</LI>
    <LI><IMG src="star.gif" alt="Item:">ローリー</LI>
    <LI> ... </LI>
    </UL>

    例2.(避ける)
    <STYLE ...><!-- UL { list-style: url(star.gif) }-->
    <UL>
    <LI> オードリー</LI>
    <LI> ローリー</LI>
    <LI> ... </LI>
    </UL>

  3. マーカーが追加的な情報を提供する順序なしリストでは、代替テキストの中にラベルを提供する。

    例.
    <STYLE ...><!-- UL { list-style: none }-->
    <UL>
    <LI><IMG src="red.gif" alt="新規:">Roth IRA</LI>
    <LI><IMG src="yellow.gif" alt="旧式:">401 K</LI>
    <LI> ... </LI>
    </UL>

  4. 順序つきリストについては、代替テキストの中に項目番号を提供する。

    例.
    <STYLE ...><!-- OL { list-style: none }-->
    4枚目のアルバムに収録した歌のタイトル.
    <OL>
    <LI><IMG src="bullet1.gif" alt="One:">部屋</LI>
    <LI><IMG src="bullet2.gif" alt="Two:">いいやつ</LI>
    <LI> ... </LI>
    </OL>

 

リンク、ボタン

等価的なテキスト的リンク文を 代替テキストの中に提供する(すなわち、リンクはそれが言おうとしていることについての、グラフィックの代わりにテキストになる)。
例. <A href="routes.html"><IMG src="topo.html" alt="ボールダーズ登山ジムの現行ルート"></a>

 

セクションの分離

セクションを分離するものとして使われるグラフィック(例.水平線)については、そのグラフィックが表現するものについての情報を提供する。言い換えると、視覚的な読者が受け取るものと同等のテキスト列を提供する。
例.
<IMG src="redline.gif" "第7章 - 視覚的表示 - の終わり">
<H1>第8章 - 聴覚的、触覚的表示</H1>

 

ビットマップテキスト

画像がスタイル化されたり色満載のテキストの画像にすぎないならば、代替テキストは画像内のテキストと同じものでなければならない。
  <P>これは私達が言おうとしていることの<IMG src="BigRedExample.gif" alt="例">です。</P>

 

スペーサーとして使われている見えない画像

ページのレイアウトを強制するために見えない画像や透明な画像が使われることが多い。「空文字列」(alt="") の代替テキストか「空白」(alt="   ") の代替テキストかのどちらでも文脈が要求しているものを提供する。

例1. 単語やグラフィックの間の注意深く定義された間隔を作成するために画像が使われている。画像が読み込まれない時に単語がつながってしまわないようにするために「空白」代替テキストが使われている。
私の詩には大きなスペースが<IMG src="10pttab.gif alt="  ">ここに必要なのです。

例2. 画像は、グラフィックが一定の位置に現れるように強制するために使われている。
<IMG src="spacer.gif" alt=""><IMG src="colorfulwheel" alt="運命の車輪">

 

将来的な注意

  1. OBJECT を用いて組み込まれた画像のための代替テキストは、後方互換的な解決策であるが、新しいブラウザにまたがる一貫性を有してはいません。
  2. 私達は、スタイルシートを使ってリストマーカーに画像を組み込むことにより生み出される問題を処理する必要があります。
  3. 早くに示唆されていますが、XMLなどといった将来の技術は、制作者がオブジェクトや画像を装飾や地図、リストマーカーなどとしてラベルづけできるようにするでしょう。
  4. 定義済みクラス型も、制作者が画像やオブジェクトに壁紙やナビゲーションバーといったようなリテラルな値を添付できるようにするでしょう。このことは、ユーザに、定義済みクラス型のうちのどの型を見たいか、どれについての説明が欲しいか、どれを無視したいかを選択できるようにするでしょう。これは個人的なスタイルシートで制御できます。

HTML制作者チェックリスト
W3Cワーキングドラフト     1998年4月14日


格付けシステム

各ガイドラインには、その重要性を説明する格付けが結び付けられている場合があります。

[必須]
必須であり、さもなくばいくつかのグループのユーザかそのページを理解することが不可能となるでしょう。
[推奨]
ページをもっと理解しやすくしたり利用しやすくします。

スタイルと構造

  1. [必須]すべてのエレメントがHTML 4.0 定義とCSS1とに従っている。
  2. [必須]スタイルシートなしでもページが読めて利用できる(例.ブラウザがスタイルシートをサポートしていなかったり、ユーザがスタイルシートをオフにしているとき)。
  3. [必須]見出しが適切にネストされており、フォーマットのために使われていない。
  4. [必須]リスト構造やリスト項目が適切なHTMLエレメントを用いて正しくエンコードされている。
  5. [必須]スクロールしたり点滅するテキストが使われていない。
  6. [推奨]テキストが、(検索不能な)グラフィックを用いて表現することによるのでなく、スタイルシートを通じてフォーマットされている。
  7. [推奨]不可視的画像や透明画像がレイアウトを強制するために使われていない。レイアウトを制御するためにはスタイルシートが使われている。
  8. [推奨]BI などの廃止された表現エレメントやアトリビュートが使われていない。
  9. [推奨]HTML構造タグが意味を伝達するためにのみ使われており、表現を伝達するためには使われていない。
  10. [推奨]HTML表現エレメントが表現を伝達するためにのみ使われており、構造を伝達するためには使われていない。
  11. [推奨]水平線、頭字語、略語表記にタイトルがついている。

画像、イメージマップ

  1. [必須]画像やイメージマップすべてに代替テキストがついている。
  2. [必須]重要な情報を表現しているグラフィック(特に地図、テーブル、解説図)に、そのグラフィックの長文説明が結び付けられている(すなわちリンクまたは "longdesc" アトリビュートを経由して)。さらに、制作者が、内部テキストをサポートしているフォーマットについては、内部テキストを画像に組み込んでいる。
  3. [必須]イメージマップがすべてアクセス可能でありキーボード操作が可能である。さらに
    • 各クライアント側イメージマップについては、マップのリンクそれぞれに関連づけられた説明文がある。
    • 各サーバ側イメージマップについては、マップのリンクの一覧がテキストリンクで提供されている(同じページ上やアクセス可能な代替ページ上、OBJECT エレメントの本体内部に)。
  4. [推奨]リンクとして使われている画像に説明的なリンクタイトルがついている。
  5. [推奨]ASCII アートが、代替テキストつきの画像で置き換えられている。

アプレット、スクリプト

  1. [必須]情報を伝達するアプレットやスクリプトについて内容の代替表現がつけられている。
  2. [必須](情報の表現以外の)重要な機能を果たすアプレットやスクリプトについて代替機構が提供されている。
  3. [必須]代替フォーマットで複製できないユーザの相互作用を要求するアプレットが直接にアクセス可能である。
  4. [必須]移動したり点滅するテキストをユーザが凍結できる。
  5. [推奨]アプレットに代替テキストがついている(APPLET"alt"OBJECT"title")。
  6. [推奨]スクリプトやアプレットがキーボードで操作できる。

オーディオ、ビデオ

  1. [必須]オーディオ情報すべてに、結び付けられた字幕がついている。
  2. [必須]ビデオ情報すべてに、結び付けられたオーディオの解説がついている。
  3. [必須]ビデオ情報すべてに、 結び付けられた字幕がついている。
  4. [必須]字幕やオーディオ解説が、直接にまたは同期ファイルを経由して、オーディオやビデオ情報と同期している。
  5. [推奨]自動的に再生される音声に、音声が再生されている旨の視覚的通知がついている。
  6. [推奨]とても短い音声へのリンクにはタイトルがついている。

テーブル

  1. [必須]テーブルセルが明示的に行や列のラベルと結び付けられている。
  2. [必須]文書を段組み編集するためにテーブルが使われていない。
  3. [推奨]単にページレイアウトの目的だけでテーブルが使われていない(代わりにスタイルシートを使うこと)。
  4. [推奨]テキストと数とのテーブルが、代替ページにおいて直線的様式で利用可能である。
  5. [推奨]長ったらしい行や列ラベルが略称化されている。
  6. [推奨]テーブルのまとめが利用可能である。
  7. [推奨]複雑なテーブルについて、情報がカテゴリーにグループ化されている。
  8. [推奨]グラフィックスをポジショニングするために使われているテーブルの中で、代替テキストが折り返されない。
  9. [推奨]テーブルをアクセス可能にできない場合、電話番号、ファックス番号や電子メールアドレスが提供されている。

リンク

  1. [推奨]リンクテキストが、文脈を離れて読んだときにも意味をなすが、うるさすぎない。
  2. [推奨]リンクの一覧に、非リンクの印字可能キャラクタ(空白で囲まれた)が挟まれている。
  3. [推奨]リンクにキーボードショートカットがついている。

フレーム

  1. [必須]各フレーム文書(FRAMESETエレメント)に、非フレームの代替方法(例.NOFRAME エレメント)がある。
  2. [必須]画像が、フレーム内に直接現れるのでなく、フレーム内に組み込まれた文書の一部分となっている。
  3. [必須]すべてのフレームにタイトルがついている。
  4. [推奨]フレームの目的とレイアウトとについての説明文へのリンクが提供されている。

ユーザ入力フォーム

  1. [必須]グラフィカルな「送信」ボタンを作り出すためにイメージマップが使われていない。
  2. [必須]各ラベルがそのフォーム制御と結び付けられている。
  3. [必須]「送信」ボタンとして使われている画像に代替テキストがついている。
  4. [推奨]論理的タブ順が指定されている("tabindex" アトリビュートで)。
  5. [推奨]関連する制御がグループ化されている(FIELDSET エレメントで)。
  6. [推奨]制御のグループにラベルがつけられている(LEGEND エレメントで)。
  7. [推奨]メニューオプションがグループ化されている(OPTGROUT エレメントで)。
  8. [推奨]編集ボックスやテキスト領域にデフォルトの場所確保キャラクタがある。
  9. [推奨]情報を送信するために、代替的な電話番号、ファックス番号、電子メールアドレス、郵政メールアドレスが提供されている。
  10. [推奨]フォームエレメントにキーボードショートカットがある("accesskey" アトリビュートで)。

万策尽きたら...

もし最善の努力を尽くしてもなおページがアクセス可能でなければ、アクセス可能で同等の情報を有し、アクセス不能ページと同じ頻度でメンテナンスされる代替ページへのリンクを提供する。

よいウェブサイト設計慣習

  1. 一貫したスタイルでページをレイアウトする。
  2. 明快で一貫した操作構造を使い、ナビゲーションバーでその構造へのアクセスを提供する。
  3. サイトの全般的レイアウト、使われているアクセス機能やその使い方の説明文をつける。
  4. サイトマップを提供する。
  5. 異なる技術レベルや好みに備えて異なる型の検索を提供する。
  6. サイト内にキーボード操作を妨げるものがないことを確かめる。
  7. テキストと背景色や背景パターンとのコントラストが充分であることを確かめる。(白黒プリンタにページを印字することがよいテスト方法です)。
  8. アクセス機能をサポートしている(またツールを使って文書を閉じたり再び開いたりするときにアクセスを除去しない)設計ツールを使う。
  9. 見出し、段落、リストなどの最初に目立つ情報を置いて、読者が重要な情報を見つけ出すために実行するふるい分けの量を減少させる。
  10. 一連の分離されたページとして存在している文書について、単一のダウンロード可能ファイルを作成する。
  11. 少なくとも 以下のブラウザでページをブラウズして、サイトのアクセシビリティをテストする。
    • テキスト専用ブラウザ(例.Lynx または Lynx ViewerLynx-me といった Lynx エミュレータ)
    • 複数のグラフィックブラウザで
      • 音声やグラフィックを読み込んで
      • グラフィックを読み込まないで
      • 音声を読み込まないで
      • マウスなしで
  12. 自動音声化ブラウザ(PWWebspeak といったようなもの)でサイトをテストすることも助けになる場合がある。
  13. 以下のようなツールでページを検証する。

謝辞

WAI Markup Guidelines ワーキンググループ共同主任:
Chuck Letourneau, Starling Access Services
Gregg Vanderheiden, Trace Research and Development
スタッフ連絡担当:
Judy Brewer, Daniel Dardailler
 
このワーキングドラフトの内容を形作るために多大な貢献をくださっている以下の方々に特に感謝します。
Harvey Bingham, Daniel Dardailler, Al Gilman, Jason White
 
加えて、検討やコメントを通じて貢献くださっている以下の方々にも感謝したいと思います。
Judy Brewer, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Larry Goldberg, Jon Gunderson, Phill Jenkins, Leonard Kasday, George Kerscher, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld

このW3Cワーキングドラフトの元々の草稿は、アメリカ教育省 国立障害リハビリテーション調査研究所からの出資の下で、ウィスコンシン大学 Trace R & D Center により積み上げられた the Unified Web Site Accessiblity Guidelines を基礎とするものです。

Unified Guidelines への協力者の完全なリストは http://trace.wisc.edu/docs/html_guidelines/version7.htm で入手可能です。

私達は、その作業がこの文書の基礎となった Unified Guidelines の積み上げに使われた、下記の参照資料セクションに列挙されている方々にも感謝したいと思います。


参考資料

HTML 4.0 Recommendation.

アクセス性の高いウェブページを設計する -- ガイドライン、オーバービュー文書

  1. Accessible Design for Users with Disabilities. -- Sun Microsystems
  2. The Accessible Web: Web Access Through Adaptive Technology -- Kevin Nguyen, University of Toronto
  3. Accommodating Imperfection -- All Things Web
  4. ALT text recommendations, and notes on viewing situation -- A.J. Flavell, University of Glasgow
  5. Alternative Access to the World Wide Web -- University of Toronto
  6. Any Browser Table Format -- Department of Missions, Abilene Christian University
  7. Best Viewed With Any Browser -- Accessible Site Design
  8. Compatibility & Accessibility -- Towards the creation of an accessible, truly World-wide Web -- All Things Web
  9. Composing Good HTML -- James "Eric" Tilton.
  10. Design Considerations: Readers with Visual Impairments -- Arthur R. Murphy
  11. Designing Access to WWW Pages - Alliance for Technology Access.
  12. Designing HTML Tables to Work with HTML 2.0 Browsers -- Stanton McCandlish
  13. DO-IT HTML Guidelines -- University of Washington
  14. Experiences Implementing Web Accessibility Guidelines in IBM -- Phill Jenkins
  15. For Web Page Designers -- Microsoft
  16. GSA HTML Accessibility Guidelines -- Paul Fontaine
  17. Guide to Writing Accessible HTML -- University of Toronto
  18. Hints for designing accessible Websites -- Royal National Institute for the Blind
  19. IBM Web Design Guidelines  -- IBM Human Computer Interaction (HCI)
  20. IBM Guidelines for Writing Accessible Applications Using 100% Pure Java -- IBM Special Needs Systems
  21. Increasing Access to World Wide Web Sites for Blind and Visually Impaired Computer Users -- Dena Shumila, Jan Richards
  22. InfoUse Web Accessibility Guidelines -- Jane Berliss, Lewis Kraus, Susan Stoddard
  23. LEVELLING THE ROAD AHEAD: GUIDELINES FOR THE CREATION OF WWW PAGES ACCESSIBLE TO BLIND AND VISUALLY HANDICAPPED USERS, Judith M. Dixon, Ph.D., Consumer Relations Officer, National Library Service for the Blind and Physically Handicapped
  24. The Lynx Manifesto -- Dehanced for Lynx
  25. Making Your Site Speech Friendly -- Cathy Anne Murtha, Web Design and Access Specialist, Magical Mist Creations
  26. NCSA Mosaic Access Page
  27. Nimble Document Navigation Using Alternative Access Tools -- Jutta Treviranus, University of Toronto
  28. Starling Access Services Accessible Web Page Design -- Chuck Letourneau
  29. Tables on non-table browsers -- A.J. Flavell, Glasgow University
  30. Unified HTML Accessibility Guidelines -- Previous version of this document
  31. Universal Accessibility -- Government of Canada Internet Guide
  32. Universal Design of WWW Pages -- a DO-IT (University of Washington) Brochure
  33. Universal Information Access on the WWW (COCA)
  34. "Universal Specifications" Accessibility Standards for Web Design -- New South Wales Attorney General's Department
  35. Usability of Information and the WWW -- UCLA Disabilities and Computing Program
  36. IBM Web Accessibility Guidelines -- IBM Special Needs Systems
  37. World Wide Web Access: Disability Discrimination Act Advisory Notes -- Australia
著作権  ©  1998 W3C(マサチューセッツ工科大学フランス国立情報処理自動化研究所慶應義塾大学).すべての権利が留保されている。W3Cの免責(liability), 商標(trademark), 文書利用(document use), ソフトウェア使用許諾(software licensing)規則が適用される。
どら猫本舗 (webmaster@doraneko.org)