テキストブラウザにも優しい HTML 文書の作成方法

世間で「画像には alt 属性をつけよう」などと語っている人間の 70% 程度は、日常的にテキストブラウザを使っていません。ここでは、もう少し頭の良い提言をしたいと思ってます。

はじめに

世間的にテキストブラウザはかなり過小評価されていますが(*1)、テキストブラウザの表現力というのは意外と侮れないものです。私などは(CSSの line-height などを使用しておらず) 行間が詰まって文章がずらずらと記述された文章系サイトなどは、行間を広く設定した端末上でテキストブラウザを利用して閲覧することもあります。

HTML 文書というものは、正しい HTML でさえあればテキストブラウザでも快適に閲覧出来ます。しかし、正しい HTML を書こうと思っても人は意外と落し穴に落ちてしまうものです。 Another HTML-lint や HTML Validator といった検証ツールは HTML の文法のチェックは出来ても、それが正しいマークアップかどうかは確認出来ません。検証ツールは文書の内容を理解して、内容に即したマークアップが為されているかをチェックすることが出来ないからです。例えば、以下のような酷いマークアップでも HTML 4.01 strict と言えるのです。

<div class="title"><strong>
HTML 4.01 strict な文書の作成方法
</strong></div>

<blockquote>
<div>
今回は、<span class="bold">HTML 4.01 strict</span>
な文書の作成方法について説明します。
</div>
</blockquote>

本文書は、「テキストブラウザではこのように見えます」ということを例示しながら、初めて HTML 4.01 strict(或いは XHTML)で HTML 文書を作成しようと考えた人が嵌る可能性が高い落し穴について説明することを目的としています。「テキストブラウザにも優しい HTML の記述方法」などというタイトルをつけると、「テキストブラウザでも綺麗に見えるページ作成の裏ワザ」などが書いてあるページだと勘違いする人が出てくると思うのですが、このページにはそんなものは一切ありません。

なお、本頁における「テキストブラウザ」とは、「文字端末上で HTML 文書を表示するための User Agent」のことを指しています。取り上げる User Agent は、ユーザが多く、「伝家の宝刀」(*2)として利用されることが多い lynx(2.8.3) と w3m(0.1.10) です。

HTML 文書を作成する前に

HTML 文書は文書型宣言(DTD; Document Type Declaration)によって「HTML 文書であること」を宣言することによって、初めて HTML 文書となります。拡張子「.html」又は「.htm」のファイルが HTML 文書なのではありません。ましてや、Netscape のアイコンがついているファイルが HTML 文書だというわけではありません。

HTML には様々な規格 / 勧告がありますが、特別な理由がなければ HTML 4.01 strict か XHTML 1.0 (或いはそれ以上のバージョン)として宣言することをお奨めします。「HTML 4.01 Transitional でもいいじゃないか」と仰る方もおられるでしょうが、HTML 4.01 Transitional はそもそも、制定時に「CSS は僅かのブラウザでしかサポートされていない」という事実に基づいて制定されたものです。 CSS をサポートしたブラウザが大勢を占める現在、HTML 4.01 Transitional として HTML 文書を作成することは、文書利用者 / 作成者双方に不利益を与えることになります。

HTML 4.01 strict として HTML 文書を作成するには、HTML 文書の先頭で以下のように宣言します。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/REC-html40/strict.dtd">

テキストブラウザにおける「視覚的表現」

誤解されている方も多いのですが、テキストブラウザでも「視覚的表現」は可能です。端末制御機能を利用して、文字の色を変更したり、高輝度文字を利用したり、太文字を利用したりすることは出来ます。テキストブラウザはこのような端末制御機能を駆使して、なるべく各要素の意味をユーザに伝達しようとします。

端末制御機能を利用するということは、言い換えれば「低機能な端末では視覚的な表現が行えないかもしれない」ということを意味しますし、「表現方法は各端末に依存する」ということにもなります。例えば、私が利用している Cygwin 版の lynx では、字句要素については b、i、句要素については cite、em、strong だけが判別可能であり、しかも表現方法は全て「文字をマゼンダ色にする」というだけです。

しかし「テキストブラウザでは句要素が表現出来ないかもしれないから、句要素を使うのはやめよう」というのは誤りです。テキストブラウザが各句要素を表現出来ないのはテキストブラウザの問題であり、 HTML 文書の問題ではありません。それに HTML 文書の情報の表現方法を「視覚的表現」に限定することは良いことではありません。 HTML 文書の表現方法は様々です。視覚的表現に囚われず、構造と体裁の分離を心掛けながら HTML 文書を作成する必要があります。

