WCAG基準の実践：カラーコントラスト比改善
株式会社COMPASS デザイナーのパジェロです。
COMPASSでは（いまのところ）デザインチーム主導でアクセシビリティ観点でのプロダクト改善に継続的に取り組んでいます。
WCAG2.1を基準にしたアクセシビリティガイドラインを制作し、全項目の基準達成に向けて改善を進めています。今回はその中から「カラーコントラスト比」を改善する取り組みについてご紹介します。
今回の対象項目は以下。
色 - テキストのコントラスト
30px未満（太字の場合24px未満）のテキストに、4.5:1 以上のコントラスト比がある。
30px以上（太字なら24px以上）のテキストに、3:1 以上のコントラスト比がある。
ただし以下の場合は対象外とする。
- 非アクティブなUI要素
- 純粋な装飾としての文字要素
参考）WCAG 2.1 達成基準 1.4.3
実現に向けて計画を立てる
アクセシビリティ観点での改善は色んな意味で進めるのがめちゃくちゃ大変なのでちゃんと計画しないとユーザーの手元に届くところまでたどり着けません。（最後に詳しく書きます）
そこで進め方をちょっと工夫し、いきなり理想状態を目指すのではなく、クリティカルなところからステップバイステップで少しずつ実現していくことにしました。
「テキストのコントラスト」実現に向けた3ステップ
ステップ 1：4.5:1、3:1を満たせておらず、読めないと学習が成立しない箇所を直す
ステップ 2：4.5:1、3:1を満たせておらず、読めなくても学習が成立する箇所を直す
ステップ 3：ステップ 1, 2でコントラスト比を調整したことにより画面内の強弱や調和のバランスが狂っている箇所をいい感じに調整する
今回は上記のうち「ステップ 1」だけをリリースすることを目指しました。
また同時に、「非テキストのコントラスト比」も視野に入れることにしました。
色 - 非テキストのコントラスト
アクティブなUI要素や、情報を理解するのに必要なグラフィックが、隣接した色との間で 3:1 以上のコントラスト比がある。
ただし以下の場合は対象外とする。
- 非アクティブなUI要素
- 純粋な装飾としてのグラフィック要素
参考）WCAG 2.1 達成基準 1.4.11
テキストと非テキストはもちろん別問題で、WCAGにおける基準も微妙に異なるので、基本的には分けて考えるべきですが、デザインファイルの整理上でも実装の仕組み上でもテキストも非テキストも区別なく共通のカラーパレットをもとに定義されている箇所が多く、結局引っ張られて同時に変更されることになりますし、それがアウトプットとして望ましいことも多いです。そこで、非テキストに「ステップ 0」という特殊な基準を設けて、今回そこだけは同時に考えることにしました。
「非テキストのコントラスト」実現に向けた1+3ステップ
ステップ 0：テキストコントラストのステップ1と同時に対応したほうが効率的な箇所を直す
ステップ 1：4.5:1、3:1を満たせておらず、認識できないと学習が成立しない箇所を直す
ステップ 2：4.5:1、3:1を満たせておらず、認識できなくても学習が成立する箇所を直す
ステップ 3：ステップ 1, 2でコントラスト比を調整したことにより画面内の強弱や調和のバランスが狂っている箇所をいい感じに調整する
現状の調査
実装とデザインカンプを1画面ずつ見ながら、計画時に設定した「ステップ 1」の対象である「4.5:1、3:1を満たせておらず、読めないと学習が成立しない箇所」を洗い出していきました。
コントラスト比の測定には以下のようなツールを使いました。
ちなみに、今回は使いませんでしたが、対象がWebページならコードを自動でチェックしてくれるツールもあるようです。
調査対象のページが多かったりUIが複雑な場合は有用だと思います。
変更内容の検討
洗い出した対象箇所それぞれにおいて、どう変更すると基準を満たすことができるか、非テキストのステップ 0を考慮すべき点はないか、を検討していきます。
カラーパレットをむやみに増やして全体の統制を失わないよう注意しながら変更方針を決めていきます。
共通のカラー変更だけでは基準が満たせない箇所を発見。ここだけは画面デザイン全体の変更を検討し、ボタンデザインの種類を増やすことにしました。
ポイントはあれもこれもと欲張らないことです。今回のステップではあくまでも「認識できないと学習が成立しない箇所」に絞ると強く心に誓って変更箇所を抽出していきました。
ひととおり検討が完了したら、変更点を「カラー / UIコンポーネント / リソース」と「画面」の2つの軸でまとめてエンジニアさんに伝えます。
全体への適用：実装編
まずは「カラー / UIコンポーネント / リソース」軸での変更から適用していきます。UIに使われているカラーはコード上で共通化されているため、1箇所を変更するだけで大部分の画面に適用されます。
ただし、すべての画面のすべてのUIパーツで共通化されているとは限りません。実装都合やコンポーネント被り、カラーパレットの認識漏れなどで共通化できていない箇所もあります。そこで、デザイン検討時にリストアップしておいた「必ず変更したい箇所」を「画面」軸でチェックしていきます。
画面チェック時のポイントは2点。
変更が適用されていない「必ず変更したい箇所」はないか？
「必ず変更したい箇所」ではないが、実装上の共通化によって変更が適用されてしまっている箇所はないか？あった場合、その変更は実装側を修正してもらうべきか、デザイン側を修正するべきか？（デザイン的に許容可能か？修正する場合の実装工数は許容可能か？）
2 のケースがそれなりに発生するので、エンジニアさんと相談しながら落とし所を見つけていく必要があります。また、将来的にステップ 2, 3を適用した時にどんな完成形になるかイメージした上での判断が必要な場合もあると感じました。
（再掲）
「テキストのコントラスト」実現に向けたステップ
・ステップ2：4.5:1、3:1を満たせておらず、認識できなくても学習が成立する箇所を直す
・ステップ3：ステップ 1, 2でコントラスト比を調整したことにより画面内の強弱や調和のバランスが狂っている箇所をいい感じに調整する
全体への適用：デザインファイル（Sketch）編
実装方針がひととおり整ったら、デザインファイルの大工事を始めます。
COMPASSでUIデザインに使っているツールはSketchです。この日のために整理を欠かさなかったと言っても過言ではない、共通化されたカラーパレットとシンボルを存分に駆使して、効率的に作業を進めることができましたが、「今回の変更対象箇所」と「今はまだ変更しない箇所」をきっちり反映させなくてはならないところにちょっと手間がかかりました。
カラーパレット→シンボル→画面デザイン の順に変更を適用していきます。
カラーパレット
これが変更前のColor Variablesです。今回変更対象になるカラーはオレンジの枠で囲われている7色。
素直に考えれば、この7色をそれぞれ新しい色に変更すると、実装と同様に共通化された使用箇所がきれいに一括で変わって適用完了……なのですが、現実はそう簡単にはいきません。
コード上で共通化されている箇所とSketchファイル上で共通化されている箇所に微妙に差があることが判明したため、正確にシンクロさせるために微調整を施す必要がありました。
繰り返しになりますが、今回の変更対象は「読めないと学習が成立しない箇所」に絞っています。つまり実装上は「今回は古いカラーのまま残す箇所」もあるわけです。そこを正確にシンクロさせておかないと、将来ステップ 2, 3で適用箇所を広げていくときにうまく検討できなくなってしまいます。間で別の機能開発も走るので認識齟齬の温床にもなりそうです。
そこで今回は、このように古いカラーパレットもPrefixをつけて同居させるようにしました。
とはいえ一括で変わってほしい箇所のほうが多いので、
古いカラーを同名のまま新しいカラーに変更
古いカラーを新規カラーとして新設
という手順を取ることで、手作業で変更する箇所を最小限に抑えました。
シンボル
Color Variablesの変更手順「 1. 古いカラーを同名のまま新しいカラーに変更」によって、ほとんどのUIパーツに更新後のカラーを自動で適用することができました。
シンボル単位で今回の対象外だとわかっているものについては、ここでカラーを手作業で戻していきます。
また、グレーを「テキスト（30px未満）」と「テキスト（30px以上）/ 非テキスト」の2種類に分岐させているものもあるので、そこも手作業で調整していきます。
（再掲）
テキストのコントラスト
30px未満（太字の場合24px未満）のテキストに、4.5:1 以上のコントラスト比がある。
30px以上（太字なら24px以上）のテキストに、3:1 以上のコントラスト比がある。
非テキストのコントラスト
アクティブなUI要素や、情報を理解するのに必要なグラフィックが、隣接した色との間で 3:1 以上のコントラスト比がある。
画面デザイン
画面上のUIパーツの多くはシンボル化してコンポーネントとして管理されているため、シンボルのカラーが変更されると同時に画面デザインもほとんどが変更済みになりました。
このあと、シンボルのときと同様に、今回の変更対象外の箇所を手作業で古いカラーに戻す作業と、グレーの使い分けを適用させる作業を行いました。
ここまでで 検討→デザイン→実装→デザインファイル整理 の全工程終了です。実装とデザインファイルの共通化部分のシンクロも完了したため、ステップ 2以降はさらに効率的に進めることができると思います。
まとめ
アクセシビリティ関連の改善はとにかく進めるのが大変です。
大多数のユーザーに向けた施策ではないため効果が測定しづらい。
今回のように対象箇所が広範囲に渡ることが多く、工数が膨らみやすい。
最初からアクセシビリティ観点を考慮して設計されていない場合（そんな場合がほとんどです）、あとから適用することによってデザイン面、システム面での不整合、不都合が生じてしまう。
などなど、阻害要因がたくさんあります。
今回進行するにあたって、これらの要因によってストップしてしまわないように、以下のようなことに気をつけました。
完成形までのステップを細かく分けて一度に進行するスコープを最小にする。
ユーザー観点、デザイン上の理想にしがみつかず、実現可能な落とし所を探る。（とにかく一歩ずつ進めることを最優先に置く）
リリースまでの全工程に推進者として責任を持って張り付く。どうしても開発チームとして最優先の取り組みにはなりづらく、足が長くなることもあるけど粘り強くがんばる。
今後もこれらのことを大切にしつつアクセシビリティ改善を継続していきたいですし、さらに工夫を重ねて実現を加速させていきたいと思っています。
COMPASSではデザイナーに限らず色々な職種で積極的に採用活動を行っています。興味がある方はお気軽にご連絡ください。
COMPASSの公式noteもよかったらご覧ください。
この記事が気に入ったらサポートをしてみませんか？