ホームページ制作ガイドライン

弊社のWEB制作ガイドラインを開示しております。
デザインやサイトマップなどを考える前に、まずこちらを一読ください。

WEB制作ガイドライン
ver.0.03 - 2009年2月9日作成
株式会社ワンダーネスト

1. はじめに

  1. 1.1. 目的
    このガイドラインは、制作/管理/クライアント間での相互認識の差異をなくし、業務の効率化をはかり、一定品質の作業が行えるようサービス・製品の品質を一定に保つことを目的としています。 定期的に内容を見直し、より一層の業務効率、サービス・製品の品質向上をめざします。
    ※全てはプロジェクトのサイト仕様(要件、目的など)に応じて柔軟に対応させ、必ずしも守るべき規則ではないことを前提とします。
  2. 1.2. メリット
    1. 1.2.1. メンテナンス性の向上
      • ・プロジェクト毎に命名規則などを考える無駄な時間を省くことができます。
      • ・複数の人で共同開発・運営しても、XHTMLCSSの品質を一定水準に保つことができます。
      • ・デフォルトのスタイルシートが整備されていれば、デザイナーがいなくてもデザイン品質を一定以上に保てる部分があります。
  3. 1.3. Web サイトの国際的な標準への準拠 本ガイドラインは、W3C勧告等の国際的な標準に準拠することを基本方針とします。国際的な標準の例として、WCAG (Web Content Accessibility Guideline) 1.0 があります。
    WCAG 1.0日本語訳: http://www.zspc.com/documents/wcag10/

