「これに尽きる」と言えることがあるとすれば、「よくチェックすること。」これでしょう。
2001.02.
HTML 4.01 Strict に関して嘘を書いていたのを修正しました。あと、HDML とかの辺りがちょっと曖昧だったので削除しました。内容的に大きな変更はありません。
2002-06
HTML というものは人工言語であり、そこに文法があります。人間同士のコミュニケーションと違い、人工言語においては文法は破綻しているけど意味は通じる、ということはあり得ません。正しい文法に則りましょう。（実際にはブラウザの仕様やバグで破綻した文法がまかり通っていたりしますが。）
特に守ってほしいことを少し以下に挙げておきます。
HTML は他のプログラミング言語などと比べて極めて短い歴史しかありません。しかしその短い間に信じられないくらいに急速に普及し、考えられないくらいに爆発的に進化（変化）してきました。
今、HTML は 4.01 でひとまずその拡張の歴史に一段落がつき、XHTML という形で XML 準拠の方向に落ち着きつつありますが、同時に「HTML のようなもの」を解釈する端末の裾野はどんどん広がりつつあります。つまり、HTML にはこれまでの歴史的な変化と今後のブラウズ環境の幅の広がりという両方の意味で、非常に多くのバージョンがあるのです。また、HTML の正体はただのテキストファイルです。テキストファイルというのは最も基本的なファイルの形式であり、そのファイルは開いてみるまでどのような形式であるのか知る方法がありません。拡張子が .htm や .html であるというのは、あくまで「HTML のようなもの」らしいと予想できるということに過ぎません。
以上のことを踏まえて、HTML 文書では、まずいちばんはじめにそのファイルが これこれのバージョンの HTML 文書であるという宣言を行う必要があります。この宣言が DOCTYPE宣言です。
これにはいくつかあり、現在使われている主なものは
■ HTML 3.2
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
■ HTML 4.01 Strict/Transitional/Frameset
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
~~~~~~~~~~~~~~~~~~~ ```````````````````````````````
~~ の部分は大文字でも小文字でも構わない。
`` の部分の大文字小文字は区別される。
■ Compact HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD Compact HTML 1.0 Draft//EN">
などがあります。*1
最近 Web page を作り始めた、あるいはこれから作るという人の多くは DOCTYPE宣言をしていないか、HTML 4.01 *2 Transitional で書いていることと思います。現在のメジャーなグラフィカルブラウザの見た目の設定を前提にした表現力に期待するのであれば、Transitional が妥当でしょう。
Transitional というのは文字通り「過渡期の」という意味で、拡張路線というかブラウザの実装を追随した HTML 3.2 時代の名残りのようなものです。細かい話は HTML の歴史に詳しいサイトや本当に正しい HTML を理解している方のサイトに譲りますが、W3C の HTML に対する考え方は装飾に関する指定はスタイルシートで記述し、HTML そのものは本来の目的だった文書構造の記述に集中するというものです。それを具体化したのが Strict というバージョンです。*3
そのほかにこれからブラウザの対応が進んでくるだろうってのが XHTML です。
■ XHTML 1.0 Strict/Transitional/Frameset
■ XHTML 1.1
■ XHTML Basic
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">XHTML からは `DOCTYPE' や `PUBLIC' は大文字で書くべし、となっています。また、その間にくる `html' は小文字に決まっています。1.0 ではまだ Strict, Transitional, Frameset という区別がありますが、1.1 では一本化されていて、これまで延命されてきた望ましくないタグは全部使っちゃだめということになりました。XHTML Basic はモジュール化された XHTML の基本セットで、携帯電話などはこれをベースにした WML に統一されていく方向のようです。無理して最新の厳密な文法に従う必要もないでしょうけど、これからは XHTML を基本にしていくと、情報の共有という意味ではいいんじゃないかと思います。
こんな感じ。これらはその文書で使っている HTML のバージョンに合わせて正しくセットしてください。これが正しくセットされていないと、ブラウザの誤作動や文法チェッカの誤作動に繋がります。以前はこの DOCTYPE宣言がどうなっていようが関係のないブラウザが多かったのですが、最近のブラウザではこの宣言によって文法解釈から表示イメージの作成時の動作が変わるものもありますので、やはり期待通りの結果を得るためには正しい宣言が必要です。（ただし、そういうブラウザについて、自分では確認を取っていません。）
他にも携帯電話などで用いられ、DOCTYPE 宣言のあるもの、ブラウザ依存で DOCTYPE 宣言のないものなどいろいろありますが、端折ります。（HDML はちゃんと W3C に submit されているものがありました。ご指摘ありがとうございます。）
HTML 文書は最初の <HTML> でスタートすると思っている人が多いようです。確かに HTML 文書の内容としてのスタートは <HTML> ですが、その前に「これは HTML 文書ですよ」という宣言がないと HTML 文書としてスタートすることができないのです。HTML 文書を作る場合は必ず初めに正しい DOCTYPE を宣言してください。なくてもブラウザはなんとか表示しますが、Another HTML-lint などの頼りになる文法チェッカを使う場合などに不便な思いをしますしね。
なお、UTF-8 以外の文字コードで XHTML に則る場合は DOCTYPE 宣言の前に XML 宣言を書かないとダメです。この辺はまだまだブラウザの実装が追いついていないと判断して触れません。（というか面倒くさい。）
文字コードを正しくセットしてください。伝統的な日本語の文字コードは Shift JIS, JIS, EUC-JP です。新しくは Unicode でしょうか。Unicode があらゆる意味で安心して使える環境になれば、多言語環境の実現て簡単なんでしょうか…。
この指定は head 要素中の meta で行います。というのが通例です。*4これを正しく指定してあげないとそのページは文字化けしやすくなります。（必ずすると言い切れないのがややこしいところ。）ブラウザにも文字コードの自動判別の機能はたいていついているのですが、文字コードの判別というのはそれほどアテにはなりません。
日本語の文字コードの指定方法は以下のいずれか。
charset= 以下の大文字小文字は関係ないみたいです。
外国語と日本語を混在させて書くような人はどんどん Unicode になっていくんでしょうかねぇ…。自分ではそんなページ作らないので全然縁がないのですが。
head の中の title 要素は必須です。
ブラウザのタイトルバーやブックマーク、履歴にこれらの情報が残るので書いた方がよい、という解説も多いですし、私もそう思っていたクチなのですが、これは必須です。書かなきゃならんのです。文法的に。
もひとつ、日本語を使う場合は charset を指定したあとにしてください。方法は上に書いた meta を使うなどです。理由は分かりますよね。
で、書けばいいってものとも違います。例えば「○○のホームページ」であれば構いませんが、中にはただの「ホームページ」になっていることも、ひどいときには「newpage」になっていることもあります。あとから見ても全然意味が分かりません。同様に「サイトマップ」、「ブックマーク」、「リンク」、「Welcome to Adobe GoLive !」なんかも全然意味の分からない言葉です。こんなことは実際に自分があちこちの Web を眺め、ブックマークを活用していればすぐに気付くと思うのですが、案外自分が作るときには注意が行き届かないようです。
これはアクセシビリティの範疇でもあるんですが、HTML 4 からは必須になったので文法の方にも入れておきます。画像を使う場合は alt 属性は必須です。
また、img だけに限らず様々な要素に title という属性が導入されました。これを利用してもユーザーに情報を提供することが（対応しているブラウザなら）可能です。今後はこの title 属性も要チェックでしょう。
frameset のページの、これが正しい構造です。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<html>
<head>
....
</head>
<frameset>
<frame src="">
<frame src="">
<noframes>
ここがフレームに対応していないブラウザへの文書
</noframes>
</frameset>
</html>
けっこう、勘違いしていると思います。私も、普段 frame を使わないもんだから長いこと勘違いしていました。（とか言いながら上のもやっぱり間違っている可能性アリ。）
HTML の文書は要素の組み合わせで成り立つものだという説明を覚えているでしょうか。覚えていますよね。だから至極単純、何の要素でもない文書は書いちゃダメなんです。
何のことか分からない？ 例えばこれはどうでしょう？
<body>
ようこそ私のホームページへ！
</body>
変ですよね。
他にもたくさん注意すべき点はありますので、できるだけ文法チェッカでチェックしてみてください。まー残念ながらブラウザの方も文法違反を平気でしているので、正しい文法であればいろんな環境で問題なく見れるようになるのかというと、現実にはそうとは限りません。
じゃーなんでわざわざ文法チェックなんかするの、という気もしますが、反対に、あなたはすべてのブラウザを知っているのですかという質問をされた場合、「んな無茶な」と言いますよね。そらそうだ。
実は、ブラウザと呼ばれるものは古いもの新しいものを含め、かなりたくさんあるんですよ。最近では携帯電話や PDA なんかでもインターネット、なんつー時代ですから、それを考えるとブラウザの種類を把握している人なんて、はっきり言ってほとんどいないでしょう。
そうなったとき、「何を基準にするか」なんです。Windows版 IE を基準にしますか、本来の文法を基準にしますか、ということなんです。ま、「俺的基準で行く」という人はなんでもいいんですが。
なんだかんだゆって数字ってのは強いわけで。
例えそれが文法的に正しい記述であっても世の中の大半の人の使っているブラウザで期待通りに動かなければやっぱダメですよね。例えそのブラウザに明らかなバグがあっても、です。スキルと時間に余裕があれば文法的に正しく動作も期待通り、という解を追求するのがいいでしょうけど、すべての Web 製作者にそんなことを求めるのは無理ってもんです。適当なところで妥協してください。
ただし、Windows版 IE で正しく見れたからそれでよし、というのはさすがにやめてください。せめて Netscape 4.x でもチェックしましょう。早晩このブラウザを捨てることができたらいいな、とは確かに思いますが…。（Windows ユーザーは K-Meleon などの Gecko エンジンの軽いブラウザを使うように啓蒙しましょう。68 Mac の iCab がバシバシ落ちるのはなんとかならんのか…。）
できれば Mac の IE と Netscape でもチェックしましょう。特に IE は Windows 版とかなり違う動きを見せます。
Netscape 4.x を使わなくてよくなる日はくるんでしょうかねぇ…。Gecko エンジンが携帯端末でも使えるってーのなら、早く 68 でも G3 以前の PPC でもびゅんびゅん動くブ ラウザを出してほしい。
Netscape 7 のプレビューを出す前に 6 を完成させろ！（2002-06）
仮に自分がブラウザを一つしかインストールしていなくても以下の項目について設定でオフにしてチェックしておきましょう。
これはもうあちこちで言われているので、みなさんも気をつけているかもしれません。でも実際に画像の表示をオフにして自分の作ったサイト全体をチェックしている人はほとんどいないでしょう。（かくいう私もサイト全体はさすがにチェックしていません。）
画像の使い方がシンプルなうちはまだいいのですが、細かいテクニックを織り交ぜている場合は画像オフだとかなりまぬけなことになります。注意しましょう。
最近では見栄えの指定はスタイルシートで行うのがかなりポピュラーになってきています。いい傾向なんでしょうけど、スタイルシートをオフにした途端何が書いてあるのかよー分からん、ということもあり得ます。これはスタイルシートの理念を誤解した HTML マークアップを施した結果でしょう。
念のためスタイルシートをオフにしてブラウズしてみましょう。IE では完全にオフにするにはレジストリにタッチする必要がありそうで、なかなか大変ですけど。まったく、いつの間に Web づくりはこんなに敷居の高いものになったんでしょうね :-P
と、書いていたら空母さんから「ス切リボ」あるやんけ、というご指摘をいただきました。Win版 IE 5 以降でスタイルシート切り替えの機能を簡単に追加できるようです。便利そうです。（自分では試してませんけど。）（2002.03.追記）
マルチメディア関係のプラグインも最近ではかなり当たり前に使われますが、仮にこれが動かなかった場合、そのサイトの内容はユーザーに伝わるでしょうか？
セキュリティを考慮して Java の機能を意図的にオフにしている人は意外と多いと思います。これもオンの場合とオフの場合の動作をしっかりチェックしておきましょう。
JavaScript は最も手軽な「ホームページ装飾法」(笑)ですが、これが使えなかった場合、意図的にオフにしてある場合、ということについてはなかなか考えの回らない人が多いようです。（私もそのうちの一人だと思いますが :-)
一人だけのチェックには自ずと限界があります。できるだけバラエティに富んだ環境でチェックできるように、知り合いを頼ってください。
ムキになってテキストブラウザでの動作のことを指摘する人がいて、そういうのを見聞きすると「デキの悪いホームページ」と同じくらいに気分がよくないものですが、確かにテキストブラウザを無視するのはよくないでしょう。
特にその内容が文章主体のページはやはりより多くの環境でブラウズできるように配慮された方がよいでしょう。幸い、Another HTML-lint など、テキストブラウザでの動作を確認できるサイトがあるので、それを利用するとよいでしょう。テキストブラウザの多くはフリーソフトですが、みんながみんなテキストブラウザをインストールして動かせるわけではありませんから。
同じように音声ブラウザをフリーでチェックできるようにならないだろうか…。
基本的には自分の作り出した情報がユーザーにとって意味があるのか、ないのか、というところが問題です。（いやいや、内容的にではなく。）
例えば内容を音声で聞いている人には画像は意味がないですし、JavaScript や Flash などの仕掛けも、見た目のレイアウトも何の意味もありません。意味がないだけでなく、サイトの見せ方をそのような仕掛けばかりに頼っている場合はサイトそのものが意味を持たなくなってしまう可能性もあります。
また、文字だけの場合も、文字の色や大きさを前提に情報を提示することも、モノクロ環境や音声環境では意味を持ちません。同じようにフレームに対応していない環境ではフレームの情報は意味がありません。スタイルシートに対応していない環境ではスタイルシートによるデザインは意味がありません。
そこで、画像、スクリプト、プラグイン、色、フレーム、スタイルシート、ディスプレイ、マウスなどの様々な装置、技術が使えない場合にも支障のないようにページを構成することがアクセシビリティの確保になります。
また、むやみな自動化も慎むべき*5、ということになっています。点滅や移動などの視覚効果は、ユーザーの意思を尊重してむやみに動かさない、blink とか marquee は避ける。ウィンドウのポップアップなんかも避ける。自動的にポップアップさせたい場合はそうでない操作も用意する。refresh を使った自動的なページの移動も避ける、などです。
このサイトはあちこちでウィンドウのポップアップを自動で行っています。JavaScript を使っているので JavaScript をオフにすればポップアップしないようになるのですが、JavaScript を使っている限りポップアップを止められないので、そういう意味ではアクセシビリティは低い、ということになります。…かねぇ？
本当に低くなってんのかなぁとか、思いますよね、やっぱ。新しいウィンドウを開く操作は簡単で一瞬でできる、と断言できる人はいいですけど、逆にその操作が簡単ではない、あるいはそういう発想の湧かない人にも読みやすいように注を別ウィンドウに分けているのですが、これがアクセシビリティの低下と言われるとちょっと悔しいですよねぇ(^^;） アクセシビリティって、判断基準が曖昧で難しいなぁ。
例えばマウスです。マウスに依存したらいかんのです。マウスを使っていないユーザーのことも考えろ、と。だから「ここをクリックしてください。」とか「押す」なんて表現はアクセシビリティ的にはだめだめなのです。印刷した場合はそもそもブラウザのリンク機能そのものが無効です。（だから本当は「戻る」も完全に間違い。）
それ以前にディスプレイに依存してはいかんのです。だから「ここ」はすでに失格です。「ここ」は視覚的な情報です。ディスプレイを使っていない人たちには意味がありません。
「『（移動先のページのタイトル）』を参照してください」などの表現を使うべし、ということですな。
スクリプトを使って様々なイベントを処理できます。マウスが通過した、マウスをクリックした、読み込みを中止した、などなど。
では、イベントが発生しない場合はどうなるのか。まー分かりやすく言えば JavaScript がオフだった場合どないすんねん、ということですな。JavaScript がオフだとリンクを辿ることすらできないようなつくりにしてはいかん、ということです。（たまに本当にあるんですな、そういうサイトが。）
その HTML 文書の言語情報をユーザーに伝える方が親切です。これは文字コードではなく言語の方です。別にこれがなくても文字化けはしませんけど、ユーザーに親切です。特に途中でいろんな言語が混ざるような場合は指定しておいた方がよいです。ブラウザによってはこの言語情報に基づいてフォントが自動的に切り替わってくれるのでより読みやすくなりますし、読み上げソフトでも多言語環境への対応がスムーズにできるかもしれません。
具体的には様々な要素に指定することができる lang属性がこれに当たります。
フレームはお手軽にナビゲーションと内容を切り離すことができて実に嬉しい機能なのですが、逆に言うと不完全なページを量産する技術になってしまいやすいです。
フレームでメニューと本文を分けるのはよくある方法ですが、仮に検索エンジンで本文のページがヒットし、その本文のページにナビゲーションとして有効なリンクが何にもなかったらどうなるでしょう？ ま、少し慣れていれば表示されているページのアドレスを確認してより上の階層を表示するなんてことは造作もないことです。でもその上の階層へのリンクを一つ用意するだけでずいぶん助かる人も増えるでしょう。右クリックとかね、実際できない人だってたくさんいるわけですよ。音声ブラウザだったら見た目でなんか変だな、と感じることもできやしません。
また、フレームを使うときはフレームに対応していないブラウザのための情報も書け、とあちこちの参考書で述べられていますが、これが「フレーム対応のブラウザでご覧下さい。」だったらこりゃもう笑い話ですよ。フレームに対応していないブラウザでそのページを訪れた人が、実際にはフレームに対応しているブラウザを使えるけど、そのときたまたま使っていなかったのであれば、この情報は意味があります。そういう人も中にはいるでしょう。フレームに対応していないテキストブラウザを使っている人たちの多くは、比較的コンピュータに明るい人が（セキュリティとかいろんな理由で）意図的に使っていることが多いように見えます。でもそうでない人たちのためにはどうしたらいいんでしょう？
確かに、我々、Windows や Mac を使っている普通の PCユーザーからすれば、逆にフレームに対応していないブラウザがどんなものなのかを知ることの方が難しいです。私も昔はテキストブラウザを動かしていましたけど（何しろマシンがものすごく遅かったから）、今ではそれを動かすメリットが（動作チェック以外に）ないので動かしていません。フレームに対応していないブラウザは身の回りにないわけです。だからフレームに対応していないブラウザへの対応ってのは、考えるのが面倒なだけで何にも面白くないんですよ。
正直、個人的にはフレームはそういった諸々の対応を考えるのが面倒なので使いたくありません。フレームを使う場合はフレームがなくてもブラウズに困らないようにすべしと言われる。でもフレームがなくてもナビゲーションを実現できるのであれば、フレームを使う意味はないんですよね。ま、フレームを使ったスゲーかっこいいサイトでも見つけたらまた方針が変わるかもしれませんが、幸か不幸か今までそんなサイトはお目に掛かったことがありません。
アクセシビリティというのは WWW をブラウズできる端末、ブラウズできる人たちの幅を最大限に広くし、HTML がその本来の目的であった特定の環境に依存しない情報共有を実現するための考え方です。
それは確かに素晴らしいし重要です。
でも、果たしてすべての Web が環境に依存しない情報でしょうか？ すべての道具には想定されていない使い方が存在します。今のような「便利なWeb」は果たして想定されていた姿でしょうか？ デザイナーによる見易いとは言いがたい、でも凝りに凝ったデザインのサイトは果たして想定された姿でしょうか？ でも現実にそういうサイトが見た目に我々を楽しませ、刺激を与えてくれ、生活を豊かにしてくれています。
私は、こういう広範に共有される情報としてではなく、環境を限定してでも表現として成り立っている Web を文法やアクセシビリティで否定するのはナンセンスだと思います。目的がハナから違うんだもの。例え HTML の当初の目的がどうあれ、です。WWW は HTML だけでは語れないのです。
こういうサイトでのアクセシビリティはどうあるべきでしょうか。はっきり言って等価な代替手段はないでしょう。結局、これこれのブラウザで見てくれ、このサイトはこのようなことを目的としてこのような表現を行っている、といった旨の文章を用意するくらいでしょう。いや、こういう文章は必ず用意すべきだと思います。訳の分からないリンクだらけのサイトに迷い込んだユーザーを、少なくとも安全に出口に誘導するという機能は果たしてくれるでしょう。さすがにそれくらいはサイトを作成した人の義務でしょう。
こういう話は何も高度な機能を使ったサイトには限りません。自分の写真や絵を公開するシンプルな画廊サイトだってそうです。そういう場合は文章を読んでいれば（聞いていれば）、「あぁ、ここは画像てんこもりで画像が見えることに意味があるんだな」くらい分かります。（それすら分からないような作り方は論外です。）この場合、どれほど完璧にアクセシビリティに気をつけてサイトを作っても、肝心の伝えたい情報は画像なのです。果たして代替テキストは本当に代替手段足り得るでしょうか。
HTML がどれほど広範な環境で見ることができる仕様だとしても、伝えたいコンテンツによってブラウズ環境は制限されます。ブラウズ環境の制限は読み手の自由を制限することに他なりませんが、読み手を制限してでも伝えたいコンテンツってのは当然あり得ます。そうしたコンテンツを発信する自由も、作り手にはあるわけです。
実際のアクセシビリティは、道路や家屋のバリアフリー化のようにどんどん進めるのが正しい、と簡単に言うことはできません。特にこの文書を読んで役に立てようと考えている人にとってはそうです。
それは、Web サイト作りは道路のように専門家だけのものでなく、なおかつユーザービリティを実現するための知識、ツールが、現時点（2002.01.）ではそれを意識していないものよりはるかに入手しにくいからです。WWW がこれだけ爆発的に豊かになったのは、簡便であったことが最大の要因です。だからこそインタラクティブなメディア足り得たのだと思います。これが小難しいものであったなら（今でもコンピュータに詳しくない人には十分に小難しくなってきてはいるのですが）、理論的仕組みとしてはインタラクティブでも現実には一方通行な、旧来のメディアと変わりのないものとなっていたでしょう。そして今、アクセシビリティはまだ難しい部類に入ります。
Web サイト作成者がユーザビリティ、アクセシビリティに対する意識を持たなくていいということではありませんが、正直言って「自分の納得のいく伝え方を犠牲にすることなくこれを実現するのはかなり難しい」のは間違いないでしょう。スキルがあれば、サーバサイドのプログラミングを施して、ブラウザを判別して適切なコンテンツをユーザーに渡すのが望ましいんでしょう。実際、一つの HTML の中であれこれ代替手段を用意するよりその方がスマートで現実的ですし、より幅広い環境に対応できます。（携帯電話に配慮する場合は HTML のサイズに制限があるので、HTML の内部であれこれ工夫するのは不可能に近いですし。）
本当は、もっと手軽に、多くの人がアクセシビリティに配慮できるようなオーサリング環境がどんどん整っていってくれれば、と思います。まだまだ、これからです。本気出したらアクセシビリティの話だけで十分会社が成り立つんですから。
HTML 2.0 や 3.0（この二つはともに 2001.12. 現在、廃棄されている）の頃には i18n とか、W3C が IETF になってるとか、いろいろありましたが、今はだいたいこの形です。（ISO-HTML なんかの場合は異なりますが、それで書いてる人、います？）
HTML 4.0 Transitional じゃなくて 4.01 です。4.0 は改訂されて 4.01 になったので 4.01 を使うようにしてください。
参考までに、Strict に従うと様々な align 属性、center, font、body に対する色や画像に関する属性などが NG になります。また、ブロック要素とインライン要素の区別が厳格になります。
最初から見た目にこだわらなければ実はそれほど厳しい制限ではないのですが、HTML の裏技装飾テクニックの見た目をスタイルシートだけで再現するのはかなり難しいので、現実的には Transitional を選択することが多くなります。”再現”しようと思わなければいいんですがね。使いこなしのポイントは div による文書のブロック化（モジュール化）とスタイルシートのポジショニング機能。あとはブラウザの対応の問題です。
（以下 2002-05 追記）また、この部分に
(Strict)? とあるのは Strict と書くか、あるいは何も書かないという意味の正規表現です。どっちかの書き方で Strict を指定したことになるということです。本講座では黙ってこういう書き方をしている部分がチョコチョコあるので注意してください。
という記述を長いこと放置していましたが、これは「HTML 4.01 の場合は Strict とは書かない」のが正解です。間違いに気づきながら放置していたら、思わぬところからそれはいかんやろ、と指摘を受けましたので削除しました。いやすいません。偉そうに書くなら正確さに留意すべきでした。
細かい話ですが、この文字コードの情報は、meta 要素の記述をブラウザが解釈するのではなく、「サーバが charset の情報をブラウザに渡す」のが期待されている動作なんだそうです。
サーバが charset の情報をブラウザに渡せるようにする方法は「meta 要素を使って文字コードを指定する」だけではないので、「文字コードの設定のために必ず meta タグを正しく書いてください」と言えないのがつらいところです。しかし、現実にはほとんどブラウザが HTML 文書から読み取っているようですので、正しく指定するに越したことはない、ということになります。（つまりサーバが charset 情報をブラウザに渡すように設計されていない、あるいは設定されていない、ということ。詳しく知りたい方は「Asahiネットだからできるリソースの多次元的表現について」なんかを参照してください。）
考えてみれば WWW では HTML ではないプレーンテキストの文書だって様々な言語で書かれているわけで、その文書には meta タグなんてものは存在しないわけです。だとしたら誰がこの文書の文字コードをブラウザに教えてくれるんでしょう。やっぱサーバですよね。
しかし現状では meta による指定は強く求められる場合が多いのです。やっぱこれは正しく指定しておきましょう。
どっかのソフト製作会社には耳が痛い話ですなぁ。