先日もWebサイトについて書きましたが、今回はデザインについて考えていることを書きます。
デザインと言っても、単に見た目だけのことではなくて、ディバイスの違いへの対応や、アクセシビリティもデザインの範疇に入ります。
異なるディバイスの対応は、レスポンシブデザインと言われていますね。私のHPはレスポンシブデザインにはなっていません。（というか・・・勉強不足でまだできません。）
とりあえずの対応策として、iPadでも見やすくなるように考えてつくりました。iPadは解像度が1024×768なので、HPの横幅を1000pxで設定してつくっています。
下の画像は、SafariのレスポンシブデザインモードでこのBlogの表示を比較した画像です。

上からiPhone6 Plus、iPad Air2、PCでの表示

iPhone6Plus

iPadAir2

DesktopPC

それぞれの解像度に対応して、メニューの位置や表示が変わっています。このBlogはWordPressでつくっているので、レスポンシブデザインに対応したテーマを使えば、簡単につくることができます。
将来的には、HPも対応できるようにしたいと考えています。（ただし時期未定ですｗ）
GWに時間をとって、HPに少し手を入れてみました。（あまり変わっていませんが）
地味ですが、少しでも早く表示できるように、コードをいじったことと、XHTMLの文法にできるだけ適合させました。
Webデザインで、もうひとつ大切なアクセシビリティですが。
これは、かなり敷居が高いですね。Another HTML-lint でアクセシビリティ評価検証ができるので、試しにやってみたら、エラーだらけです（笑）

アクセシビリティチェック

建築にもバリアフリーへの対応やユニバーサルデザインなどがありますが、Webデザインも同様に考える必要がありますね。

下記はAnother HTML-lint 5サイトのアクセシビリティについて引用です。

アクセシビリティチェックについて
アクセシビリティチェックは、総務省の miChecker ver1.2 を検査エンジンとして開発した検査ツールです。将来にわたって無料でご利用いただけます。
最新のウェブアクセシビリティガイドライン「日本工業規格 JIS X 8341-3:2010」、「W3Cスタンダード WCAG 2.0」「アメリカ　リハビリテーション法　第508条」を基に、ウェブページのアクセシビリティ検証を行うことができます。詳細レポートでは問題がある箇所が「問題あり」「問題の可能性大」「要判断箇所」「手動確認」の4種類に分類されます。詳細レポートの問題箇所の行をクリックすると、該当する解説に移動することが可能で、より詳細な情報を入手しやすくなっています。
その他「音声ユーザビリティ」フレームでは画像等の視覚的な情報やレイアウト要素を排除したプレビューが確認でき、また「ロービジョン」フレームでは「視力」「色覚異常」「水晶体透過率」を基にシミュレーション表示が可能です。
評価ツールというと、ボタンひとつですぐ適合不適合の一覧の結果がでるイメージですが、このツールはそうではありません。これはウェブアクセシビリティの検証が、すべて機械的にできるものではないためです。
機械的に判断できる問題箇所の指摘と、人が確認しないと判断できない箇所を指摘する「アドバイザー」的な役割を果たします。例えば画像にalt属性そのものが無いというような明確な問題は「問題あり」と指摘しますが、alt属性があったとしてもその内容が適切かどうかは「人が内容を確認して判断してください」というアドバイスが表示されます。
それに基づいて「人が判断」をし、機械的なチェックとあわせて総合的に達成基準に適合しているかどうかの最終判断を「人」が行う必要があります。