2. 制作運用ガイドライン

  1. 2.1. ユーザー環境
    1. 2.1.1. 対象ブラウザ
      現在の国内ブラウザシェアを考慮して、WindowsはMicrosoft InternetExplorer6.0(以下、IE6)以上、Safari・Firefoxの最新バージョン、MacintoshはSafari・Firefox最新バージョンを対象とします。
      但し、ブラウザシェアはWEBサイト固有の要因が関係しますので、ターゲットユーザの国・年齢層、頻繁にアクセスするユーザが使っているブラウザなどをプロジェクト毎に考慮する必要があります。また、各プラットフォームとも古いブラウザを使用しているユーザへの配慮を心掛けるようにしてください。
    2. 2.1.2. 画面サイズ
      画面解像度のシェアを考慮すると、対象とするモニタ解像度は最大でXGA(1024x768px)とします。ですが、これより低いモニタ解像度を考慮し、一般的なサイトのコンテンツを収められる横幅を考えてもVGA(800x600px)でブラウザの枠、スクロールバーが表示される場合を想定し、コンテンツを表示する領域の横幅は760px前後とするのが望ましいでしょう。
      但し、ブラウザの表示サイズに合わせて領域を可変するようにデザインする場合はこの限りではありません。
  2. 2.2. サイト構造とディレクトリ/ファイル
    1. 2.2.1. フレーム
      framesetまたiframeによるフレームレイアウトは、SEO・アクセシビリティ上、デメリットがあるので、ターゲットユーザを相当絞り込める(SEO・アクセシビリティが求められない)場合を除いて原則として使用しないようにしましょう。
    2. 2.2.2. ディレクトリ/ファイル名
      ディレクトリ名およびファイル名は、先頭が1バイト(半角)文字のアルファベットで以下、英数字およびハイフン「 - 」アンダーバー「 _ 」ピリオド「 . 」で表記します。なお、英字は特殊なケースを除き必ず小文字を使用して下さい。
    3. 2.2.3. ローマ字英語表記
      ローマ字英語表記は、原則として禁止します。使わざる得ない場合は常識の範囲内で判断してください。例)gyouji → event
    4. 2.2.4. 命名規則
      わかりやすく、規則的な名称をつけます。
      ユーザビリティ・作業効率・SEOの面から、URIを見ただけでサイトの構成や自分のいる位置が想像しやすいこと、後々のメンテナンスのしやすさ、内容に即した意味のあるキーワードをファイル・ディレクトリ名に含めることで検索エンジンのヒット率向上が期待できます。
      例)/news/2008/10/index.html >2008年10月のニュースのインデックスにいることが想像できる
      一般的なコーポレートサイトのディレクトリ名の一例
      商品案内: products
      事業案内: services
      会社概要: outline, profile
      沿革: history
      事業所案内(会社の位置): access, location
      採用情報: recruit, career(キャリア採用の場合)
      よくある質問: faq
      利用規定: sitepolicy
      免責事項: disclaimer
      個人情報保護について: praivacypolicy, privacy
      お問い合わせ: contact, inquiry
      サイトマップ: sitemap
  3. 2.3. データ容量
    ひとつのページを構成するXHTMLファイルの容量は、ユーザ環境への配慮とSEO対策を考慮した150KB以下とします。
    サーチエンジンのクローラは150kb以上あるXHTMLを正常にクロールしない可能性があるため、これ以上増える場合はページ分割することを検討してください。
  4. 2.4. 画像ファイル形式
    使用可能な画像ファイルのフォーマット形式は原則としてGIFとJPEGとします。
    その他透過PNGについては未対応ブラウザへの対処などプロジェクト毎に十分に検討しましょう。
  5. 2.5. 文字コード
    UTF-8、Shift_JIS、EUC-JPのいずれかを対象のプロジェクト要件のサーバ環境、利用する技術に応じてプロジェクト毎に統一した文字コードを選定してください。
  6. 2.6. .htaccess/robots.txt/エラーページ
    1. 2.6.1. .htaccess
      .htaccessの設置については、サーバにより設置の可否など扱いが異なりますので、プロジェクト毎に検討、サーバ管理者に問い合わせるなどして必要に応じて実施するようにしてください。
    2. 2.6.2. robots.txt
      robots.txt(サーチエンジンによるクローラのアクセス制御)の設置は、プロジェクト毎に検討し必要に応じて実施してください。
  7. 2.7. エラーページ
    Webページへのアクセスに失敗した場合に表示されるエラーページは、ブラウザ・サーバによって異なり、閲覧者にとって分かりやすい内容とはいえません。独自のエラーページを作成してユーザを適切なコンテンツへ誘導しましょう。
  8. 2.8. FLASHコンテンツ
    想定されるユーザのマシン環境にインストールされているFLASHプラグインのバージョンは、ver.8以上とします。
    ※FLASH PLAYER普及率バージョン8=13.36%, バージョン9=77.99%。(Jストリーム社調べ2007.10月調べ) バージョン8以上で9割以上がプラグインのアップグレードをしなくても閲覧可能
    但し、.swfファイルを配置する際は、プラグインの無い環境のユーザ(バージョン7以前)への配慮を徹底して下さい。FLASHコンテンツを閲覧しない限り情報が得られない場合は、代替画像を用意した上でプラグインのダウンロード先を明記して下さい。
  9. 2.9. 個人情報保護
    個人情報を取得する入力フォーム(クレジットカード情報、採用情報、イベント・セミナーの登録、アンケート、ご意見・ご相談、お問い合わせ等)およびCGI等のWeb アプリケーション(ログインID/パスワード)は、SSL(Secure Socket Layer)対応したサーバ上に公開してください。また、その際個人情報を取得する際には、利用目的などの一定の事項を開示した上でユーザに同意をいただいてから取得するようにしてください。
    また、クライアント側で個人情報を管理する体制を維持できない場合には、個人情報の収集ならびに取り扱いは一切提案しないでください。
    例:入力フォームのページにおいて、利用目的などを記載してそれに同意する旨のチェックボックスをチェックいただいた場合に限りフォームを送信するような、チェックボックスを設置する。

