このブログの文字のコントラスト比を確認する作業を行ったので、その作業メモをつけておきます。今回、この作業を行った結果、リンクテキストの色を変更することになりました。

きっかけ

アクセシビリティがテーマの Accsell という Podcast をいつも聞いています。iTunes で登録してあるので、更新があると知らないうちに iPhone に入ってて便利。YouTube のチャンネルも開設されています。

で、ふと Accsell のサイトにアクセスしようと思ったけど、スペルが思い出せなかったので、出演者の一人である植木さんの名前で検索してみました。こうすれば辿りつけるだろうと。

すると、Accsell のサイトを見つける前に、植木さんが出てる動画を見つけました。ちょっと気になったので、視聴。

URL : 植木真の仕事環境 [67WS10周年記念] – YouTube

動画内では、タイトル通りどんな PC 環境で仕事をしているかを話されていたのですが、その中で「カラー・コントラスト・アナライザー 2013J」というアプリケーションの紹介をされています（4分15秒ぐらいから）。Photoshop のスポイトツールのような機能を使って、前景色と背景色のコントラストを簡単に確認できるとのこと。

「そういえば、今のブログってコントラストとかチェックしてなかったな」と思ったので、さっそくこのブログの文字のコントラストを確認することにしました。

カラー・コントラスト・アナライザーは今のところ Windows 版のみ

「カラー・コントラスト・アナライザー 2013J」は、WebA11y.jp で配布されていました。このサイトは植木さんの会社インフォアクシアによって運営されているようです。そして、「カラー・コントラスト・アナライザー」はもともと WAT-C Web Accessibility Tools Consortium の製品で、インフォアクシアさんが日本語にローカライズしているとのこと。

ダウンロードしようと思って、システム要件を確認したら、現在は Windows 版しか配布されていないようです（XP, Vista, 7 対応）。Mac 環境しかない私はここでストップ。Mac OS版も近日公開予定です。との記述もあるので、期待しておきます。

Colour Contrast Analyserをインストールしてみる

本家には Mac 版があるということなのでさっそく検索。Mac 版のダウンロードは、Colour Contrast Analyser (Win/Mac) | The Paciello Group – Your Accessibility Partner の「Download for Mac」のリンクから行えます。

インストールしようとすると、Mac の Gatekeeper 機能が働いてインストールできませんでした。なので、「システム環境設定」>「セキュリティとプライバシー」>「一般」タブの「ダウンロードしたアプリケーションの実行許可」で「すべてのアプリケーションを許可」にチェックを入れてインストールできるようにします（一応、インストールし終わった後は、「Mac App Store と確認済みの開発元からのアプリケーションを許可」にチェックを戻しておきましょう）。

そして、起動してみたところ、植木さんが動画内で使っていたスポイトが無い！あの機能が欲しかったのにー。利用するとしたら、前景色と背景色のカラーコードを調べて打ち込む必要があります。ちょっと面倒だなあ。

【追記 2014-12-17】上記で “植木さんが動画内で使っていたスポイトが無い！” と書いていたのですが、今日 Colour Contrast Analyser を使っていたら、カラーピッカー機能を発見しました。リンクテキスト色を変更した話と共に記事にしましたので、そちらも御覧下さい。

Chrome の拡張機能 “Accessibility Developer Tools” をインストールしてみる

他に良いの無いかなと調べていたら、Chrome の拡張機能でそれっぽいのが見つかる。Accessibility Developer Tools という Google さんが提供しているものです。Web 制作会社のミツエーリンクスさんがこのアプリケーションの紹介記事を書かれていました。

インストールすると、Chrome のデベロッパーツールで“Elements”を選択している際、サイドパネルに“Accessibility Properties”というタブが追加されます。私の場合は、画面の狭さのためか、最初は Accessibility Properties タブが隠れていました。「>>」という記号をクリックすれば、隠れている Accessibility Properties タブを表示できます。

試しに先ほどのミツエーリンクスさんの記事のコントラストを確認してみます。デベロッパーツールを表示させて、虫眼鏡アイコンをクリックして調べたい箇所をフォーカスします。この時、Accessibility Properties タブが隠れてしまっている場合は先ほどの方法で表示させます。

