CyberLibrarian

【注意】 このドキュメントは、W3CのW3C QA - How to achieve Web standards and quality on your Web site?(2002年4月8日作成、2006年3月31日更新版)の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2006年6月28日


私のウェブサイトは標準です! あなたのは?

ステータス

この記事は、W3C品質保証インタレスト・グループ(Quality Assurance Interest Group)の作業の一部として作成されました。これに関する公的なフィードバックは、公開アーカイブ付きのメーリング・リストpublic-evangelist@w3.orgに、私的なフィードバックはkarl@w3.orgに送ってください。レビューやアイデアに時間をさいてくださった方々に謝辞を表します。

この記事は、数か国語に翻訳されています。

はじめに

ここでは、あなたのウェブサイトの品質を改善し、正当なものにするための、簡単で痛みを伴わない技術やアイデアを紹介します。このドキュメントは、HTMLユーザ、ウェブ・アプリケーションの開発に従事している人々、ウェブ・マスターを対象としています。

ウェブ上のほとんどのウェブサイトは正当なものではありません。これはウェブ・ページの99%に当てはまると推測していますが、これを裏付ける統計はありません。これが本当に真実であると証明する調査を実行すると面白いでしょう。

なぜ?

HTMLと標準

一般的な意見

このトピックに関する多くの意見や文句を聞いたことがあります。それらのほとんどは大抵、HTMLの正当性とは何かに関する知識と理解が不足していることに起因しています。以下は、その例の一部です。

  1. スティーヴ(CEO)いわく、ウェブサイトを標準に基いて作れば、ありきたりなものになって、顧客を失ってしまう。

    W3Cの標準に基づきながら、非常に面白いウェブサイトを作ることは可能です。標準を尊重したウェブサイトの作成は、テキストのみによるウェブ・ページの作成と全く関係がありません。

    現在、W3Cは非常にクールな統合技術を提案しています。XHTML(構造化XMLマークアップ)およびCSS(スタイル・シート)、SVG(2Dベクター動画)、SMIL(同期化マルチメディア)を使用した、既存のW3Cの相互運用可能な技術による完全なマルチメディア・ウェブサイトを体験できます。この技術は、ウェブ市場に参加している様々な人々の合意に基いて開発されました。

  2. アラン(技術ディレクター)いわく、ウェブサイトの標準に配慮するための資金がない。費用がかかり過ぎる!

    標準に基いて設計すれば、様々なブラウザに対応した複数のバージョンを用意する必要がないため、ウェブサイトのコーディング・メンテナンスが容易になるでしょう。ページの寿命が長くなり、短期間で消滅するような技術に頼らなくてもよくなるでしょう。したがって、実際には、ウェブの標準に基いて設計すると費用は低くなるでしょう。

  3. ディーン(アート・ディレクター)いわく、標準を尊重すれば、創造性が侵害されるのではないか。

    技術的な制約は、絵画、彫刻、ウェブ・ページのデザインといった、あらゆる芸術的な技法と共存ます。水彩画や油絵自体には制約がありますが、これらの技術が創造性を阻むことはなく、創造的な表現に骨組みを与えてくれます。

    ウェブの標準に基いて作成すると、メディア、技術、読者に特化した技術で新しい世界を開くことになるでしょう。この領域には検討すべき点がまだ多くあります。我々は、標準に基づくマルチメディア体験の利点について探索し始めたばかりです。

  4. クラウディア(グラフィック・デザイナー)いわく、アクセシビリティには関心がありません。私の対象とする読者には障害を持った人はいません。

    アクセシビリティを尊重して設計すれば恩恵を受けられるでしょう。障害を持った人は、総人口の8%から10%に相当します。アクセシビリティのガイドライン(したがって、ウェブ標準)に従ったウェブサイトを維持することは非常に簡単です。ウェブサイトのアクセス数が増加し、より多様なブラウザを用いてサイトのコンテンツにアクセスできるようになるでしょう。

    オーストラリア(障害者撤廃法意見書(Disability Discrimination Act Advisory Notes)バージョン3.1 1999年5月)や、アメリカ(508条 ウェブ・ベースのイントラネットおよびインターネットの情報およびアプリケーション(Web-based Intranet and Internet Information and Applications))のように、いくつかの国々では、法則によってアクセシビリティが義務付けられており、ヨーロッパでも同様の計画(e-アクセシビリティ)に取り組んでいます。

  5. アミナタ(ウェブ・プログラマ)いわく、なぜ標準を尊重しなければならないのですか。ウェブは自由な空間です。

    ウェブは、あなたがニーズを知っているとは限らない多くのユーザが共有する自由な空間です。標準は、すべての潜在的な読者を考慮して設計されています。ウェブ・コミュニティーには、ウェブ標準で作成するという目標があります。特定の会社や所有権に属した技術に縛られることはないでしょう。プラットフォームに依存しない技術を利用できます。

  6. カール(ウェブ開発者)いわく、本の指示に従っただけなのですが。

    残念ながら、本の多くは、良いウェブ・プログラミングについて教えてくれません。ウェブサイトを作成する際には、マークアップの正確さをチェックする必要があります。あなたがウェブ開発者ならば、本を利用してアプリケーションを開発し、実装しようとしている特定の仕様を読むときには注意が必要です。

    W3Cの標準に従った設計を支援してくれる良い素材を集めているウェブサイトもあります。W3Cのウェブサイトには、ベスト・プラクティスを促進している拡大しつつあるチュートリアルのリストがあります。

    W3Cの関係者には、私的利用の範囲で自由に利用できるソフトウェアを開発した人もいます。可能であれば、それらを利用することをお勧めします。これらのパッケージ・ソフトは、W3Cの技術を実装しています。

  7. ティム(経理)いわく、私のウェブ編集ソフトは、正しくないマークアップを作成してしまう。

    多くのオーサリング・ツールは、正しいマークアップを作成しません。構文チェッカーが埋め込まれていたり、正しく動作するものもありますが、多くは正しいマークアップを作成しません。中間的な解決策として、HTML検証ツール(HTML validator)でウェブ・ページをチェックしなければなりません。加えて、ソフトウェア・メーカーに連絡し(メール、電話、文字で)、知らせてあげてください。要求すれば、その会社はきちんと対応してくれるでしょう。

  8. ヴァレリー(ウェブ・コンテンツの開発者)いわく、私のせいではありません。テンプレート用のエンジンがそのように設計されているのです。(ウェブ・ベースのインターフェースを持つシステムに多い )。

    そのとおりです。たいていは、あなたのせいではありません。あなた自身がHTMLを書かなくて良いような単純なフォームを使用しているのであれば、問題が解決されるまでインターフェースの開発者やサイトの管理者に通知してあげてください。作成したコンテンツがW3Cの標準を尊重しているかどうかの確信がない場合は、HTML検証ツールで内容を検証し、ウェブ・マスターやコンテンツ管理システムの担当者に報告してください。

  9. ニン(ソフトウェア開発者)いわく、役に立つ情報がありません。私が見つけた資料は、すべて英語です。

    ドキュメントや仕様書を他の言語に翻訳してくれている人もいます。W3Cは翻訳のリストを維持しています。