もっとも愚かしいのは、 テキストブラウザで表現可能な要素だけを巧みに組み合せて「テキストブラウザにも優しいページにしました」とやってしまうことです。このような、各ブラウザの表現方法のみに頼ったページ作りは誤りであるばかりでなく、有毒でさえあります。

`span` の誘惑に負けないこと

HTML 4.01 strict で HTML 文書を記述するようになると、今まで使っていた font などの体裁用要素が使えなくなるせいか、 <span class="red"> や <span class="italic"> などで逃げてしまう人がいます。しかし、font の代わりに span を使うのでは HTML 4.01 が謳う「構造と体裁の分離」は実現出来ません。

span を利用する前にまず「何故その部分の書式を変更したいのか」を考えるようにして下さい。HTML 4.01 には abbr(略語の表現)、acronym(頭文字の表現)、 cite(インラインの引用表現)、code(コンピュータ・コード)、 dfn(用語定義)、kbd(キーボードからの入力)、 samp(サンプルの表現)、em / strong(強調 / 最強調)、 var(変数)など、沢山の論理的意味を持った句(phrase)要素が準備されています。これらを使うことにより、テキストブラウザでも(可能であれば)要素の意味を利用者に対して表現出来るのです。

なお、現在のところ、w3m / lynx 双方共に span でマークアップされた部分を適切に表現することは出来ないようです。将来的には span を完全にサポートするテキストブラウザが出てくるのかもしれませんが、そのことは「句要素を押しのけてまで span を使う」理由にはなりません。

字句要素に関する注意

HTML 4.0 以降、幾つかの体裁用の要素が「不適切(deprecated)」とされましたが、 tt(テレタイプか等幅テキスト)、i(斜体テキスト)、 b(太文字テキスト)、big(大きい文字テキスト)、 small(小さい文字テキスト)については HTML 4.01 でも引き続き「字句(fontstyle)要素」として定義されています。

一般的に「体裁用の要素は利用されるべきではない」とされていますが、HTML 4.01 で定義されている句要素は文書を作成する上で必ずしも充分なものではありません。文書を作成する上で、世間的な慣習に従うべく「太文字」や「イタリック体」を利用する必要があるということは充分に考えられます(*3)。

例えば、数学のベクトルは太文字で書くことが慣習となっています。ベクトルを示す句要素は定義されていませんので、このような場合は b 以外に利用可能な要素はないでしょう。少なくとも b を利用すれば、「太文字テキスト」であるということがわかるからです。

但し、字句要素の表現方法はブラウザに依存しますので、確実に「太文字」で表現されるという保証はありません。

`link` 要素に情報を設定しよう

一般論

link 要素によって HTML 文書の関連性情報が定義されます。現在のところ、link 要素は有効に利用されているとは言いがたい状況ですが、将来的には様々な用途で有効利用されると考えられます。新しく作成する HTML 文書には必ず付与しましょう。

テキストブラウザでの表現

「rev="made"」は是非埋め込んでほしいものの一つです。 lynx では、= をタイプすることでこの情報が閲覧出来るからです。また、「rel="contents"」や「rel="prev"」などを記述しておくと、lynx では画面最上段にこれらの情報を表示します。ユーザはこれらの情報を利用して文書間を移動することも可能です。

lynx で有効に利用される link 要素の例を挙げておきましょう。

<link rev="made"     href="mailto:ページ作成者のメールアドレス">
<link rel="contents" title="目次の名前"     href="目次の URL">
<link rel="prev"     title="前の文書の名前" href="前の文書の URL">
<link rel="next"     title="次の文書の名前" href="次の文書の URL">

link 要素の title 属性の定義はなくても構いませんが、これらが定義されていると、「prev」や「contents」といった文字列ではなく、 title 属性に定義された文字列が表示されます。そうでなければ「contents」や「prev」としか表示されません。

`img` 要素の `alt` 属性は考えて付与しよう

さすがに最近では個人ページで alt 属性が付与されていないものは減ってきましたが、テキストブラウザで見るとがっかりするような alt 属性も数多く見受けられます。 alt 属性を付与するときのポイントを再度確認してみましょう。

大前提: テキストブラウザでも画像は参照出来る

「テキストブラウザの利用者は画像を見ることが出来ない」と考えている人が多いようですが、テキストブラウザでも外部ビューワを起動することによって画像を参照することは可能です(*4)。

alt 属性は HTML 4.01 では「代替テキスト」という位置付けになっており、画像の説明については longdesc 属性を利用して別リソースへのリンクを指定するのが正しいようですが、現在のところ longdesc 属性は広くサポートされているとは言い難い状況なので、ある程度この原則を崩さざるを得ないかもしれません。

