HTML文書を検証しておくことは、おそらく最も重要なことで、非常に容易でもあり、制作者がアクセス性を確保するためにできることです。検証は文書HTMLを 文書型定義（DTD）に対してチェックし、HTMLの構文（使い方）が正しいかを確認します。
引用マークの付け忘れや間違った属性値の使用を、しばしばHTMLを書く際におかします。多くのブラウザではこのエラーを回復補足しますが、補足のやり方はブラウザによって様々で、ブラウザのバージョンが変わると補足方法も変わります。典型的な例としては、Netscape 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検証を使ってウェブ・ページをチェックすべきです。 検証すると間違った言われかたをするプログラムに注意しなければなりません；文書チェックカーやリントは価値ある手段ですが、HTML検証の代わりにはなりません。
＿＿訳者注：日本語対応"Another HTML-lint gateway"は、sgml検証もするリントで、HTML-lintとは一味違うと言うことで、"Another"をつけ"Another HTML-lint gateway"と銘々されています。＿＿
出来るだけウェブ・ページはプラットフォームに依存すべきではなく、ユーザーのプラットフォーム（os環境）や設定に関わりなくアクセスできるべきだという意味です。 検証はプラットフォーム非依存性を確認する鍵になるステップですが、それだけでは十分ではありません。制作者はまた、ウェブ・ページが或る種の解像度・色彩幅・文字サイズや画面サイズに依存していないことを確認する配慮もすべきです。
文書のアクセス性に関心を払う制作者は色々な解像度・色彩帯・文字サイズそして画面サイズでページを閲覧するようにしましょう。よく出来たページはどのようなブラウザにおいても調整されアクセス性を保ちます。また、制作者は多くのブラウザでウェブ・ページを閲覧できるようにでき（ Lynxのようなテキスト専用ブラウザを含めるのが望ましい）、目の見えない人や車の中のユーザーがページをどのように聞くかをシミュレートするためにウェブ・ページを大声で友達に読んでみてもらうこともしておきます。ウェブ・サイトがプラットフォームに依存していないことを確認する際制作者にとって手助けとなる手段が二つあり、 Web Page PurifierとWeb Page Backward Compatibility Viewerです。
様々な方法でウェブにアクセスしてくるので、プラットフォームに依存している句文は避けられるべきです。例えば、 「ここをクリック」"click here"は、マウスを使わない人には適切でなく、また要約として文書の終でリンク先が音声で読み込まれたり印刷されたりした場合は役く立ちません。制作者は ［以下参照］といった句文も避けるべきで、というのも文書を読み上げる場合には［以下］といっても意味がわかりません。
HTMLを書く際、制作者は体裁よりも文書の構造に集中しなければなりません。構造的にマーク付けされた文書は、色々な閲覧環境に容易に適応できます。HTMLを構成する際、制作者はどのように見えるかではなくて内容がなにを意味しているかを考えるべきです。テキストを太文字にしたいなら、 何故このスタイルが必要なのかを考えるべきです；強調や最強調が本当に必要なら、HTMLの EMや STRONG要素を使いましょう。
FONT要素が、最強調や見出しの目的でしばしば誤用されています。
<FONT COLOR=red>Warning!</FONT>でなくて、
スタイル・シートで定義した
.warning { color: red; background: transparent }
と一緒に
<STRONG CLASS=warning>Warning!</STRONG>を使いましょう。
ALIGN属性といったHTMLの体裁（見え方）用属性は、見え方の示唆（指定）として安全に使うことができるものもあります。一般的に スタイル・シートは、制作者とユーザー両者にとってより柔軟な解決策を提供します。アクセス性を保には、文書は特殊な体裁に、スタイル・シートで達成される場合をも含めて、 依存すべきではありません。
IMGや AREA要素を使う際には、制作者は ALT属性を使って代わりとなるテキストを提供しておくべきです。 ALT属性が、全ウェブ・ユーザーの30%と推定される画像読み込みをしていないないユーザーに、表示されます。
ALT属性は、画像の説明でなくその働きを知らせるのが最も良い使い方です。例えば、 ALT="Welcome to the Web Design Group"が、 ALT="Web Design Group logo"よりも画像を読み込まないユーザーには役に立ちます。一般的に Lynxなどのテキスト専用ブラウザのユーザーは、画像がテキストで完全に置き代えられる内容でないなら、ページの画像を気にしていません。写真アルバムや芸術ギャラリーなどの場合、画像の機能と説明は本質的に同じで、画像の説明は ALT文にとって適しています。
純粋に装飾的な画像では ALT=""を使って、画像には内容を伴っていないと分かるようにしておくべきです。装飾的な丸は ALT="*"やそれににたもので置き代えておくべきです−− ALT="Round yellow bullet"ではなく。画像がテキストや別の画像と並んでいるいる場合は、 ALT=" [Photograph of me] "や ALT="Web Design Group ‾"といった区別する書式が必要になります。
ALT属性についての詳しいことは、作品 Use of ALT texts in IMGsを参照下さい。
テキストの画像化はウェブ上ではよく見られますが、視力の弱い人や小さな画面で高解像度では見づらくなります。HTMLでは、テキストはユーザーの好みの文字サイズに従って調整されますが、テキストの画像化の場合制作者がユーザーの見る文字サイズをピクセル単位で絶対化します。色々なユーザーはそれぞれの好みを持っていますので、最適の文字サイズを推測しようとするのは良いとは言えません。かくて、制作者はできるだけテキストの画像化を避けるべきです。
カスケーディング・スタイル・シートは、画像を使わないで引き付ける魅力のあるテキストの提供にしばしば使われます。CSSで、制作者はテキストの物理的な特有値を幾つも示唆でき、 font・ color・ background・ letter spacingなどで可能です。
イメージ・マップ使用は問題があります、というのはサポートが貧弱で画像を読み込まないからです。イメージ・マップを使う場合必ずサーバー側イメージ・マップと組み合わせてクライアント側イメージ・マップを使うべきです。クライアント側イメージ・マップで、 AREA要素の ALT属性は、必ず使うべきです。
イメージ・マップは、それが「自然」でない場合避けるべきです。例えば多くの画像ツールバーは、別々の画像の組み合わせや単純にテキストを使って作成できます。他方、体の器官へのリンク用イメージ・マップや国の領域へのリンク用のイメージ・マップは自然で、ウェブ上でよく見かける画像ツールバーより工夫はいりません。できるなら、代替えテキストはこの場合手助けになります。
HTMLの BODY属性を使って色設定をする場合、制作者は 全ての色属性を特定しなければなりません。ただ一つや BGCOLOR・ TEXT・ LINK・ VLINKやALINKの中の幾つかだけを特定すると、アクセスできないブラウザの危険をおかすことになります、というのもユーザーが選んでいる色が制作者が特定した色に対して判読できなくなるかもしれないからです。制作者として、ユーザーも同じブラウザ設定をしていると思ってはいけません。
BODY色は必ず #rrggbbや #RRGGBB形式の 十六進三組で特定すべきで、旧いブラウザは色彩名をサポートしていないからです。Netscape 1.22は色彩名を全て青と解釈します。
BODYのBACKGROUND属性を使って背景画像を特定する制作者も、全ての色彩属性を特定しておくべきです。テキスト色に対して判読できる BGCOLORを選ぶこと確かめておきます、というのも画像を読み込まないものは背景画像の代わりに背景色を見るからです。
HTMLのFONT要素（そしてその cohort BASEFONT）は、アクセス性の良いウェブ・サイトを作成する場合一般的には避けるべきです。 SIZE="+1"や SIZE="-1"といった属性特定は、比較的害はありませんが、 SIZE=1といった絶対サイズは読むには小さすぎるテキストをもたらします。制作者は スタイル・シートによって、 FONTでよりも、柔軟性のある相対的な文字サイズ変更を指定できます。
FONT要素の COLOR属性は常に避けるべきで、というのも多くのこれをサポートしているブラウザは、ユーザーが制作者特定色を上書きしようとしている場合なおこのフォントを優先しするからです。その結果、文字色が読み手の選んだ背景に対して文字が十分コントラストをえられなくなり判読できなくなります。
FONT要素の FACE属性もまた、多くのブラウザでユーザーが上書きすることができません。その結果ユーザーのプラットフォームや設定環境では読み辛い文字をブラウザが選ぶことになります。同じ文字があなたのプラットフォーム以外のプラットフォームでは非常に異なって見えるかもしれないということを忘れないようにしましょう。
FACE属性はまた、ギリシャ文字・数学記号や飾り活字を表示するのに使ってはいけません。 FONT要素はただ体裁を示唆するだけで、従ってその体裁がなくてもなお内容はわかります。ブラウザは <FONT FACE=Symbol>a</FONT>をギリシャ文字アルファとして表示しません；このバグは将来修正されるかもしれません。
FACE属性の詳しい議論は、 <FONT FACE> considered harmfulを参照下さい。 FONT要素についての他の優れた議論として、Warren Steel氏の What's Wrong With FONT?（翻訳版）があります。
制作者は単にレイアウトの目的にテーブルを使うことはできるだけ避けるべきです。残念なことに、レイアウトのためにテーブルを全く使わない制作者の柔軟性を制限することになります、と言うも CSSレイアウト手段がテーブルに置き代わるには十分でないからです。レイアウトにテーブルを使う場合は、制作者は以下のことを念頭にいれておくべきです：
ジャバスクリプト（JScriptやVBScript）は、全てのブラウザでサポートされていませんし、その機能を禁止にしているユーザーもいます。ジャバスクリプトを使う場合、それに頼るべきではありません。
例えばジャバスクリプトでリンクから小さなポップアップ窓を開く場合、制作者は以下のように使ってはいけません。
<A HREF="javascript:window.open('foo.html', 'popup', 'scrollbars,resizable,width=300,height=120')">
何故なら、機能するジャバスクリプトがないならこのための機能は作動しません。以下のようにすれば、全てのブラウザ上で作動します：
<A HREF="foo.html" ONCLICK="window.open('foo.html', 'popup', 'scrollbars,resizable,width=300,height=120'); return false">
インデックス ‾
アクセスしやすページを書く理由 ‾
アクセス性神話
Copyright C（著作件） 1997-98 Liam Quinn. All rights reserved.