3. XHTMLガイドライン

  1. 3.1. 基本ルールと書式
    1. 3.1.1. 基本ルール一貫性のあるマークアップポリシー
      提供する文書の内容が、様々な閲覧環境でも理解できる内容とし、記述ルールを一貫させるよう努めます。 セマンティックウェブを視野に入れた構造
      セマンティックウェブとは(引用元:IT用語辞典 e-Words) 「Webページおよびその中に記述された内容について、それが何を意味するかを表す情報(メタデータ)を一定の規則に従って付加することで、コンピュータが効率よく情報を収集・解釈できるようにする構想。インターネットを単なるデータの集合から知識のデータベースに進化させようという試みである。」
      見出し・ツリー構造を明示化(各見出しのおよぶ内容の範囲)し、人間だけではなく、コンピュータにも「情報の意味」を理解させることで、利用する私達人間がWEB上の資源を最大限有効に活用できるようになります。
      解説)
      <div class="section">
      <h1>見出しレベル1</h1>
      <p>段落内テキスト</p>
      </div>
    2. 3.1.2. 書式
      XHTMLの書式は、各ブロックの開始タグ・終了タグで改行し、子要素ブロックのインデントを行わないようにします。(ソースコードが横に長くなり読みにくくなるため) 例)
      <div id="header">
      <h1>タイトル</h1>
      </div>
  2. 3.2. 各部位の定義ルール
    基本はdiv要素+idで、必ずしもdiv要素ではなく意味的な要素 (p、ulなど) に直接idづけするのが理想ですが、現場の混乱が予想される場合は予め「必ずdiv要素+idでラップする」と決めておくようにします。 id名については社内で統一したものを使用します。 以下に示すid名の一例を示します。(命名の仕方については4.2セレクタのルールを参照) 全体を囲う部位のid名 container, wrapper, pagetop ページ上部のid名 header, headerArea ナビゲーション部のid名 nav, navigation, globalNav パンくずリスト・トピックパス部のid名 topicPath, breadcrumbs メニュー部のid名 menu, submenu, localMenu 本文・メイン部のid名 content, main, sub, section, contentBlock, entry, item, lead ページ下部のid名 footer, footerArea, copyright
  3. 3.3. head要素内のルール
    1. 3.3.1. DOCTYPE宣言(文書型定義)
      ユーザ環境ガイドラインに沿って、また、提供する情報内容によりマークアップ上必要な要素を含む文書型定義を選択します。文書型定義の選択肢は、制作の時点で W3C より勧告されている仕様から選択します。
      HTML 4.01 Strict / Transitional DTD
      XHTML1.0 Strict / Transitional DTD
      XHTML1.1 DTD
    2. 3.3.2. HTML 4.01 Strict / Transitional DTDについて
      既存コンテンツ・技術資産などを流用したいサイトなどには有効ですが、特にHTML4.01を選択する理由がない場合はXHTML1.0を利用するのが一般的です。
    3. 3.3.3. XHTML1.0 Strict / Transitional DTDについて
      他のXML関連技術を利用した連携・拡張が可能なため、将来的な相互運用性の確保も視野にいれている場合や技術的な制約が特になく、新規立ち上げや全面リニューアルするサイトなどに向いています。
    4. 3.3.4. XHTML1.1 DTDについて
      XHTML1.1については、1.0に代えて採用するメリットはほとんどなく、IE6がダウンロードダイアログを表示してしまうといった不具合が発生する場合があるので採用しないのが一般的です。
    5. StrictとTransitionalの採用の判断
      StrictとTransitionalの違いは、Transitionalで利用できる要素・属性がStrictで認められていないことです。ですので、Strictで認められていない要素・属性を少しでも使うのであればTransitionalを採用することになります。
      たとば、target属性、iframe要素、font要素などがStrictでは認められていません。
      ただ、Strictで認められていない要素・属性を乱用してしまうと、ページをすっきりと構造化できなかったり、ソースコードが冗長になったり、CSSを適応しにくくなるデメリットが発生してしまいます。Transitionalを採用する場合でも、「なるべくStrictなマークアップを心がけ、Transitionalな要素・属性は限定的に利用するにとどめる」意識が大切です。
    6. 3.3.5. Framesetの選択について
      フレームレイアウトはSEOやアクセシビリティ上、デメリットがあるので、ターゲットユーザを相当絞り込めるSEOやアクセシビリティが求められないCMS管理
    7. 3.3.6. XML宣言
      XML宣言は、XHTMLXML(eXtensible Markup Language)の一種であることを示すための指定です。(XHTMLだけではなく、RSSやAtomなどの言語の上位に位置するメタ言語です) 但し、XML宣言を記述すると、IE6がレンダリングモード(描画モード)として「後方互換モード」を採用してしまうため、事務的には記述しないのが一般的でしたが、IE6のシェアが低下している現在では先方互換性も視野に入れ記述するのが望ましいです。
    8. 3.3.7. CSS/JavaScriptについて
      CSS/JavaScriptの記述については、style要素やstyle属性などでXHTML内に直接記述せず、原則としてそれぞれ外部ファイル化しlink要素やscript要素で外部ファイルとして指定しましょう。

4. CSSガイドライン

現在広く利用・ブラウザサポートされているCSS(Cascading Style Sheets、カスケーディングスタイルシート)のバージョン「CSS2.1」を採用します。