「画像の説明」ではなく「画像の機能」を表現すること

alt 属性は、画像を読み込んでいない利用者に対するアクセシビリティ向上のために定義されているものです。そのことを考えて使わないと、付与されていてもあまり意味はありません。

例えば、ページのタイトルロゴの説明として「ページロゴ」などと書いてあっても仕方がない、ということです。場合によっては「おれさま☆たろうのホームページにようこそ!」などのほうが良いこともあります。

他の文字列との関係に気をつける

先ほどの例の場合、本文中に同じ「おれさま☆たろうのホームページにようこそ!」という文字列が存在するなら、 alt 属性の文字列はかえって鬱陶しく思えるかもしれません。この辺りはページ全体を見渡しながら、適宜考える必要があるでしょう。「画像の代わりに置かれても違和感がないような文字列を指定する」ようにすればよいと思います。

例えば、ボタン画像の横に「戻る」と書いてあるのに、ボタン画像の alt 属性に「戻る」と書いてしまうと、テキストブラウザでは「戻る戻る」と二重になってしまうことになります。

「吹き出し」代わりに使うのは厳禁

Web サイト構築本などを見ると、たまに「裏ワザ」などと称して「alt 属性に文字列を書いておくと、画像の上にマウスポインタを持っていくとその文字列が吹き出し状に表現されます」などと書いてあるものがあります。このような低能な著者が書いた書籍は捨ててしまってよいでしょう。 alt 属性はこのような用途で使われるものではありませんし、そもそもそのような挙動はそのブラウザ独自のものなのです (ちなみに Netscape 6 では、alt 属性の代わりに title 属性に記述した文字列がツールチップとして表示されます)。そもそも HTML 4.01 ではユーザエージェントは、画像をサポートしていないか、ある特定の画像形式をサポートしていないか、または画像を表示しないよう設定されているような場合にのみ、代替テキストを表示するようにしなければならない。と規定されていることを忘れてはいけません。

何でもかんでもつければいいというものではない

例えば、見出しの先頭に小さなボタン型の画像を貼り付けている場合、この画像の alt 属性として画像ファイルのファイル名(例: 「button01.png」)や、「ボタン」などといった文字列が書かれても、テキストブラウザ利用者には何のメリットもありません。例えば、このように見えてしまいます。

ボタン おれさま☆たろうのひとりごと
button01.png リンク集

このような場合、alt 属性に「・」や「o 」と書いておくと、

・おれさま☆たろうのひとりごと

や

 o リンク集

となって、ちょっといい感じになります。また、テキストブラウザで見た場合にそもそも alt 属性の意味がないと感じたら「alt=""」と空文字列にしておくべきです。

もっとも、このように画像を利用して「リスト的なもの」を作成するということ自体、「論理的なマークアップ」だとは言いがたいことは自明です。HTML 4.01 の仕様書にも何にせよ、著者は、ページの整形に画像を用いることを避けるようにすべきである。その代わりにスタイルシートを用いる必要がある。と明記されています。

なお、CSS を利用すれば、例えば ul 要素に対して以下のような定義を指定することにより同等の見栄えが実現出来ます。

ul {
    list-style-image: url("image/button.png")
}

必要があれば `table` はバリバリ使ってよい

一般論

table 要素でレイアウトを行うことは悪です。レイアウトに利用された table 要素は、文書の論理構造を表現しているわけではないからです。読み上げ式のブラウザなどでは障害になることすらあります。

何故かこの事実を極端に拡大解釈して、「table は須らく使用してはいけないものである(∴CSS の位置指定を利用しろ)」と三段跳びに飛躍した理屈を捏ねる人もいますが、情報をどのように表現するのが最も理に適っているかという観点に立てば、表形式の情報などは table 要素を利用する以外に考えられません。 table 要素を利用することによって情報の構造が明確になり、再利用も可能になるのです。

テキストブラウザでの表現

「テキストブラウザでは表はサポートされない」と考えている人も多いようですが、そんなことはありません。正しく書かれた表なら、w3m ではほぼ完璧に、lynx でもある程度は表現出来ます。

手前味噌ですが、例えば週刊「鍵盤世界」第 6 回の表を lynx で見た場合は、

CAPTION: Windows 3.0 時代のショートカットの割当

Undo  alt + backspace
Cut  Shift + Delete
Copy    Ctrl + Ins
Paste   Shift + Ins

w3m で見た場合は

