🎨

Web アクセシビリティに配慮し、なおかつ式として例外のないものにしたい色設計

2021/05/18に公開

デザインシステムにおける色設計、ルールをひとつの式で表現できるようにしたい。でもA11y対応でルールが増えるので、どうやったらシンプルにできるかを試行錯誤するお話。

色を展開するルールをシンプルにしたい

色計算が可能なプログラミング言語でひとつの式を使いさえすれば、設計されたカラーシステムを再現できるというのはメリットが多いはずだ。(デザインシステムで定義された色をわざわざコード上で演算する必要があるのかは怪しいけれど)

メリット

式の例

darken($some-color,20%)
	or
lighten($some-color,20%)

上記のように$some-colorに対して明度への演算をかけるだけで赤、青、黄、緑のカラーパレットがデザインシステムに沿ったものになるのであればいくらかコードへの負担が軽減されるのではないだろうか。(と期待しているけど、聞かないとダメですねコレ)

RGBではなく、H(色相)S(彩度)B(明度)として扱うことで、おおまかに明度だけ変更すればUIに必要な色情報が出揃うのは、理由が明確なので今後あらたにルールを作る場合においても追加しやすい。

画像のように明度だけで展開し、それでも差がつきづらい色相においてのみ、彩度を調整する

A11y対応AAA準拠の比率を維持しようとすると下記は固定事項

例えばブランドカラーが鮮かなブルーの場合、文字色としてそのまま使うのには上記理由から適切でない。

では、ブランドカラー(印象用途)とテキストカラー(文字用途 / 可読性)として、基準色と役割(文字、背景、線)の2軸で考えるのはどうだろうか。これは後述する理由によってボツになる。結論だけ知りたい場合は「改善案：基準色のパレットを増やす」へGO!

グレーについては、基準色として用意するものの、文字なのか背景なのかによって必要とされる灰色は限定されるはずなので(ダークモードなしの場合)適切な数と用途が叶っているかを考える

ルールの基準となる式を、文字色用、背景用で追加し、さらに上限と下限を設定したカタチになる。

darken($some-color,13%) //B40以下は不採用
lighten($some-color,13%) //B20以上は不採用

…でもコレ、分かりづらいねんな…。

上記の例はルールが複雑で覚えづらいので、あまり良い設計ではないように思える。そこで色を増やしていくのではなく、基準色を10段階くらいに増やして、その中で文字と背景に適切なものをピックアップしていくのが良いだろう。

GrayとSmokeはBlightnessの数値加算のルールが異なるので別のカラー軸と定義した。
Grayは+10加算なのに対してSmokeは90開始の+3加算。

以前はB80を複製して「text01」というカラーパレットを増やしていたが、増えるとそれだけ把握できなくなるので、命名時に「名称」と、あれば「役割」を追加することにした。

Figma上であればカラー選択時に「text」などと入力してもらえれば、文字色だけのフィルタリングが可能になるので、十分と考えたからだ。

コードへの実装時にはこのラベルをもとに$text-color-01 = $B10みたいな事になるのを想定している。

できれば同じ役割を持つ色たち(Feedbackの成否用の色など)は、色相以外は同じ彩度、明度にしたいけれど波長の問題のせいか、色ごとに同様にしてもあんまり見た目で差がつかなかったりキレイにいかない。赤は明度彩度浅くても見やすいし逆に青は下げすぎると青である意味がないくらい暗くなる。

なんとなくだけど、モニター上の色知覚が暗所視の視感度レベルに似ている気がするけど詳しくは分からん…。青とグレーだけやたら明度差を知覚できる理由については今度気が向いたら調べます。

実際にコンポーネントを追加すると不思議なことがおこる。文字と背景色を使うばかりで基準色の用途がほぼゼロになる。色だけで情報を伝えることは、アクセシブルではないので印象設計用途の色は出番がないのだ。

画像はブランドカラーとしての赤と黄色を無理矢理使った例。上から二つ目、三つ目のアイコンは基準色を採用したので文字色に比べて鮮やか。しかし正直どうでもいい用途である。

では基準色の定義が不要かと言うとそうではないと考えている。基準色の定義がなければ文字色、背景色は作れないからだ。

問題はA11yの制約がある中で、Feedback Colorに対してどのようにプロダクトのパーソナリティを表現するかだろう。