HTMLは標準です(XHTMLもそうです!)

HTMLは、その開発過程で進化しており、いくつかのバージョンがあります。これらのバージョンはすべて標準であり、自分のニーズに合ったものを選択できます。ごく一部の限られた読者や古い欠陥のあるブラウザを対象としているのでなければ、大抵は、最新のバージョンを選択するのが最も良いでしょう。選ぶバージョンによって使用できる要素や属性が決まります。

例えば、HTML 4.01にはページ内で使用できる要素のリスト属性のリストが含まれています。ページを手作業で編集する、「手作業によるコーディング」や「ソースの記述」と通常呼ばれる方法をとることができます。

HTML 4.01では、以下のように、この段落にパラグラフやアンカー識別子を記述できます。

<p id="ref">This is a paragraph</p>

要素を入れ子にする方法に注意してください。他の要素内に含むことができない要素や、ある要素にしか属さない属性もあります。

ドキュメントに記述できたり、ソフトウェアに実装できる要素は、HTMLのバージョンに依存します。以下の表には、使用できるHTMLの定義やドキュメント・タイプ(DOCTYPE)のリストが含まれています。

バージョン DTDリスト DOCTYPEドキュメント宣言
HTML 2.0 DTD
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
HTML 3.2 DTD
<!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"
   "http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
   "http://www.w3.org/TR/html4/frameset.dtd">
	
XHTML 1.0 Strict, Transitional, Frameset
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
	
XHTML 1.1 DTD
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
	

これらのDOCTYPEのうちの1つをドキュメントの冒頭で使用しなければ、正しいドキュメントにはなりません。手作業でドキュメントを作成する場合は、忘れないようにしてください。

HTMLオーサリング・ツール
すべてのHTMLオーサリング・ツールは、DOCTYPEを提示し、該当する言語でマークアップされなければなりません(MUST)。
HTMLテンプレート
すべてのHTMLテンプレートには、DOCTYPEがなければなりません(MUST)。
ライブラリまたはテンプレート・エンジン(サーバーサイド)
すべてのHTMLライブラリまたはテンプレート・エンジンは、DOCTYPEを返さねばなりません(MUST)。

以下に、XHTML 1.0 Strictのテンプレートの例を示しています。

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>
	<title>An XHTML 1.0 Strict standard template</title>
	<meta http-equiv="content-type" content="text/html; charset=utf-8" />
	<meta http-equiv="Content-Style-Type" content="text/css" />