※「CSS2.1」は、CSS2で定義された仕様のうち一般的なブラウザで実装されなかった部分や、既にブラウザに実装されている機能を踏まえて解釈を調整した、「CSS2」のマイナーバージョンアップ版です。

  1. 4.1. 基本ルールと書式
    1. 4.1.1. 基本ルール
      原則としてXHTML内にインラインで記述せず、全て外部CSSを適用させることを基本とします。CSSファイルの1行目には、@charset で文字コードを指定しましょう。XHTMLの文字コードとは関係ありませんが、特に理由がなければ同じ文字コードを指定しておきます。 なお、@charsetより前に、セレクタやプロパティ、コメントを書くことはできません。 例)
      <link href="/common/css/master.css" rel="stylesheet" type="text/css" media="screen, projection, print" />
      <link href="/common/css/print.css" rel="stylesheet" type="text/css" media="print" />
    2. 4.1.2. 書式
      インデントを行う場合はタブ1つ、または半角スペース2つで行いましょう。
      CSSファイルの先頭には、制作者情報(用途や作者・バージョン)を記載し、更新/管理します。 セレクタを分類した大きなまとまりがある場合もコメントを記載します。
      例)セレクタを分類した場合など
      /* ==== 分類 ==== */
      その他、注釈をする場合
      例)注釈をする場合
      /* ---- 注釈 ---- */
  2. 4.2. セレクタのルール
    セレクタに class および id の指定がある場合は、文書中のどの要素に係る class / id なのかを極力明示します。(CSS だけではどの要素につけられているのかが理解できず、都度 HTML を確認しなければならなくなるため)
    ただし、どの要素にも適用させたい汎用 class の場合はこの限りではありません。
    例)
    /* id が content の div 要素の例 */
    div#content {
      width: 760px;
    }
    /* class が section の div 要素の例 */
    div.section {
      margin: 0 0 1.2em 0;
    }
    /* class が error で、要素に関係なく適用したい場合の例 */
    .error {
      color: #f00;
    }
  3. 4.3. プロパティのルール
    1. 4.3.1. インデントと改行
      セレクタ+半角スペース1つ+{+改行
      プロパティの記述は、そのセレクタに対して半角スペース4つ分のインデント
      プロパティ直後のコロン':'の隣に半角スペース1つ
      値が複数ある場合は半角スペース1つ区切り
      値の終了にセミコロン';' + 改行
      閉じ括弧'}'(インデントなし)
      セレクタ{プロパティ: 値;}のひとまとまりを記述したら1行空ける
    2. 4.3.2. プロパティの記述順序
      厳密に規定しませんが、制作後のメンテナンス性を考慮すると一定のルールを持った順序で記述するのが望ましいです。例としてMozilla.orgの外部CSSの順序アウトラインを示します。
      例)
      selector {
        視覚整形モデル
        ボックスモデル
        背景と前景
        フォントとテキスト
        生成内容
      }
      Mozilla.orgの外部CSS: http://www.mozilla.org/css/base/content.css
  4. 4.4. CSSハックのルール
    ブラウザ個別にCSSを適用させるためのCSSハックは、文法的に間違ったものも含まれるため極力使用しないのが理想です。
    デザインの実現するためにやむを得ず利用する場合は、コメントを記述するか、別途ハックをまとめたCSSファイルを用意し、将来ハックが不要となった場合に容易にCSSを取り除けるようにします。
  5. 4.5. マルチデバイス対応
    想定されるすべての環境に適合するスタイルシートを提供するのが理想ですが、あらかじめユーザ環境ガイドラインで定めたターゲットのメディアに対応します。
    パソコンのディスプレイ向け(media="screen")
    普及している解像度を考慮して作成します。アクセシビリティに配慮するならばフォントサイズの固定は望ましくありません。 プリンタ向け(media="print")
    グレースケール印刷を前提にスタイルを決め、印刷に不要な要素(例えばフォームコントロール部品など)は隠すなど考慮して作成します。 携帯端末向け(media="handheld")
    専用ページを用意するなど、各種携帯キャリアのサポート状況に応じて柔軟に対応します。

