当サイト制作方針更新
2004年7月14日作成
現在の標準的なディスプレイサイズは 1024×768 ですが、エクスプローラーバー（コンテンツパネル）をブラウザの左側に表示している方は少なくないでしょう。800×600 をターゲットサイズにしているのはこのためです。
1280×1024 以上の画面で閲覧されている方には少々小さく感じられるかも知れませんが、齋主が相対レイアウトで CSS が記述できるようになるまで、今しばらくこのままでお許し下さい。
JavaScript を極力使わないという方針は、第3世代のページでも継承されています。（理由は、第一にセキュリティのために JavaScript を OFF にしているユーザーがいること、第二に JavaScript を異なる環境下で同じように動作させるのが大変なため。）
唯一、最終更新日の自動取得・出力で例外的に5行くらいの短い JavaScript を使ってますが、もちろんこれはページ制作省力化のための措置です。JavaScript を切るよう、あるいは警告を表示するように設定している方には多少不便な思いをさせてしまうかも知れませんが、ページによっては頻繁に微修正することもあるため、何卒、ご理解いただければ幸いです。
一見、以前のスタイルに比べて複雑なレイアウトになってますが、ソース構造は以前のページよりも、むしろ単純化されています。具体的にはレイアウトやデコレーション目的のタグを大幅に削り、全て外部CSSファイルでスタイルを一括指定するようにしました。
また制作環境もHTMLエディタ（ホームページビルダー）ではなく、テキストエディタ（EmEditor）から直接ベタ打ちするようになりましたが、エディタ側でもテンプレートを用意したり、自動補完プラグインや自作の CSV → テーブル変換マクロを活用したりして、実はここでも以前に比べてかなり作業量が削減されています。
レイアウト面を CSS 依存にして HTMLソースを簡素化したことで、実は携帯電話のような、テキストベースのブラウザでの表示が可能になりました。ただ、当サイトは１ページあたりに盛り込む情報量が比較的多い方なので、携帯電話の機種によっては最後まで文章を表示できません。またページのエンコードも全て UTF-8 にしたので、そちらが原因で表示できない / 文字化けすることがあるかもしれません。
もともと携帯電話向けに作成しているコンテンツではないので、このあたりについては修正する予定は今のところありません。ただ、今後、別のサイトの制作を手掛ける際に活かすかも知れません。
個人経営の私的なサイトにクロスプラットフォーム志向（主として幅広いPC環境の人に対して同じように閲覧できるようにすること）なんて必要なのか？という疑問を持たれる方もいらっしゃるかも知れません。いかにも、閲覧する人/させたい人が決まっている私的なサイトに関しては特に意識する必要はないかもしれません。
拙齋でアクセシビリティをことさら意識しているのは、近年、齋主が公共機関のオフィシャルサイトの制作を何件か手掛ける機会があって、いざアクセシビリティを意識したページ造りをしようと思っても一朝一夕には出来ないことを思い知らされたためです。そういう事情ですので、ここでは齋主の私的な取り組みくらいに考えていただければ結構です。
動作確認環境【 】内は確認頻度。 → SCREENSHOTS
想定閲覧環境前世代（第２世代）からの変更点課題・悩みどころ今回のリニューアルの悩みどころは、総じて「アクセシビリティ（閲覧快適性）と実用性のバランス」もしくは「見た目の見やすさ（デザイン）と、マークアップ構造のバランス」という点に尽きます。これが意外に両立しないことが多いのです。
「アクセシビリティ（閲覧快適性）と実用性のバランス」という面では、たとえばこのサイトでは、テキスト中に CJK Extention 漢字を使用している個所がありますが、その中には "SimSun (Founder Extended)" というフォントを持っていないと表示できない個所もあります。（このフォントは MS Office XP Proofing Tools などから入手することができます。）これはアクセシビリティの上で言えば、もちろん良いことではありません。しかし、このサイトは立ち上げ当初からコンテンツ重視の方針を貫いてきていることもあって、コンテンツデータの将来的な二次利用も見据えて、敢えて CJK Extention 漢字をサイト中で使用してます。
また一般訪問者に対する見映え重視か、再利用性向上を目的としたマークアップ構造重視かというジレンマもあります。当サイトは一般向けのコラムもあり、同時に専門家向けの文書もあるという中途半端な位置にあるため、文書構造も見た目も同じように気を遣う必要がありました。以下に掲げる当サイトの自己評価をご覧いただければ、そのジレンマを端的に窺うことができるかもしれません。
自己評価WCAG 1.0 のWebページ アクセシビリティのチェックリストです。「評価」の欄に、条件を概ね満たしていれば「○」、満たしていなければ「×」、該当するコンテンツが当サイト内にない場合には「－」をつけています。「 * 」のついているものは、将来的に改善する計画がある項目を示しています。
| 汎用項目 | 評価 | |
|---|---|---|
| 1.1 | あらゆる非テキスト系要素には代替テキストを用意する。(alt属性・longdesc属性を使用する、要素のコンテンツ内にそれを解説するテキストを置く、等)非テキスト系要素には以下のものを含む。画像、画像化されたテキスト(シンボルマーク含む)、イメージマップ、アニメーション(動画GIF等)、アプレット、プログラミングオブジェクト、 ASCIIアート、フレーム、スクリプト、リスト行頭のマーク、空白用の画像、画像ボタン、音声(ユーザーによる動作実行の実装・非実装にかかわらず再生されるもの)、スタンドアロンオーディオファイル、ビデオのオーディオトラック、ビデオ。 | ○ |
| 2.1 | 色を使った全ての情報は、その色が再現出来ない状態でも利用できるようにする。一例としては、文脈やマークアップを利用するなど。 | ○ |
| 4.1 | テキストやその代替形式中、使用されている言語が切り替わる箇所では、それを分かるように示す。 | － |
| 6.1 | コンテンツは、スタイルシートを用いなくても読み取れるように構成する。例えば指定したスタイルシートを適用できない環境でHTML文書を表示させても、正しく読めるようにしなければならない。 | ○ |
| 6.2 | ダイナミックコンテンツでは、コンテンツ内容の移り変わりに伴って代替形式もアップデートする。 | － |
| 7.1 | ユーザーが明滅(flicker)を制御できるユーザーエージェントが開発されるまで、スクリーンを明滅させることをしない。 | ○ |
| 14.1 | サイトのコンテンツに適する言葉を、出来うる限り分かり易くシンプルに表現する。 | ○ |
| 画像とイメージマップの取り扱い | 評価 | |
| 1.2 | サーバサイド・イメージマップのリンク領域には、多様なテキストリンクを設置する。 | － |
| 9.1 | イメージマップはサーバサイドのものではなく、クライアントサイドのものを用意する。ただしクライアントサイドでもリンク領域の形状を定義出来ない場合は例外である。 | － |
| テーブルの取り扱い | 評価 | |
| 5.1 | データテーブルでは行のヘッダと列のヘッダを区別する。 | ○ |
| 5.2 | 行や列のヘッダが複数の理論レベルを持つ場合は、マークアップを利用してデータセルとヘッダセルの関連付けを行なう。 | － |
| フレームの取り扱い | 評価 | |
| 12.1 | フレームを識別できるよう、またナビゲーションを容易にできるようにそれぞれのフレームにはタイトルを付ける。 | － |
| プログラム要素の取り扱い | 評価 | |
| 6.3 | スクリプト、アプレット等のプログラミングオブジェクトに関する機能を環境が持たない、機能をオフにしている状態でもページを利用できるように作成する。不可能であれば、別にアクセス可能なページを作り、代替となる情報を提供できるようにする。 | ○ |
| マルチメディアコンテンツの取り扱い | 評価 | |
| 1.3 | ユーザーエージェントが、ビジュアルトラックの代替テキストを自動的に読み上げることが出来るようになるまでは、マルチメディアプレゼンテーションに用いるビジュアルトラックの重要な情報に、音声による記述も提供する。 | － |
| 1.4 | 時間軸を以って動作する、ムービーやアニメーションでのマルチメディアプレゼンテーションには、代替要素を同期する。 | － |
| 不適合の場合 | 評価 | |
| 11.4 | もし最善の努力を尽くしてもアクセシブルなページを作成できない場合、W3Cのテクノロジーを使った代替ページへとリンクさせる。代替ページはアクセシブルであるべきで、オリジナルページと同内容の情報(または機能)を持たせるべきで、オリジナルページと同じ更新頻度を保つべきである。 | － |
| 汎用項目 | 評価 | |
|---|---|---|
| 2.2 | 前景色と背景色には充分コントラストを付け、色盲・色弱、またはモノクロモニターで閲覧するユーザーにも識別可能であるようにする。[画像に関しては優先度･2、テキストに関しては優先度･3] | ○ |
| 3.1 | 適切なマークアップ言語がある場合は、画像を用いずマークアップを記述する。 | － |
| 3.2 | 公式に定義された文法に沿って文書を作成する。 | ○ |
| 3.3 | レイアウトやプレゼンテーションのコントロールには、スタイルシートを利用する。 | ○ |
| 3.4 | マークアップ言語の属性の値やスタイルシートのプロパティには、絶対値でなく相対値を使用する。 | × |
| 【現状と展望】現在はフォントサイズなどは全て "px"（ピクセル）で指定している。このページを見ても分かるように、レイアウトの都合でやむを得ず小さめのフォントで固定している所もあり、視力の弱いユーザーのことを考えれば本来好ましくない点がある。環境差によるレイアウトの崩れを回避できる目処が立てば、これを "em" などの相対サイズに変更することは考えているが、様々なケースでの影響を検証して対策を取るまでは、当面、現状を維持することなる。 | ||
| 3.5 | 文書構造を表すには、仕様に従ったヘッダ要素を使用する。 | ○ |
| 3.6 | リストやリストアイテムには、適切なマークアップを行なう。 | ○ |
| 3.7 | 引用文にはマークアップを行なう。インデントなどのフォーマット効果を目的とした引用マークアップは行なわない。 | ○ |
| 6.5 | ダイナミックコンテンツはアクセシブルであることを保証する。またはダイナミックコンテンツの代替コンテンツを提供する。 | － |
| 7.2 | ユーザーが点滅(blink)を制御できるユーザーエージェントが開発されるまで、スクリーンを点滅させることをしない。(定期的にオン・オフ表示を切り替えることを含む) | ○ |
| 7.4 | ページの自動更新を止める機能を実装したユーザーエージェントが開発されるまで、定期的に自動更新するページは作成しない。 | ○ |
| 7.5 | ページの自動リダイレクトを止める機能を実装したユーザーエージェントが開発されるまで、自動的にリダイレクトさせるマークアップの使用はしない。代わりにサーバサイドでページ移動ができるような設定を行う。 | ○ |
| 10.1 | ユーザーによる選択で、新しいウィンドウが開かないよう設定できるユーザーエージェントが開発されるまで、ユーザーへの告知無しにポップアップなどで新しいウィンドウを開いたり、使用中のウィンドウを変更したりしない。 | △ |
| 【現状と展望】現在、他サイトへのリンクは全て新規ウィンドウで開くように設定してある。これは他サイトに対する著作権的配慮の意味がある。将来的に現状の方式を見直す可能性はあるが、修正要望が出ない限り現状を維持する。 | ||
| 11.1 | 作業を遂行するにあたり、W3Cのテクノロジーが利用でき、それが適切であるなら利用すること。最新バージョンがサポートされているなら、それを利用すること。 | － |
| 11.2 | W3Cのテクノロジーの中で、非推奨とされているものを使用しない。 | ○ |
| 12.3 | 情報のブロックが大きい場合は、自然で適切なグループに分けて区切り、扱いやすくする。 | ○ |
| 13.1 | リンク先を分かりやすく表示する。 | ○ |
| 13.2 | メタデータを用いて、ページとサイトに意味情報を追加する。 | ○ |
| 13.3 | サイトの全体的な構造に関する情報(サイトマップや目次など)を提供する。 | ×* |
| 【現状と展望】目下、サイト構造を再構築中。固まり次第、サイトマップを公開する予定。 | ||
| 13.4 | ナビゲーションメカニズムには一貫性を持たせる。 | ○ |
| テーブルの取り扱い | 評価 | |
| 5.3 | テーブルをレイアウト目的で使用しない。ただしテーブル内の情報を横に向かって順に読んでいった時、意味が通じるようならその限りではない。横に向かって順に読んでいって意味が通じない場合は、代替形式を用意する。(テーブル内の情報を一行に書き抜いたもの) | △ |
| 【現状と展望】唯一、例外的にトップページ（http://www.karitsu.org）のみ、レイアウトにテーブルを利用している。将来的展望は未定。 | ||
| 5.4 | レイアウト目的でテーブルを使用した場合、視覚的なフォーマット効果を狙ったマークアップの使用はしない。 | ○ |
| フレームの取り扱い | 評価 | |
| 12.2 | フレームタイトルだけでは分かりにくい場合は、そのフレームの目的やそれぞれのフレームとの関連性についても記述する。 | － |
| フォームの取り扱い | 評価 | |
| 10.2 | ラベルとフォームコントロールの明らかな関連付けをサポートしたユーザーエージェントが開発されるまで、暗黙の状態でフォームコントロールと関連ラベルがある場合は、必ず適切な位置に配置する。 | － |
| 12.4 | ラベルとコントロールを明確に関連づける。 | － |
| プログラム要素の取り扱い | 評価 | |
| 6.4 | スクリプトとアプレットを使用する場合には、イベントハンドラを入力機器に依存させない。 | － |
| 7.3 | ユーザーが動くコンテンツを停止できるユーザーエージェントが開発されるまで、ページ内に動きのあるコンテンツを挿入しない。 | ○ |
| 8.1 | スクリプトやアプレットのようなプログラミング要素は、それ自体をアクセシブルに作成するか、支援技術との互換性を持たせる。[ページにとって欠かせない機能であり、その機能の代替手段が無い場合は優先度･1、そうでなければ優先度･2] | － |
| 9.2 | 独自のインターフェイスを持つ要素は、どんな種類のデバイスを用いても操作出来るよう設計する。 | － |
| 9.3 | スクリプトのイベントハンドラは、機器に依存するものでなく理論イベントハンドラを指定する。 | － |
| 汎用項目 | 評価 | |
|---|---|---|
| 4.2 | 略語やイニシャルのような略称が使われる最初の箇所では、正式名称も表記する。 | ○ |
| 4.3 | 使われている主要な言語を識別しておく。 | ○ |
| 9.4 | tabキーで、リンク、フォームコントロール、オブジェクトを移動する場合、移動の順番が理論的になるように設定する。 | ×* |
| 【現状と展望】Tab キーを使ったリンク オブジェクトの移動は、アンカータグ内に ' tabindex="1" ' などと記述することで制御できる。ページ上部のメニューバーや左側のコンテンツメニューのリンクを飛ばして、ページ右側のメインコンテンツ部のリンクを Tab キーで直接移動できるように制御することは考慮しているが、実際に施行するかどうかは未定。現在は未設定。 | ||
| 9.5 | リンク(クライアントサイド イメージマップ内のリンクを含む)、フォームコントロール、フォームコントロール グループの中で重要度の高いものには、キーボード操作によるショートカットを設定する。 | ○ |
| 【現状と展望】ショートカットキーの割り当ては、アンカータグ内に ' accesskey="x" ' のように記述する。ページ上部のメニューバーと、左側のコンテンツメニューに対して固定のショートカットキーを割り当てる可能性はあるが、今のところ試験段階。テンプレートの段階で埋め込めば良いので、前項（9.4）に比して実現は容易。（→ 2004/07/27対応） | ||
| 10.5 | 隣接するリンクがそれぞれ別のリンクであることを正しく処理できるユーザーエージェント(支援技術を含む)が開発されるまで、隣接するリンク間には印刷可能な非リンク文字を挿入する。非リンク文字の前後にはスペースを入れる。 | ○ |
| 11.3 | ユーザー側で設定した言語やコンテンツタイプで文書を受信できるように情報を提供する。 | － |
| 13.5 | ナビゲーションバーを設置してナビゲーションの仕組み部分を強調し、アクセスしやすくする。 | ○ |
| 13.6 | ユーザーエージェントに配慮し、関連のある複数のリンクはグループにまとめて、各グループを識別化する。また、これらの処理を適切に処理できるユーザーエージェントが開発されるまで、グループを読み飛ばすことが出来る方法も提供する。 | ○ |
| 【現状と展望】方法としては、ページの最初にページ内コンテンツの目次とリンクを設置する方法が考えられる。１ページあたりのコンテンツ量が多いものに関しては対応予定だが、サイト全体に適用するかは目下検討中。（→ 2004/07/27 対応） | ||
| 13.7 | 検索機能がある場合は、ユーザーのスキルや設定に応じた各種の検索が行えるようにする。 | －* |
| 【現状と展望】すでにサイト内検索（ Unicode版 msearch 導入予定 ）は and / or / not 検索に対応している上、「過立齋叢書電子検索系統」も通用字体同一視機能を持たせている。両者ともバージョンアップ予定（時期は未定）。 | ||
| 13.8 | 見出し、段落、リスト等の行頭には、それらを識別できる情報を配置する。 | ○ |
| 13.9 | 文書の集合に関する情報を提供する。(文書が複数のページをまたぐ場合など) | － |
| 13.10 | 複数行にまたがるASCIIアートがある場合には、それをスキップできる方法を提供する。 | － |
| 14.2 | ページを理解するのに役立つよう、グラフィックやオーディオプレゼンテーションの内容をテキストで補う。 | ○ |
| 14.3 | サイト全体に一貫したスタイルを持たせる。 | ○ |
| 画像とイメージマップの取り扱い | 評価 | |
| 1.5 | クライアントサイドのイメージマップに示されたリンクの代替テキストを正しく変換できるようなユーザーエージェント(ブラウザ)が開発されるまで、マップに示したリンク先と同じ内容のテキストリンクも用意する。 | － |
| テーブルの取り扱い | 評価 | |
| 5.5 | テーブルには要約(サマリー)を付ける。 | ×* |
| 5.6 | ヘッダラベルとして、ヘッダの内容を短くまとめた(略した)ものを使う。 | ×* |
| 10.3 | 並列に配置されたテキストを正当に出力できるユーザーエージェント(支援技術を含む)が開発されるまで、囲まれたコラムや、テキストを並列にレイアウトしたテーブルには全て、代替形式として一行に直線的にレイアウトされたテキストを用意する。代替形式は同ページ内、別ページを問わない。 | ○ |
| フォームの取り扱い | 評価 | |
| 10.4 | 値が空白のフィールドを正しく扱えるユーザーエージェントが開発されるまで、編集ボックスとテキスト領域には、領域確保用の文字をデフォルトで入れておく。 | － |