The Web Design Group presents:

World Wide WebのHTML制作基準

はじめに

目的

　これらの基準の目的は、ウェブ制作に於いて標準と良い実践の遵守を推進し、基準から外れる制作者が彼等の行動の結果に気付いてもらうことです。実践において、世界的に広がるウェブ（WWW）を発展させたシステムは、クライアント・ソフト装備に関わりなく、全てのユーザーにアクセス可能なものです。ウェブ制作標準はW3Cから発行されているHTMLマーク付け標準と相補的なものであるべきです。

規約

　これらの基準は、以下のような例外を除き、一般的な出版にアクセス可能であるように作成される全てのウェブ・ページに適用されるでしょう：

  1. 単にリクリエーションで、何ら情報内容を持たないウェブ・ページには当てはまりません。
  2. 関係者だけの内部的なシステムには適用する必要はありませんし、意図しているユーザーが或る組織や特別な外部の関係者（イントラネット）に限定されているシステムにも適用する必要はありません。

対象者（Intended Audience）

　組織のために仕事をしているプロフェッショナルなウェブ・デベロッパーで、職業はウェブそのものではない人（例えば、雇用者やクライアントよりもより詳しくしっていると正当に思われていり状況で仕事をしている）。

　読み手が、既にHTMLの一般的な作業知識と適当な訓練や経験を通して獲得しているとおもわれる、ものを持っている。

定義・頭文字・省略語

　PSS-05に沿って、以下の標準的実践が定義されています：

義務実践（Mandatory Practices）
SHALL（することになっている）という言葉のあるセンテンスは、義務的な実践で全てのウェブページで例外なく従わなければなりません。
推奨実践（Recommended Practices）
SHOULD（すべき）という言葉のあるセンテンスは、強く推奨する実践です。従わない場合、その正当化の理由が必要です。
ガイドライン的実践
MAY（しましょう）という言葉があるセンテンスは、ガイドラインです。従わなくても、その正当化の理由は必要ありません。（訳注：MAYは軽い強制）

　以下の頭文字は、読み手に馴染みがあるでしょうが、完全にするためここにリストされています：

CGI
The Common Gateway Interface
CSS
Cascading Style Sheets
HTML
HyperText Markup Language
HTTP
HyperText Transfer Protocol
SGML
Standard General Markup Language
W3C
The World-Wide Web Consortium
WWW
The World-Wide Web

参照

  1. ESA PSS-05 Software Engineering Standards Issue 2, February 1991.
  2. HyperText Markup Language Specifications
  3. WebTechs HTML Validation Service

概観

この文書は、以下の見出しの簡潔なリスト形式で、必要事項を表わしています：

  1. 検証
  2. HTMLヘッダー
  3. 色と背景画像
  4. 画像
  5. 適切な使用と旧式になるタグ
  6. 非標準／特徴的なマーク付け
  7. ブラウザ互換性
  8. 国際的なページ
  9. スタイル・シート
  10. フレーム・ページ
  11. クライアント側スクリプト
  12. ダイナミック・ページ

ウェブ制作基準

検証

  1. 全てのHTML文書は、HTML検証によってチェックすことになっている［義務：SHALL］。
  2. 文書はHTMLレベルの2.0・3.2(Wilbur)乃至は入手できる場合はW3Cからの将来の仕様書で検証すべきです［推奨：SHOULD］。
  3. 上記以外のDTDを使う制作者は、適切なDOCTYPE宣言を記載することになっている［義務：SHALL］。標準でないものや広く知られていない（例えば、WebTechs検証サービスから入手できる）DTDの場合、DTDそのものが文書内のコメントで参照されることになっています［義務：SHALL］。
  4. HTML文書は検証に合格すべきです［推奨：SHOULD］。
  5. 制作者は検証エラーを書き留めるべきです［推奨：SHOULD］。このようなノートが別にHTML文書（ソース内のコメントによって参照される）に送られるようにしましょう［軽いガイドライン的強制：MAY］、そして妥当でない構造とテキスト・ブラウザなどを含む幾つかのブラウザ上での影響を並記し説明すべきです［推奨：SHOULD］。妥当ではないが確固とした構造の場合は、確立した分析参照で十分です。

HTMLヘッダー

  1. 全ての文書は適切なタイトルをきさいすることになっています［義務：SHALL］。
  2. 文書に、リンクの関連・スタイルシート・クライアント側スクリプトそしてメタ要素など、ヘッダー要素を書くようにしましょう［軽いガイドライン的強制：MAY］。
  3. フロント・ページ乃至はシステムにとって原理的に入り口ポイントである文書は、次のものを含むべきです［推奨：SHOULD］： その他の文書はこのようなヘッダーを含みましょう［軽いガイドライン的強制：MAY］。