5. 用語・表記ガイドライン

  1. 5.1. 漢字と仮名のルール(送り仮名の付け方)
    送り仮名は、現在広く行われている基準(昭和48年内閣告示第2号)に則して行います。
    送り仮名の原則
    • * 用言 - 用言を漢字を用いて書くには、ふつう、送りがなが必要になる。活用語尾を送りがなにするのが原則であるが、形容詞 ・形容動詞については次のルールが適用される。
      • o 形容詞 - 終止形が「しい」で終わる場合には送りがなが「し」で始まる。 例 楽しい
      • o 形容動詞 - 語幹が「か」「やか」「らか」で終わる場合には送りがながそれぞれ「か」「やか」「らか」で始まる。 例 静かだ 華やかだ 清らかだ
    • * 副詞・連体詞・接続詞 - 最後の音節を送りがなにする。 例 甚だ 全く
    • * 名詞 - 送りがなはない。
    • * 派生語 - もとの語の送りがなの送り方に準ずる。このルールより、漢字に負担させる訓読みが統一される。 例 動く・動かす(活用語尾は「す」)・動き(名詞)

    Wikipediaより引用

    間違いやすい表現
    「ら抜き表現」「い抜き表現」などに気をつける

    ら抜き表現
    誤)見れる 食べれる 受けれる 出れる
    正)見られる 食べられる 受けられる 出られる

    い抜き表現
    誤)~してる ~してない 使ってる
    正)~している ~していない 使っている

  2. 5.2. 差別/禁止用語
    ウェブもテレビ・ラジオ放送などと同様で一般的な通信と異なり、不特定多数に一斉に情報を伝達することができるメディアであるため、その社会的責任は重く、その内容には正確性に加え健全であることが求められます。
    1. a. 最初から差別を目的として作成された用語
    2. b. その状態や職業そのものが侮蔑の対象とされたもの
    3. c. 元は差別とは無関係であるが、差別的に使われる事が多い、又は多かった用語
    4. d. 正式な呼称・表記をわざと使用しない事による侮蔑を目的とした語
    5. e. 対象に対して揶揄的であるもの
    6. f. 語に差別的と思われる表現を含むものや、差別的観点から作られたとされる語
    7. g. 語が、語の示す人々や地域の実体を正確に表していないもの、特にその内容が侮蔑的であるもの
    又、以下のようなものも差別用語とされる場合があります。
    * 語源上は差別的意図とは無関係だが、語感が差別的意図や差別用語を連想させるもの
    * 誤解によるもの・根拠が希薄なもの
  3. 5.3. 機種依存文字
    記号(丸囲み文字・数字など)や固有漢字、は機種によって正確に表示されないため、原則として使用してはいけません。
  4. 5.4. 半角カナ文字
    半角カナ文字もデータを中継するサーバが誤動作する可能性があるため使用してはいけません。
  5. 5.5. 括弧の使い方
    1. 5.5.1. ( )丸括弧、[ ]角括弧、{ }波括弧
      括弧は補足や注釈のために用います。補足や注釈したい言葉や文の直後に付記します。
      括弧が多重になるときの使い方は、内側から、丸括弧、角括弧、波括弧の順とします。
    2. 5.5.2. 「」鉤括弧
      鉤括弧は会話文や語句の引用に用います。また語句の強調に使われることもあります。会話で使う場合は基本的に行を改めます。
      会話文の最後につける句点を省略するか(「……」)、それとも鉤括弧の中に句点を収めるか(「……。」)という問題があります。結論からいえば、文章作法としてはどちらも間違いではありません。
  6. 5.6. 記号の使い方
    1. 5.6.1. ? (疑問符)
      疑問や問いかけを表わします。疑問文かどうか紛らわしい文章の場合に用いると区別が簡単が疑問文であることが明らかであったり疑問の助詞がある場合は、省略したほうが文章が落ちつきます。
    2. 5.6.2. ! (感嘆符)
      驚きや大声など、強調したい箇所に用います。ただし乱用すると強調の役を果たさなくなってしまう上、文章そのものが安っぽくなるので注意が必要です。
    3. 5.6.3. ・ (中黒、なかぐろ)
      同格の単語を並べる場合などに用います。しかし外国語の名前をカタカナ表記する際の姓名の区切りとしても使われるため、他の箇所ではあまり用いないほうが良いでしょう。普通は読点で代用できます。
    4. 5.6.4. ― (リーダー線)
      ダッシュなどとも言います。必ずふたつ続けて用いること。文末などに置いて余情や余韻、省略を表わしたり、注的な文章の前後に置いて補完説明に用いたりします。
    5. 5.6.5. … (三点リーダー)
      文末などに置いて余情や余韻、省略を表わす点は、リーダー線とほぼ同じ。これも原則としてふたつ続けて用います。中黒を三つ続けた・・・で代用する人をよく見かけますが、誤った使い方です。
  7. 5.7. 位置/場所情報の表現について
    サイト内で扱う住所情報については、通常の住所情報と合わせて郵便番号を掲載し情報の利便性を高めます。

Work Flow

  • ホームページ制作の流れ
  • ガイドライン