Color の箇所で、“Contrast ratio: 15.91”という結果が出ました。これは、このテキストの色と背景色のコントラスト比が、“15.91 : 1”であることを示しています。

コントラスト比が適切かどうかを調べる

結果が出たので、この“15.91 : 1”という比率が適切かどうかを判断します。基準になるのは、“Web Content Accessibility Guidelines (WCAG) 2.0”です。「うぃーきゃぐにーてんぜろ」と発音するようです。名前の通り、Web 上に存在するコンテンツのアクセシビリティに関するガイドラインです。WCAG 2.0 は HTML や CSS 等の仕様を策定している W3C が発行しているもので、日本の JIS 規格「JISX8341-3（高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第３部：ウェブコンテンツ）」も、この WCAG 2.0 を参考に策定されています。

では、この WCAG 2.0 において、どの程度のコントラストを確保することが求められているかを確認します。正規の文書は英語でしか公開されていませんので、基本的には原典にあたることが求められます。「でも、英語苦手だなあ」という人のために、日本語に訳されたものがあります。これは、ウェブアクセシビリティ基盤委員会、通称WAIC（うぇいく）が公開しているものです。この委員会は先ほどの植木さんが委員長を努められています。

ということで、日本語訳された文書でコントラスト比について書かれいている箇所を見てみましょう。長いページですが、ページ内検索をすればすぐに見つかります。項目番号 1.4.3 に「最低限のコントラスト」という項目がありました。この部分を引用してみます（一部整形）。

上記のように、4.5：1 のコントラスト比が確保されていれば、最低限の基準は満たされているということになるようです。先ほどのミツエーリンクスさんの記事は、15.91 : 1 だったので、全く問題ないようです。逆に、例えばこれが 3.2 : 1 など 4.5 より低かった場合はレベル AA の最低限のコントラストの基準に達していないということになります。

そして、少し下にテキストのコントラスト比に関しての箇所がもう一つあります。こちらも引用してみます（一部整形）。

先ほどの 1.4.3 との違いを見てみると、1.4.3 の項目名は「最低限のコントラスト」だった一方、1.4.6 の項目名は「より十分なコントラスト」になっています。なぜ2つの基準が設けられているかというと、これらはレベルが違うのです。1.4.3 はレベル AA の基準、1.4.6 はレベル AAA の基準ということのようです。

WCAG 2.0 には、レベルが A、AA、AAA の3段階あります。これは各サイトにおいてアクセシビリティ方針を策定する際「うちのサイトはこの基準をクリアすることを目標にしていますよ」ということを決める指針になるようです。これ以上書くと脱線しすぎな感じがありますので、このくらいで止めておきますが（自分の理解も怪しいのであまり書き進めるとよくない）、今回のコントラストに関する基準もそうだったように、A < AA < AAA と A の数が増えるごとに、達成基準が厳しくなります。

このブログのテキストと背景色のコントラスト比を調べてみた

上記した Chrome の拡張機能 “Accessibility Developer Tools” を用いた方法で、このブログも調べてみます。まずは通常のテキストを調査。コントラスト比を示す値は“Contrast ratio: 18.26”なので問題ないようです。良かったー。

次に、リンクのテキストを調べました。“Contrast ratio: 2.58”でした。これはマズい。レベル AAA の「より十分なコントラスト」はもちろん、レベル AA の「最低限のコントラスト」の基準すら満たしていません。

もう一つ、フッターのテキストも調べました。“Contrast ratio: 6.98”でした。Accessibility Developer Tools 上では問題無い表示になっていますが、レベル AAA で設定されているコントラスト比は 7 : 1 なので微妙に足りてません。

ひとまずまとめ

今回の結果を受けて、リンクテキストの色を変更することにしました。このブログでは特にアクセシビリティ方針を立てているわけではないですが、なるべくアクセシブルなコンテンツ作りを心がけたいので、リンクテキストの色はレベル AAA の 7 : 1 を達成するような色に変更する予定です。

以前、こんなツイートをしました。

最近、プロフィール画像とかを border-radius 使って正円にしてるのよく見かけるけど、あれって描画処理にかかるコストってどんなもんだろう。普通に正円の画像を切り出した方が描画速い気がするけど、何か理由があるのかな。