色と背景画像

  1. 制作者は文書の色を決定するのに正しいマーク付けをして［軽いガイドライン的強制：MAY］、そのためにはRGB仕様を使うべきです［推奨：SHOULD］。
  2. 色の設定をする所はテキストと背景が強いコントラストになることを確認することになっています［義務：SHALL］。これは暗い中の明るさ・明るい中の暗さを意味します：色調コントラストでは、モノクロ画面や色盲の読み手にとって不十分です。テキスト色を設定する制作者は対応する背景を、そしてその逆も、設定しなけれべなりません。
  3. 背景画像は（何処でつかわれても）小さくすべきで［推奨：SHOULD］、特定されたBGCOLORと同じ色にすべきです［推奨：SHOULD］。
  4. 目を引き付ける背景画像はテキスト情報のあるページでは避けるべきです［推奨：SHOULD］。

画像

  1. 画像はテキストを補うために使うもので［軽いガイドライン的強制：MAY］、それに置き代わられるべきではありません［推奨：SHOULD］。適切な使用例としては、ヂアグラム・グラフ・地図（当然、テキストを補います）；不適切な例としては、テキストに置き代える為に遣われた一行の飾られたテキストやイメージ・マップです。
  2. 全てのはALTテキストを持つことになってなっています［義務：SHALL］。適切な場所なら、ALT=" "も受け入れられます。
  3. リンクである画像のALTテキストは、 リンクの目的を説明することになって［義務：SHALL］、簡潔であるべきです［推奨：SHOULD］。 「ホーム」・「次へ」・「前へ」・「検索」などはいいALTテキストの例で、 「ここをクリック」・「ホーム・アイコン」・「Binocular Icon」・ 「XYZホームページに戻る」などは救い難いほどに悪い例です。
  4. ALTテキストは文書のテキストの写しであるべきではありません［推奨：SHOULD］。
  5. 大きな画像（10Kbを超すもの）のALTテキストはこのサイズについて警告をしておくべきです［推奨：SHOULD）］−例えば、"Global Composite Image (29K)"（ALTテキストが邪魔をするケースではこれを省略するのが適切でしょう［軽いガイドライン的強制：MAY］。
  6. ALTテキストは読み手を別のテキスト・ツールバーに導きましょう［軽いガイドライン的強制：MAY］、その必要がないならブランク(ALT=" ")にすべきです［推奨：SHOULD］。
  7. イメージマップが使われている所には、誘導の代替え方法を読み手が入手できるようにすべきです［推奨：SHOULD］。
  8. 画像は高さと幅属性を使うべきで［推奨：SHOULD］、以下のBrowser Compatibilityで注意されていることは除外しますが。

適切な使用と旧式になるタグ

  1. <BLINK> は使うべきではありません［推奨：SHOULD］。
  2. <FONT> はHTML見出し<H1> - <H6>に代わって使われるものではありません［義務：SHALL］。
  3. 強調タグ、<FONT>, <B> or <STRONG>、は長い行には適用すべきではありません［推奨：SHOULD］。これらは言葉や語句そして（例外的に）テキストの全パラグラフに適しています。
  4. <H1>...</H1>は、HTMLページに一回だけ使うべきです［推奨：SHOULD］。

非標準／特徴的ななマーク付け

　一般的な基準：特殊なケースは以下のように分けて取り扱われます。

  1. 制作者が非標準乃至は特徴的なタグをHTML文書で使ってもいいのですが［軽いガイドライン的強制：MAY］、上記の検証基準に従いましょう。
  2. かくて、HTMLページが生成されたとしても、特徴的なマーク付けに依存すべきではありません［推奨：SHOULD］。特に全ての鍵になる機能性や情報は、拡張をサポートしていないHTML互換ブラウザでも入手できるようにすべきです［推奨：SHOULD］。
  3. 定義されていない実体は使用すべきではありません［推奨：SHOULD］。

ブラウザ互換性

　普通のブラウザにある既知の欠陥による判読困難なHTML構造は、厳密なHTMLで構造的に妥当であったとしても、避けるべきです［推奨：SHOULD］。このこのセクションでのガイドラインが助言になります。

　ブラウザで欠けていると並べたてるのはこの文書の目的ではありませんが、制作者の関心は稀なケースでもここに引き付けられます。多くの人に向け書こうとしている制作者は、ポピュラーなネットスケープ・ブラウザで正しくないとなる、この構造リスクに気付いておかなければなりません。

  1. タグ内に<や>を使うことは、 <IMG SRC="forward.gif" ALT="=>">と対照的に、解析を壊す危険があり、避けるべきです［推奨：SHOULD］。
  2. コメントは<!--で開かれ、 -->で閉じられます。同じ区切り子内に "--"や ">"を使うことは避けられるべきです［推奨：SHOULD］。
  3. 画像の高さと幅属性は、画像自身かALTテキストが文書に必要なケースに限定すべきです［推奨：SHOULD］。特に誘導アイコンである画像は、別のテキスト誘導も同じページに提供されていないなら、画像の高さと幅属性を使用すべきではありません［推奨：SHOULD］
  4. 文書の色をボディ・タグで特定する時は、数値RGB記法が必ず使われるべきです［推奨：SHOULD］。
  5. 画像やテーブル迂回の使用は、 "br clear"が可能なら続く画像やテーブルの前で使われるべきです［推奨：SHOULD］。
  6. HTMLテーブルの使用の際、文書がそれをサポートしていないブラウザでも妥当にであるかの確認準備がなされるべきです［推奨：SHOULD］。
  7. HTML内容は（パラグラフやテーブルの様に）はっきりと閉じるべきです［推奨：SHOULD］。

