HTML文書の検証は、作者がアクセシビリティを確保する上で、おそらく最も重要で簡単な対策でしょう。バリデータは文書のHTMLを文書タイプ定義（document type definition、DTD）に照らし合わせて、HTMLの構文が正確かどうかを検証します。
クオーテーション・マークを書くのを忘れたり間違った属性値を指定したりすることは、HTMLを記述する時にはよくあることです。多くのブラウザはページ作成上のエラーがあっても正常に機能しますが、エラーの対処法はブラウザによって異なる傾向にあり、また、あるブラウザの新しいバージョンではエラーの対処法が変更になっていることがあります。このよい例が、Netscap 1.22とNetscape 2.0との動作仕様の違いです。Netscape 1.22では、例えば<A HREF="oops.html>Oops</A>のように、クオーテーションを閉じ忘れても問題なかったのですが、Netscape 2.0ではクオーテーションを閉じなければなりません。検証を受けた文書はどちらのブラウザでも正しく機能するのですが、作者がNetscape 1.22の表示だけでチェックした文書は、Netscape 2.0で表示するとコンテンツの半分が消えてしまうことがあります。
WDG HTMLバリデータを使ってウェブページをチェックするとよいでしょう。バリデータであると偽っているプログラムの使用は慎重に行う必要があります。文書チェッカーやリント（lint）利用する価値のあるツールですが、バリデータの代用にはなり得ません。
可能であれば、ウェブページはプラットフォームに依存しないものであるべきです。つまり、ウェブページは利用者のプラットフォームや設定に関わらずアクセシブルであるべきです。HTMLの検証はプラットフォームに依存しないサイト作りの重要なステップですが、それだけでは十分ではありません。作者が注意すべきなのは、ウェブページは特定の解像度、カラー階調、フォントやウィンドウの大きさに依存してはならない、ということです。
アクセシビリティに感心のある作者には、さまざまな解像度、カラー階調、フォントやウィンドウの大きさを用いてページを表示してみることが望まれます。上手く作成されたページであれば、どのようなブラウジング環境においても上手く表示され、アクセシビリティが確保されます。また、ウェブページをいろいろなブラウザで表示してみることもできます（できれば、Lynxのようなテキスト・ベースのブラウザを含むとよいでしょう）。また、知り合いにページを読み上げてもらい、視覚障害者や車載ブラウザの利用者がページを聞く様子をシミュレーションしてもらうこともできるでしょう。プラットフォームに依存しないサイトの評価ツールとして、Web Page PurifierとWeb Page Backward Compatibility Viewerの2つがあります。
ウェブの利用者のアクセス方法はさまざまに異なるので、プラットフォームに依存する表現の使用は避けるべきです。例えば、「ここをクリック」という表現はマウスを使わない利用者には不適切です。また、このような表現は、リンクのアンカーを読み上げたり、文書の終わりに要約としてプリントする場合にも、意味をなしません。他にも、作者は「以下をご覧ください」のような表現の使用もさけなければなりません。なぜなら、「以下」という表現は、文章が読み上げられる場合には意味をなさないからです。
HTMLを記述する時、作者が集中すべきなのは文書の構造であって、表示方法ではありません。文書が構造的に記述されていれば、さまざまな異なるブラウジング環境に簡単に対応することができます。HTMLを記述する時、作者はコンテンツの意味を考えるべきであって、コンテンツの見え方・見せ方を考えるべきではありません。文字を太字にしたい場合、そのスタイルを採用する理由を考えてください。強調や重要性を表現したいのであれば、HTMLのEMやSTRONG要素を使用してください。
The FONT要素はしばしば間違って使用されます。例えば、強い強調とか注意をひくことを意図するような<FONT COLOR=red>警告！</FONT>のような場合です。代わりに、<STRONG CLASS=warning>警告！</STRONG>として、.warning { color: red; background: transparent }のようにスタイルシートで定義づけを行ってください。
HTMLには表示や見え方を扱う属性もあります。例えば、ALIGN属性などです。これらは表示方法の作者からの提案として利用するのが無難です。一般的には、スタイルシートの使用が、作者と利用者の双方にとって、より柔軟な解決方法となります。アクセシビリティを確保するには、スタイルシートを使用する場合でも、文書はある特定の表示方法に絶対に依存すべきではありません 。
IMG要素やAREA要素を使用する場合、ページ作者は常にALT属性を使用して、代替テキストを指定すべきです。ALT属性は画像を表示しない利用者のためのものです。このような利用者はウェブ利用者の30％を占めると言われています。
ALT属性には、画像の機能を記述するのが望ましいです。画像の説明ではありません。例えば、画像を表示しない利用者にとっては、ALT="ウェブ・デザイン・グループへようこそ"の方がALT="ウェブ・デザイン・グループのロゴ"よりも便利です。一般的には、Lynxなどのテキスト・ベースのブラウザのユーザには、画像がテキストで完全に置き換えられるものでない限り、ページに画像があるということが分からないはずです。このような意味で、例えば、写真アルバムやアート・ギャラリーなどのサイトでは、画像の機能と説明は本質的に同じものだと言えます。このため、画像の説明がALTテキストとして適切になります。
純粋に装飾目的の画像を使用する場合には、ALT=""と記述して、画像には内容がないことを明示するべきです。装飾のための円形の画像（decorative bullet）はALT="*"や似たような記述で置き換えるべきです。ALT="黄色い円形画像"とすべきではありません。画像がテキストや他の画像と一緒に使用されている場合、ALT=" [私の写真] "やALT="ウェブ・デザイン・グループ ~"のように、何らかの形で区切りをする必要があるかもしれません。
ALT属性についての詳しい議論は、Use of ALT texts in IMGsという記事を参照してください。
画像として文字を使うことはウェブでは非常によくありますが、視力が悪い利用者や小さいモニターを高解像度で使用している利用者にとっては、見にくいことがあります。HTMLでは、文字はユーザの設定したフォントの大きさで表示されますが、画像として文字を使用すると、作者が利用者に代わって、ある絶対的なフォントの大きさをピクセル単位で選択することになります。利用者によって嗜好は異なるので、適切なフォントの大きさを推測するのはよい考えではありません。このため、作者は画像として文字を使用するのを可能な限り避けるべきです。
カスケーディング・スタイルシート（Cascading Style Sheets、CSS）は、かっこいい文字を画像を使用せずに表示させるためにしばしば利用されます。CSSを使えば、ページの作者は、フォント, 色, 背景, 文字間隔など、文字の表示方法の属性を指定することができます。
イメージ・マップは問題となるのは、画像を表示しない利用者へのサポートがほとんどないからです。イメージ・マップを使用する時には、可能である場合には、サーバ・サイド・イメージ・マップと組み合わせて、クライアント・サイド・イメージ・マップを使用するべきです。クライアント・サイド・イメージ・マップでは、ALTを属性をAREA要素に常に記述するべきです。
イメージ・マップは、「必然性」がなければ使用しないでおくべきです。例えば、ツールバーの画像であれば、いくつかの画像を組み合わせたり、単に文字を使えばより簡単に効率よく作成することができます。一方で、人体の器官や国の地域をクリックさせるようなイメージ・マップは、ウェブでよくありがちなツールバーの画像よりも自然でわざとらしくありません。より便利にするには、代替の文字情報を記述しておくとよいでしょう。
HTMLのBODY属性で色を設定する場合、ページの作者はすべての色の属性を指定するべきです。BGCOLOR、TEXT、LINK、VLINK、ALINKのうちの1つとかいくつかだけを指定すると、ページがアクセシブルでなくなる危険性が生じます。なぜなら、利用者が選択している色によっては作者が指定した色との組み合わせでは文字が読めなくなることがあり得るからです。作者として、利用者があなたと同じようにブラウザを設定しているとは仮定しないでください。
BODY属性での色は3組の16進数を使用して#rrggbbや#RRGGBBのように指定されるべきです。なぜなら、古いブラウザは名前で指定された色をサポートしないからです。Netscape 1.22は色の名前のすべてを青色と解釈してしまいます。
背景画像をBODYのBACKGROUND属性で指定する場合には、すべての色の属性を指定するべきです。注意しなければならないことは、文字色が有効に機能するようなBGCOLORを選択することです。なぜならば、画像を表示しない利用者には背景画像の代わりに背景色が表示されることになるからです。
HTMLのFONT要素（と関連要素のBASEFONT）は、一般的には、アクセシブルなウェブサイト作りにおいては使用しないべきです。SIZE="+1"やSIZE="-1"のような属性指定は比較的問題ありませんが、絶対的な大きさをSIZE=1のように指定すると、文字が小さすぎて読めなくなってしまうことがあります。スタイルシートを使うと、FONTを使う場合よりも柔軟に、フォントの大きさを相対的に変化させることが可能になります。
FONT要素のCOLOR属性の使用は常に避けるべきです。なぜなら、利用者が作者の指定した色を使用しないように設定したとしても、この機能をサポートしているブラウザの多くはその色を優先的に使用してしまうからです。結果として、利用者が選択した背景色とのコントラストがうまくとれない場合には、文書が読めなくなってしまうことがあります。
FONT要素のFACE属性についてもまた、この機能をサポートしているブラウザの多くが、ユーザ自身の設定を無効にしてしまいます。このために、プラットフォームと環境の設定によっては、ブラウザがとても読みにくいフォントを選択してしまう、という結果になることがあります。忘れてはならないのは、同じフォントでもあなたのプラットフォームとは異なる場合には異なって表示されることがある、ということです。
ギリシャ文字、数学記号、特種記号（dingbut）を表示しようとする場合には、FACE属性もまた使用すべきではありません。FONT要素は表示方法を単に提示するだけなので、その表示方法が使えない場合でもコンテンツが意味をなしていなければなりません。ブラウザは<FONT FACE=Symbol>a</FONT>をギリシャ文字のアルファとして表示しません。 このバグは将来修正されるかもしれません。
FACE属性についての詳しい議論は、<FONT FACE> considered harmfulを参照してください。FONT要素についての優れた議論として、Warren SteelのWhat's Wrong With FONT?があります。
ページの作者は、単なるレイアウトのためにテーブルを使用するのは可能な限り避けるべきです。残念ながら、レイアウトを目的としてテーブルを絶対に使わないのは、作者にとっては柔軟性がなくなります。なぜならば、CSSのレイアウト機能はテーブルを完全に置き換えるのには十分にはサポートされていないからです。テーブルをレイアウト目的で使用する場合には、作者は以下のことを考慮すべきです。
JavaScript（または、JScriptやVBScript）はすべてのブラウザでサポートされているわけではありませんし、その機能を無効にしている利用者もいます。JavaScriptを使用する場合には、それに依存すべきではありません。
例えば、JavaScriptを使って、リンクから小さいポップアップ・ウィンドウを表示させる場合、作者は以下のようなスクリプトを使うべきではありません
<A HREF="javascript:window.open('foo.html', 'popup', 'scrollbars,resizable,width=300,height=120')">
なぜなら、JavaScriptを有効にしていない利用者にとっては、リンクが機能しないからです。以下のようにすれば、すべてのブラウザで機能するでしょう。
<A HREF="foo.html" ONCLICK="if (window.open) { window.open('foo.html', 'popup', 'scrollbars,resizable,width=300,height=120'); return false; }">
アクセシビリティ：目次 ~ なぜアクセシブルなウェブページを書くのか？ ~ アクセシビリティに関する神話
Copyright © 1997-2002 Liam Quinn. All rights reserved.
日本語訳：青山知靖（Tommy AOYAMA）