— mzmjp (@mzmjp) 2014, 4月 19

「border-radius で画像丸くするより、丸くした画像使った方がパフォーマンスいいんじゃないのかなあ。何でそうしないんだろう」という疑問。今回はこの疑問に対する答えの一つになりそうなものを見つけたので書き留めておきます。

先日、Tokyo WebGL Meetup のサイトで、border-radius でプロフィール画像を丸くしているのを見つけました（ちなみに、このイベントは iOS 8 から Safari で動くようになる WebGL をテーマにしたイベントです。iPhone の小さな画面の中で、3DCG 動くのヤバい）。プロフィール画像のソースを見てみたら、”pbs.twimg.com” を発見。ということは、 Twitter からプロフィール画像を持ってきてるのかな。

Twitter にアップするプロフィール画像は四角。Twitter からプロフィール画像を持ってくると、画像は四角のまま。それを丸く見せるには、border-radius を使う。というのが、最初の疑問の答えの一つになるんじゃないかなあ、と思いました。

余談ですが、「サイトで使うプロフィール画像を何で Twitter から持ってくるのか」も考えてみました。これは、プロフィール画像を変更した際に、自動で切り替わってくれるからではないでしょうか。サイト上のプロフィール画像が古いまんまということは無くなりそうです。これは、プロフィール画像を自分で上げずに Twitter から持ってくるメリットの一つになるのではないでしょうか。

このブログのデザインを少々変更したので、メモしておきます。何が問題でどう解決したかを書き記しす形で。これらのデザイン変更は少しずつ適用させていたのですが、今回で一応一段落できそうです。

問題点

このブログを読み返したり、他の方のブログを読んでいて「ここをこう直したいな」と思う箇所がいくつか出てきたので、まずそう思った箇所を書き出してみました。

1. このブログに関するメタ情報が無いので、何のブログかわからない
2. スマートフォンで見ると、ヘッダーが大きくてコンテンツの表示量が少なくなっている
3. ヘッダー部分の背景テクスチャが、Retinaディスプレイの iPhone で見ると汚く見える
4. PC で見た際に、横幅がかなりあるので目が疲れる

改善策

次に、上の段落で書きだした問題点を解消するための改善策を考えました。

問題点1.どこを探しても、このブログに関するメタ情報が無いので、何のブログかわからない

改善策1：フッターにブログの概要を掲載、新規に about ページの作成

問題点2.スマートフォンで見ると、ヘッダーが大きくてコンテンツの表示量が少なくなっている

改善策2：検索フォーム部分をフッターへ移動し、コンテンツの表示量を増やす

問題点3.ヘッダー部分の背景テクスチャが、Retinaディスプレイの iPhone で見ると汚く見える。

改善策3：Retina 対応のテクスチャに変更

問題点4. PC で見た際に、横幅がかなりあるので目が疲れる

改善策4：本文の max-width を縮小。line-height を調整して読みやすくする

上記のように改善することに決め、作業をはじめました。

改善策1：フッターにブログの概要を掲載、新規に about ページの作成

今回のデザイン変更以前、フッターには mzmjp.net と自分が利用している Webサービスのリンクが置いてあるだけでした。しかも、全部ロゴだけ。なので、このわかりづらい形式は廃止。このブログの概要文を載せました。

そして、aboutページを作成しました。aboutページには、このブログで何を書いているかや、自分の興味関心について少し書きました。文の最後に、最終更新日の日付を入れたのですが、これ入れると昔のインターネットっぽくなりますね。

この aboutページのリンクをフッターの概要文にリンク。これで、簡単にわかればいい人はフッターの概要文を見れば OK。もう少し知りたいと思ってくれた人は、概要文から aboutページに飛んでいただければ OK になりました。

改善策2：検索フォーム部分をフッターへ移動し、コンテンツの表示量を増やす

PC で見ている時は表示領域が大きいのであまり気にならなかったのですが、スマートフォン（私は iPhone 5 を所有しています）で見た際にヘッダーが大きく思えてきました。「なるべく早い段階でメインコンテンツが表示されるサイトが好き」という個人的な好みに則って改良しました。

まず、これが改良前の画面です（開発環境の画像なので、ブログのタイトルが本番のものと異なっています）。