Windows 3.0 時代のショートカットの割当
┌────┬─────────┐
│ Undo   │ Alt + backspace  │
├────┼─────────┤
│ Cut    │ Shift + Delete   │
├────┼─────────┤
│ Copy   │ Ctrl + Ins       │
├────┼─────────┤
│ Paste  │ Shift + Ins      │
└────┴─────────┘

となります。それなりに表として表現されているのがわかるでしょうか?

但し、lynx の表の表現能力は限られたもので、例えば週刊「鍵盤世界」第 13 回のキーボードの図などは表として再現出来ません(w3m であれば、この程度の大きな表でも平気で再現しますが)。

というわけで「lynx で表現できないから table 要素は使うな」などと 低能な主張を繰り返す lynx ユーザも世間にはいますが、正直な所彼らの主張はバッサリ無視して構いません。テキストブラウザに過剰な配慮をして、表を事前に整形してから pre 要素で表現するなど愚の骨頂です。 lynx で表が正しく表現出来ないのは lynx の問題であって、それをガタガタ言うユーザには「別のブラウザを使え」と言ってしまえばいいのです。

ブロックレベル要素の落とし穴

これは私もつい先日までやっていたのですが、「p.attention { text-weight: bold"; }」という定義をした後に、

<p class="attention">
皆様ここにご注目。
</p>

なんてことをしてしまうことがついついあります。当然ながら CSS をサポートしていないブラウザでは通常の p と何ら代わりがなく見えてしまいます。

<p>
<strong>皆様ここにご注目。</strong>
</p>

とすべきでしょう。

パラグラフを div でマークアップしない

一般論

CSS を利用すれば、p も div も同じような見栄えにすることが可能です。そのため、本来ならパラグラフである部分を p でなく div でマークアップする人がいます。

しかし、パラグラフを定義するために p があるのですから、パラグラフは正しく p でマークアップするべきです。 div は複数のブロックレベル要素を論理的に纏める場合、或いはパラグラフではないテキスト(ナビゲートバーなど)に対して利用するものだと個人的には考えています。

テキストブラウザでの表現

テキストブラウザでの一般的な見栄えについてだけ考えれば、多くのテキストブラウザは p 要素の前後に空行を入れて表現しますが、 div 要素の場合はそのようなことを行いません。先にも書いたように、CSS の機能を利用すれば p もdiv も同じように見せることが出来るでしょうが、テキストブラウザでは勿論それに追従することは出来ません。仮に、全段落が p でなく div としてマークアップされていた場合、テキストブラウザでは全部の段落がただ繋がって表現されてしまい、読みづらいことこの上ありません。

勿論、テキストブラウザでの見栄えだけを根拠にしてこのような主張をするのは誤りです。先に書いたように、パラグラフの定義用に p があるのに div を使うのは愚かだというだけの話です。

長い文章は所々に `hr` を入れよう

一般論

hr はそもそも体裁用の要素であり、水平線を表現するならば CSS の border プロパティを利用するのが筋です。

テキストブラウザでの表現

(注意: ここは今までとは異なり、純粋にテキストブラウザでの表現力不足の観点から書いています)

CSS を利用すると、CSS の border 属性を利用することで簡単に綺麗な直線が表現出来ます。しかしテキストブラウザでは CSS を利用した直線を(現在のところ)再現できないので、文書が読みづらくなってしまうことがしばしばあります。そこで、長い文書の場合は要所要所(セクションの区切りなど)に hr を入れてあげることで、テキストブラウザでも読みやすい文書を作成することが出来ます。

但し、ヴィジュアルブラウザで見たときに CSS を利用して作成した直線と、hr が両方とも並ぶと、鬱陶しく見えることが多いのも事実です。そのような場合は、CSS の「display: none」を利用しましょう。 <hr style="display: none"> と指定すると、CSS をサポートしたブラウザでは「そもそも存在しないもの」として扱われますので、この hr は表示されなくなります。

*1: 或いは「一部の狂信的なマニアが利用するもの」「HTML 文書に対してケチを付けるために使われるもの」「一部の W3C 信者が他人の HTML 文書を罵倒する為に利用する錦の御旗」などと、歪んだ評価をされていますが。

*2: 個人的には「lynx ユーザのことを考えろ!」という主張は「あまりアタマの程度が高くない主張」だと思っています。 lynx や w3m で見たときに救われればいい、という話では無い筈だからです。

*3: その前によく考えて下さい。表現したいものは、本当に b や i を使わなくては表現出来ないものですか?

*4: 実のところ、テキストブラウザを利用している人間に対して「外部ビューワを起動してまで見たいと思わせる」画像ファイルを用意するのは、結構骨かもしれませんが。