Stardust Crown
福祉社会の実現に向けて、多くの理念が生まれ、実行に移されています。多様な価値観の中、用語とその概念の理解自体が難しい場合もありますが、それを知ろうとするだけで、学べるものがあります。
なお、特にウェブデザインでは利用者と実際に触れ合う機会が少ないですから、「知ったつもり・わかったつもり」は厳に慎まなければなりません。常に謙虚に学習していくようにしましょう。
完璧なアクセシビリティとユーザビリティが理想ですが、それには大抵無限のコストが要求され、しかしデザインに費やせるコストは常に有限です。したがって、設計者側が妥協しなければならず、ユーザーサイドの補正を期待せざるを得ない部分は必ず残ります。
その中で、できる限りの配慮を行うこと、また、その時点では達成できない項目も、拡張性をもたせることで将来には実現できるようはかることも大切です。
例えば、文書を記述する言語を考えてみましょう。実は、日本語を選択した時点で、日本語を理解できない人々のアクセシビリティは（制作者側からは）切り捨てられました。もし英語も堪能であれば、英語版も用意できるかもしれませんが、世界中の人が英語または日本語を理解できるわけではないのです……。
一方、アクセシビリティ等はユーザーサイドで確保することも時には可能です。例えば、非常に高機能の翻訳ソフトならある程度内容は理解できるでしょうし、文書の価値が認められれば翻訳してくれる人が現れることもあるでしょう。そのために、ここでは“正しい日本語”を使うことが“拡張性”に役立つといえます。
※言語の例はあくまで喩えです。多くの言語圏にはそれぞれ独自のウェブリソースが存在しますので、日本語を選択しても一般に問題になりません。一方、日本語を母国語としながら障害があって通常のアクセス能力を発揮できない人々もいますが、そのような人々もウェブリソースを利用する権利があるのです。可能なバリアフリーを図るのは、同じコミュニティに属する我々制作者の義務といえるでしょう。
「非常に使いにくい」と「全く使えない」が感覚的に近いせいか、しばしばユーザビリティとアクセシビリティとは混同されます。しかしながら、基本的にこれらは必ずしも一致しない概念です。
端的にいえば、アクセシビリティは（いわゆる）健常者には不要です。（より厳密にいえば、健常者へのアクセシビリティはデザイン成功の前提であるため、一般にアクセシビリティのコストとして意識されません。）だからこそ、デザインする側で特に注意しなければ見落としてしまいがちと言えます。そして、アクセシビリティの配慮の対象外だった場合、まったく“もの”を扱えなくなるので、利用の際には絶対に必要です。
一方、ユーザビリティは、ほとんどのユーザーが意識できることです。そして、必ずしも必要ではありません。（配慮がない場合でも、程度の差はあれ、使いにくくなるだけです。）けれども、一般に多数のユーザーに関わる問題なのです。
アクセシビリティを確保しようとするとき、あるいは多様な人に対してユーザビリティを維持しようとするとき、安易な道として、対象別に異なる“もの”を用意することで済ませがちかもしれません。単に“バリアフリー”の思想を訴えた場合、そのようなある意味で場当たり的な対処をすることが多かったようです。しかし、バリアフリーはアクセシビリティを確保するために必要ですが、“単なる迂回路”を準備するだけですと、社会が「健常者」を前提としている実情は何も変わりません。理想的には“障害を障害と意識しない”ような社会が望ましいと考えられます。
そこで、単にアクセシビリティを確保するだけでなく、健常者も障害者も一緒に使えるような、包括的で汎用的なデザインが求められるようになりました。特別な意識を必要とせず、ありのままに扱えるようなデザイン、ということで“ユニバーサルデザイン”が提唱されたのです。
なお、このような説明をしますと、バリアフリーが古い、劣った考え方のように思われるかもしれませんが、“ユニバーサルデザイン”と“バリアフリー”の思想の原点は共通しているはずです。思想の優劣を示すものではないことに注意すべきかと思います。
ユニバーサルデザインはバリアフリーの優れた実現手段である、と考えればよいでしょう。（あるいは逆にユニバーサルデザインがバリアフリーの思想を併合しているという見方も可能かもしれません。）……実際、ユニバーサルデザインは必ずしも可能とは限りません。どうしても別々の経路を用意せざるを得ない場合もあり、そのときでもアクセシビリティを確保する努力は必要なのですから。
上記の用語を早速使ってみると、デザインとは（制作者たる自分が支払う）コストを睨みながら、拡張性・アクセシビリティ・ユーザビリティを可能な限り高め、ユニバーサルデザインを指向し、それが無理でもバリアフリーは確保するのが望ましい、と言えます。
何だか大変そうですが、幸いにも、ウェブの規格は既にこのような思想を内包しています。W3C の定めた国際規格を遵守するだけで、ある程度しっかりしたデザインを達成することが可能なのです。とはいえ、これ自体にコストが必要ですが、W3C の規格は公開されており、現にインターネット上の多くの人が解説を行っているので、誰でも無料で学習することができます。
付け加えて、公的な規格に従うことはリソースの拡張性の向上に役立つといえます。
まずは、ページの構成を Valid な HTML(XHTML) と Valid な CSS に分離することです。構造と見栄えを分離することはリソースのアクセシビリティの向上に役立つと言えます。
しかしながら、流通しているオーサリングツールが不完全で、上記の学習に困難があると考えられていることから、すなわち、コストの負担が重い作業であるとされているため、一般には余り普及していないようです。
私は、これは学習する価値のあることだと思います。（ HTML 等はプログラムではないため、それほど複雑ではありません。）けれども実際問題として、本当に構造と見栄えを分離するデザインが普及するには、適切なオーサリングツールの開発を待たなければならないでしょう。
※ここでは特にスクリーン上の表示を規定する CSS について述べています。
そして、適切な HTML(XHTML) が用意されていることを前提とすれば、分離された CSS を適切に作成することはリソースのユーザビリティの向上に役立つと言えます。
多くの人がグラフィカルなブラウザでウェブページを見るでしょうから、位置や配色を制御する CSS は、ユーザビリティに大きく関わることになるのです。適切な HTML(XHTML) だけで、人間が直ちに構造や情報を読みとれるわけではありませんから。
ところが、ユーザースタイルシートの設定が可能である以上、不満があれば自分で用意した CSS を利用すればよい、従って CSS は自分で満足できるものであればよい、と開き直りたくなるときがあります。それは確かにその通りではあるかもしれません。（事実、私の CSS もそう考えて設計してしまっている部分もあります。）
しかしながら、このような発想は「アクセシビリティを確保すればユーザビリティは捨ててもよい」と翻訳できることを自覚しなければなりません。ユーザースタイルシートの推奨は自らのデザインの失敗を認めることなのです。
さて、望ましい CSS を作成するためには、以下の“CSS デザインの三原則”をしっかりさせるようにします。
世間では“デザイン”というと“もの”を格好良く作ることを指す場合が多く、したがって観賞性ばかりを追求しがちですが、ユーザビリティに関わる前者二つの項目に配慮することも、立派な、そして非常に大切なデザインなのです。
ウェブリソースはテキスト情報がメインですから、可読性は以下の項目を満足すれば大体は大丈夫でしょう。
さて、テキスト情報の大半を p 要素で記述するならば（ほとんどの方がそうなのではないでしょうか？）、p が最も読みやすいようなデザインを選択すべきです。例えば、見出し要素を目立たせるためだけに本文の文字色を薄くする、というのは本末転倒だと思われます。
特に注意が必要なのが、第一の色の組み合わせでしょう。これがひどいと、ユーザビリティというより、ほとんどアクセシビリティに関わる問題になります。
最も重要なのはコントラストですね。背景が暗色系なら文字は明色系、背景が明色系なら文字は暗色系にするのは必須といえるでしょう。（よく言われることですが、白黒にしてみて読めるのが望ましいのです。）
書籍メディアで慣れ親しんでいるのは「白地＋黒文字」ですが、コンピュータ・スクリーンは発光体なのでそれでは目が疲れやすい場合が多く、背景の輝度を少し落とすのが良いとされています。また旧来のコンピュータ環境で主流だった「黒地＋白文字」も文字部分が眩しいので、やはり少し色を付けるべきかもしれません。要するにコントラストがきつすぎるのもよくないようです。
特に本文については、読みやすいことが重要ですから、刺激の強い色は（たとえ目立つとしても）避けるべきです。
なお、自分のスクリーンだけでテストしてしまうと、異なる環境では非常に読みづらくなる場合があります。その他のデザインもそうですが、色々な環境でテストすることが大切ですね。
読みやすいフォントサイズがどのくらいであるかは人によります。ですから、フォントサイズを変更してもデザインが崩れないように、柔軟性に配慮しましょう。なお、フォントサイズを絶対指定（ここではピクセル指定を含む）すると、IE でサイズの調整ができなくなってしまいますから、相対指定（ピクセル指定を除く）しておくことが推奨されます。
もちろん、大きければよいというわけではありません。フォントサイズが過大ですと、結果的に画面に収まる分量が減少し、逆に可読性を損なう場合があります。小さすぎず、大きすぎず……適切な水準が望まれます。
私は、本文のフォントサイズに関しては 100% が望ましいと考えています。さて、本文のフォントサイズを 90% 等に（縮小）しているサイトの発想は、閲覧者が「（無知等の理由で）ブラウザのフォントサイズ設定をデフォルトのままにしている」ことを前提にしているように思えます。（このようなサイトおよび閲覧者を、それぞれサイトＡ群・閲覧者Ａ群と呼びましょう。）一方、フォントサイズを 100% にしておく発想は、閲覧者が「（デフォルトを含め）ブラウザのフォントサイズ設定を自分の好みにしている」ことを前提とするわけです。（同じく、このようなサイトおよび閲覧者を、サイトＢ群・閲覧者Ｂ群としましょう。）
このとき、閲覧者Ｂ群がサイトＡ群を訪問したらどうでしょう？ ……自分の好みでないフォントサイズで文字が表示され、調整（または我慢）にコストを要求されますね。では、閲覧者Ａ群がサイトＢ群を訪問したら？ ……可読性に関する支障はないはずです。サイトＡ群の制作者が意図した“クールな雰囲気”は演出できないかもしれませんが……。
ということで、可読性を重視する私は、本文のフォントサイズを 100% にすることを推奨します。
本文の文字の適当な密度という点では、文字間隔と行間も大切な設定項目です。（CSS で設定するのは“行間”ではなく“行の高さ”ですが。）個人的には、文字間隔は 0〜0.05em くらい、行の高さは 150〜200% が望ましいと思います。
上記には入っていませんが、行の幅もしばしば問題となります。特に昨今の広いスクリーンで、画面目一杯まで文字が連なると読みにくいという声があります。そこで、わざと行の幅を制限して、一行あたりの文字数をコントロールしようというデザインも多く見かけるのです。
私の意見を述べておきます。ブラウザのウィンドウ幅は、狭くする分には、ユーザー側で狭くできます。しかし、CSS で設定された幅を増加させるには、それより遙かにコストを要します。したがって、制作者側で意図的に狭くする必然性は薄いのではないでしょうか。少なくとも、いわゆる幅固定は慎むべきかと思います。
HTML(XHTML) の構造を閲覧者に伝えるような配慮も大切になります。簡単に言えば、要素をその要素らしい見栄えにすることです。見出しは見出しらしく、アンカーはアンカーらしく、定義リストは定義リストらしく……見ただけでそれとわかるような見栄えを用意しましょう。
以下では特に問題となる要素だけをざっと見てみます。
つまるところ目立たせればよいですね。（それもレベル順に……。）本文と異なり、長く連なる場合は少ないので、目立つことを優先してよいでしょう。
また、見出しは本文のアウトラインを把握できるように記述してあるはずですから、見出しだけを簡単に拾えるように、インデント位置を揃えるか、目に入りやすい配置にするのが望ましいと言えます。（右揃えや中央揃えを不規則に繰り返すのは避けるべき、というわけですね。）
ハイパーリンクはウェブで新しく導入された概念なので、旧来の作法が通用しにくいです。そこで、多くのブラウザのデフォルト仕様である【青文字＋下線】に習うのが望ましいと言われます。（このように、デザインを標準手法に揃えるのはしばしば有効です。）
とはいえ、暗色系の背景の場合は青文字は可読性を損ないますし、最低限、【本文と異なる目立つ文字色＋下線】を守ればよいのではないかと思います。また、アンカーでない要素をアンカーらしくデザインするのは構造性を損ないますので、“下線”などを他の要素に適用する際には慎重になるべきです。
HTML(XHTML) の標準的な仕様では、意図した dt と dd のグループ分けが明示できませんので、dt と dd の対応をしっかりさせるようなデザインが望ましいと言えます。（これは CSS の範疇を越える部分がありますが……。）
いわゆる“腕の見せ所”ですね。上記のようなデザインの原則を守っても、なお無限に近い創造性の余地が残されています。あとは我々の工夫次第です。
実践例についてはカスいけサイト私撰集および関連サイトを参考にして下さい。
特にウェブにおけるアクセシビリティとユーザビリティについては、以下のリソースなどが参考になるかもしれません。
なお、私自身のサイトも、アクセシビリティやユーザビリティを完璧に配慮しているわけではありません……。
著作・制作／永施 誠