改良前は、ヘッダー部分の高さが 99px でした。ヘッダー内にある検索フォームをフッターに移動させてヘッダー部分を縮小したものが以下の画面です。

この改良の結果、ヘッダーの高さを 39px まで抑えることができました。約60%減です。

そして、ヘッダーには検索ボタンのみを残しました。虫眼鏡アイコンは Webフォントです。fontello というサービスを使うと、各種 Webフォントサービスから自分が利用したいフォントだけをダウンロードすることができます。

検索ボタンは、虫眼鏡アイコンのみにせず、テキストも併記しました。理由は、もし何らかの理由で虫眼鏡アイコンが表示されなかった場合を想定したからです。虫眼鏡アイコンはあくまで「ここをクリックすれば検索できる」という認知を補助するためのものです。

この検索ボタンをクリックすると、フッターに移動した後、検索フォームにフォーカスがあたります。この動作は、jQuery を利用したスクリプトを書いて実装しました。

また、色が変わっている箇所全体がリンク範囲になっています。これは、他のサイトでリンクがフォントのみになっていて、ボタンのように見えていてもフォント以外の周辺領域はリンク範囲になっておらず、不便な思いをしたことがあるからです。

改善策3：Retina 対応のテクスチャに変更

テクスチャは Subtle Patterns から、Brilliant という素材をお借りして作りました。Photoshop で色を乗せただけです。

改善策4：本文の max-width を縮小。line-height を調整して読みやすくする

もともと、960 Grid System というフレームワークがお気に入りだったので、セオリー通りに本文の幅を 940px にしていたのですが、他のブログより目の横移動が激しいので、 820px まで max-width を狭めました。幅を狭めたら本文がこれまで以上に詰まって見えたので、本文の line-height を 1.4 から 1.7 に変更しました。

その他変更点

上記の改善策以外にも、いくつか変更を行いました。

1.JavaScript をインライン化した

上の改善策2のスクリプトを書いた時は、個別に js ファイルを設置していたのですが、Google の PageSpeed Insightsで「小さな JavaScript はインライン化しろ」と言われたので、その通りにしました。

2.Google の広告をはずした

記事と記事の間に表示させていた Google のテキスト広告をやめました。クリック率がそんなに良い訳でもないし、PageSpeed Insights でいつも広告関連の JavaScript について注意されるし、いいことないので外しました。

3.Syntax Highlighter やめた

Syntax Highlighter、高機能で良かったけど、必要なファイルとか指定が多い。 Google Code Prettify大変良い | Border/memo を以前読んで、目をつけていた Google Code Prettify を利用することにした。CSS が2個から1個に、JavaScript が5個から1個に。HTTPリクエスト数を減らして、パフォーマンス改善を図れます。css は scss ファイルにして、style.css に @import した。

4.Google の Analytics をユニバーサル アナリティクスに変更

自分のサイト（このブログ含む）と Tumblr 2つ（リブログ+短文用と無印良品用）に仕込んでいた Analytics をユニバーサルアナリティクスに変更しました。私の場合は、トラッキングコードを変更するだけで完了しました。Google 公式のヘルプを読んだのですが、いまいちわからなかったので、こちらのページを参考にさせていただきました → 【緊急解説】ひと目でわかる！ユニバーサル アナリティクスへのケース別アップグレード方法（第92回） | Web担当者Forum

1から3は、パフォーマンス（表示速度）のための施策です。現在、Webデザインで重要視する必要があるものは「アクセシビリティ」と「パフォーマンス」だと、私は思っています。ちなみに、Webアクセシビリティに関しては、書きかけの記事があります。

とりあえず完了＆個人的な反省

これらの施策を持って、デザイン変更はとりあえず完了しました。また何か修正したい点が見つかったら、その都度短い記事を書いていくようにします。

今回の修正に関しては、修正作業そのものはそんなに時間かからなかったのに、この記事を見返しては直し見返しては直しを繰り返してしまった。デザイン修正はじめてから何ヶ月経ってしまったことか。

これからは、当然文章の質を上げることを忘れることなく、なおかつ更新量を増やすことも考えよう。どんなに体面（デザイン）を取り繕っても、中身（コンテンツ）が無きゃ誰も相手にしてくれませんよね。