</head>

<body>

     ... Your HTML content here ...

</body>
</html>

XHTML Strictのテンプレートは、非常に容易に実現できます。ドキュメントの修正や検証は、簡単で分かりやすいです。

ドキュメントの検証

HTMLの検証

HTML検証ツールは、宣言されているDOCTYPEに対するドキュメントの正しさを簡単にチェックします。

最終ドキュメントの正当性を、ユーザー・エージェント(例えば、ウェブ・ブラウザ)で表示して検証したい場合は、HTML検証ツールを使用できます。HTML検証ツールは、選択したHTMLのDOCTYPEに対するエラーのリストを返してくれます。ドキュメントにエラーがない場合、エラーは発見されませんでした!というメッセージが返されるでしょう。

フォームを利用してウェブサイトを編集する(かつ、そのフォーム内にHTMLタグを記述しない)場合は、サイトのウェブマスターにエラーを報告し、HTML作成プログラムの修正を要求できます。

手作業でウェブサイトを作成したり、直接マークアップのコードを記述したときに、ツールがページのエラーを返す場合は、単にマークアップの修正を行ってください。HTML検証ツールは、エラーが存在する行番号を示してくれます。

HTML検証ツールは、エラーが発生した行番号を示してくれるため、ドキュメントの問題箇所を見つけるのが容易になるでしょう。このツールは、1行目からスタートして、ファイルを一行ずつチェックします。これは、ドキュメントの冒頭のエラーによって、ページの別の場所にもエラーが生じるかもしれないということを意味します。エラーを一掃する良い方法は、最初に表示されたエラーを修正し、ページを再検証することです。ドキュメントの最初の方の問題を解決すると、いくつかのエラーが一度に解決することがよくあります。エラーがすべて修正されるまでこれを続けると、正しいドキュメントができあがります。

HTMLオーサリング・ツールを使用していて、編集後にページが正しく記述されていない場合は、ソフトウェア開発者や会社に報告してください。その会社の技術サポート担当者とコンタクトをとることができるはずです。

あなたがテンプレート・エンジンやオーサリング・ツール、コンテンツ管理システムの開発者である場合は、実装の問題を解決するためにHTML検証ツールを使用してください。ソフトウェアやバックエンド・システムにHTML検証ツールを組み込むこともできます。HTML検証ツールのソース・コードは、自由に利用できます。この検証ツールは日々強化されており、あなたもその開発に参加できます。

: ドキュメントによっては、DTDに関しては正しくても、HTMLの仕様に関しては正しくないことがあります。近い将来、HTML検証ツールで検知不可能な、起こりうるエラーのリストを掲載する予定です。

HTML検証ツールのリスト

リンクの検証

多くのウェブサイトに関する別の大きな問題は、URIの永続性です。他のウェブサイトへのリンクをドキュメントに記述するときには、それらのリンクが安定的かつ永続的であることを期待するでしょう。これは、あなたのウェブサイトの読者がリンクの1つをクリックしたときに、あなたが指し示したいと考えている情報がまだあるということを意味します。あなたは、他のウェブ・ページやあなたのウェブサイトの他の部分にはったリンクに誤りがないことを検証し、担保したいとも考えるでしょう。この目的のためのツールが開発されています: W3Cリンク・チェッカー

Checklinkは、リンクのレポートを生成します。レポートの長さは、ページに含まれるすべてのリンクを読み出して検証するのに要する時間によります。プログラムは、リンクを検証するために、ドキュメントのHEAD HTTPリクエストを処理します。サーバーが誤設定されていれば、サーバーがHEADを提供できないという理由だけで、リンクが正しくても間違ったレポートが提供される可能性があります。この場合、そのウェブサイトのウェブ・マスターに、サーバーの設定を修正するように依頼するべきです。

Checking link http://webstandards.org/
HEAD http://webstandards.org/  fetched in 0.1s

上記はリストの例です。リンクを読み出すために要した時間を示しています。

リンクのリストの後に、リンク切れやリダイレクトされているリンクに関するレポートが示されるので、正しくないリンクを修正するのに役立つでしょう。