　よく見かけおうおうにして深刻な制作エラーは、ユーザーの文書の判読し易さを妨げるやり方で影響を与えようとします。

  1. ページは、読み可能性を特殊なブラウザ画面・文字サイズそして色に依存すべきではありません［推奨：SHOULD］。本当はページはそれが何であれ、どのような描写にも依存しないもので、情報内容が性質上本来視覚的であるものは別ですが。
  2. 制作者はユーザーの設定を想定（明示的かそうでなくても）した構造を用いるべきです［推奨：SHOULD］。避けるべき例として、ピクセルでサイズを表示された全画面スクリーンのテーブルや仕切られた画像です。 <TABLE WIDTH="95%">は受け入れられますが、 <TABLE WIDTH="500">はそうではありません。

　勿論、このガイドラインは、制作者が意図する描写上利点がある状況の読み手のために、文書のビジュアルな作成を排除するものではありません。

国際的なページ

  1. 一つ以上の言語で入手できる文書が、関わりのある言語で平行階層として表現されるべきです［推奨：SHOULD］。
  2. HTTP content交渉（HTTP content-negotiation）が読み手に見せる初期言語を決めるのに使われるべきです［推奨：SHOULD］。
  3. 多言語階層の各文書は、入手できる別の言語へのリンクを含むべきです［推奨：SHOULD］。

スタイル・シート（様式規則集）

  1. 制作者はウェブページを作成するのにスタイル・シートを使うようにし［軽いガイドライン的強制：MAY］、文書の体裁見栄えを決めようとする場合はそうするように薦めます。
  2. スタイル・シートは、それをサポートしていないブラウザに見せるべきではありません［推奨：SHOULD］。これは、テストしなければなりません［推奨：SHOULD］。
  3. スタイル・シートは、サポートしていないブラウザのアクセス性を妨げるやり方で使用すべきではありません［推奨：SHOULD］。

フレーム・ページ

  1. フレームは、検証要求に従って使いましょう［軽いガイドライン的強制：MAY］。これは標準HTMLとして検証されないので、報告が必ず必要です。
  2. framesetを経て提供される情報は、NOFRAMES部分を経て非フレーム情報にもアクセスできるようにすべきです［推奨：SHOUL］）。
  3. NOFRAMES部分は、完全な代替えを読者に提供すべきです［推奨：SHOULD］。別のバージョンへのリンクを使うのは、容量が大きい場合に限られるべきです［推奨：SHOULD］。
  4. 一つのサイトに一つ以上のフレームを下にしたレイアウトの使用は避けるべきです［推奨：SHOULD］。

クライアント側スクリプト

  1. ジャバスクリプトなどのクライアント側言語は、サポートしていない乃至はこの機能が可能なブラウザにページのアクセス性を損じないようにして、使いましょう［軽いガイドライン的強制：MAY］。
  2. スクリプト・ページは、スクリプト言語をサポートしていないブラウザでも（単にこの機能を切っているブラウザではなく）、満足のいく表現になっていることを確認することになっている［義務：SHALL］。
  3. スクリプト・ページはHTML検証の要求に従うべきです［推奨：SHOULD］。

ダイナミック・ページ

　CGI・SSIその他のサーバー=インターフェースで生成されるダイナミック・ページの場合、生成される可能な全てのページを検証することは現実的ではありません。しかし、出力は一般に一つの用意された形式乃至は幾つか用意された形式の一つを取ります。

  1. ダイナミック・ページはプログラムのサンプル出力によって代表されるべきです［推奨：SHOULD］。これらサンプル・ページは変化しない文書用に記載された標準に従うべきです［推奨：SHOULD］。プログラムからの主な各経路はこの様なサンプル出力ページによって代表され、ソフト・ウェアー自体と同じ注意をもってテストされるべきです［推奨：SHOULD］。
  2. ユーザー登録を含むダイナミック・ページは、制作者の制御を超えているかもしれません。けれでも、制作者は破壊的な入力を予想し探しておくべきです［推奨：SHOULD］；例えば、何らかのHTMLマーク付けが暴かれることがあります。
  3. 制作者は全てのケースで、ユーザー登録がシステム案全性やまたシステム上の他の情報へのアクセスを保証して使われることはできないことを確認しておくべきです［推奨：SHOUL］。

　ダイナミック・ページと協力するソフトウェアーの発展に合った標準は、既存のPSS05や同等の適切である標準から得られると思われ、これはこの文書の範囲外のことになります。

Home, Questions, Members, WDG Award, Reference, Design, Links

Copyright C 1997. Web Design Group All rights reserved.

日本語翻訳版覚書

この文書の原著は、Web Design Groupの
[Web Authoring Standards Document]
"http://www.htmlhelp.com/design/standards.html"　で、
翻訳許可を受けています。翻訳版は、翻訳からくる間違いがあり得ます。

Yasutaka Kato　加藤泰孝
<email:y.kato@personal.email.ne.jp>
<email:ykato-ind@umin.ac.jp>

［ホームページ］