リンクの重要性に関するより詳細を知りたいならば、ティム・バーナーズ・リー氏によって書かれたクールなURIは変わらない(Cool URIs don't change)を読むことをお勧めします。

ウェブ・マスターであるあなたが、他の人が自分のウェブ・ページをチェックできるプログラムを、あなたのウェブサイトにインストールしたいと考えたときには、W3Cのリンク・チェッカーのソース・コードを自由に利用できます。

CSSの検証

1996年以来、カスケーディング・スタイル・シート(CSS)は、スタイルと構造を分離する洗練された効果的な方法を提供してきました。昨年(2001年)には、多くのユーザ・エージェント(ブラウザ)が、CSS 1およびCSS 2のサポートを実現しました。スタイル・シートを使用すると、ドキュメントのスタイルに関するすべての情報を一ヶ所で管理できるようになります。

この記事の執筆時点では、ドキュメントにスタイルを記述するためにCSS 1またはCSS 2を選択できます。

スタイル・シートによるデザインは、ウェブサイトのデザイン費用を削減し、相互運用性(様々なユーザ・エージェントによるウェブサイトの可読性)を高めるなど、多くの利点があります。テーブルやJavaScriptを使用してユーザ・エージェントに対応した多くのバージョンのウェブサイトをデザインすると、初期作成費が30%増加します。

FONT要素FACE属性を使用しないでください。国際化の点で有害であると考えられています。どのようにフォント要素を排除し、スタイル・シートを採用するかを学びたければ、Todd Fahrnerによるチュートリアル、FONTタグを超えて:実践HTMLテキスト・スタイリングを読むことをお勧めします。

W3CのHTML検証サービスおよびW3CのCSS検証サービスでは、スタイル・シートの正当性をチェックできます。ドキュメントが読み出す外部スタイル・シートの正当性をチェックすることもできます。ウェブサイトに独自性を導入したい場合は、CSS検証ツールのソース・コードを自由に利用できます。

アクセシビリティの検証

ウェブサイトを作るだけでは十分ではありません。大抵の場合、作者は読者のことを知りません。ウェブサイトにアクセスする人々は、異なるアプリケーション、ブラウザ、および(または)個別の障害を持っています。アクセシブルなウェブ・デザインの実行には、ビジネス上の利点が多くあります。残念なことに、ドキュメントのアクセシビリティの検証はそれほど容易ではありません。ボビー(Bobby)のような一部のツールを利用することも可能ですが、それらはアクセシビリティーに関する懸念への最終的な回答ではありません。人間がコンテンツをチェックする必要があるでしょう。Web Accessibility Initiativeは、アクセシブルなウェブサイトを作成するのに役立つ資源のリストを維持しています。

段階的に品質改良を行うツール

自分達が所有している不正なページの数が多いため、また、どこから始めれば良いのかが分からないため、ウェブサイトを正当なものにすることを思いとどまることがよくあります。極めて簡単です。SMART(Small(小さい)、Meticulous(注意深い)、Accessible(アクセシブル)、Regular(標準的)、Template(テンプレート))であれば良いのです。徐々に取り掛かることにより、痛みや落胆を伴わずに正当なウェブサイトを作成きるでしょう。ですので、テンプレート・エンジンを使用するといった、作業をより簡単にする解決策を徐々に考え、見つけてください。

より良いウェブサイトを作るのに役立つツールのリストを以下に示しています。

HTML Tidy

Tidyは、Dave Raggettが最初に開発しました。ウェブ・ページを正当なものにするのに役立つでしょう。Tidyでは、すべての誤りを修正できないことがあります。Tidyは、編集ツールではなく、問題の解決のみに役立ちます。

最も不正なドキュメント

ウェブサイトのどのページが不正なのかを知るのが非常に難しいことがあります。すべてのページをクロールするスクリプトを走らせると、膨大な不正ページのリストが出力されてしまいます。

では、解決策は何でしょうか?

W3Cでは、Gerald Oskoboinyが、サイトのウェブマスターに負担をかけない、先進的なQ&A形式のウェブサイト用ツールを開発しました。最もアクセスがあった10位までの不正なドキュメントの報告を送り、修正が可能であることを通知してくれます。ウェブマスターには、毎週10件の不正ドキュメントをリストアップした新しい報告が届きます。このツールは一般に公開されており、必要性に応じて改造できます。

W3CのOlivier Théreauxは、このツールのよりポータブルでプラグインとして実装可能なバージョンを開発しました:LogValidator

このツールは、ウェブ・サーバの最終ログをとり、それを検証モジュールで処理します。この検証モジュールは、最も人気のあるドキュメントの特定の技術に対する正当性をチェックしてくれます。デフォルトのモジュールはHTMLの検証ですが、その他のものもあります。

あなたは、自分のウェブ・ページのスペルや、メタデータが記述されているかどうか、リンクがまだ正当かどうかなどを修正したりといったことが可能です。APIドキュメンテーションは、自身のニーズに応じた新しいモジュールの作成に役立つでしょう。

謝辞

この記事をレビューしてくださった次の方々に感謝いたします:Ian JacobsSusan LeschOlivier ThéreauxStephanie TroethJeffrey Zeldman、およびpublic-evangelist mailing-listの方々。

この記事は、レビューおよび支援をしてくださったテクニカル・ライターであるKim Nylanderの参加がなければは作成できなかったでしょう。


Valid XHTML 1.0!

Created Date: 2002-04-08 by Karl Dubost
Last modified $Date: 2006/03/31 04:24:20 $ by $Author: kdubost $

Copyright © 2000-2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.