アクセシブルなパレット: 色彩システムでHSLの使用をやめる

 (wildbit.com)
2 ポイント 投稿者 GN⁺ 2023-08-30 | 1件のコメント | WhatsAppで共有
  • Postmarkの既存カラーパレットは、色ごとの見かけの明るさにばらつきがあり、段階間のコントラスト比を予測しにくかったため、WCAG推奨コントラストを毎回手動で確認する必要があった
  • HSL/HSVはRGBを単純変換したモデルであり、人間の明るさ・彩度知覚を反映できないため、単一の色の選択には使えても、色彩システムの構築には不向き
  • CIELABとLChは、数値の変化が知覚される変化により近くなるよう設計された知覚的に均一な色空間であり、同じ明度レベルのカラースケールをより一貫して作成できる
  • Accessible PaletteはLChをベースに、明度、コントラスト比、Hue補正、既存ブランドカラーの反映を調整して一貫したパレットを生成するアプリ
  • WCAG 2.1のコントラスト比とWCAG 3 Working DraftのAPCAをあわせて確認することで、現在の指針への準拠と将来のコントラストアルゴリズムの変化の両方に対応しやすくなる

Postmark色彩システムの問題

  • 既存のPostmarkパレットには2つの問題があった
    • 青や赤は黄や緑よりはるかに暗く見えるなど、見かけの明るさに一貫性がなかった
    • 色のバリエーション間のコントラスト比を予測しにくく、色の組み合わせがWCAGの推奨を満たしているかを簡単に判断できなかった
  • 色の組み合わせを選ぶたびにコントラスト比を手動で確認する必要があり、実際には確認されない可能性も高かった
  • 原因はHSLカラーモデル自体の限界と、より良い代替手段をデザインツールが十分にサポートしていない状況にあった

HSLが色彩システムに向かない理由

  • RGBは画面の動作方法を反映したモデルであり、人が色を選びやすい直感的なモデルではない
  • HSLとHSV/HSBは、1970年代にRGBを人が考える色のあり方に近い形で表現しようとして作られた代替モデル
    • HSLはHue、Saturation、Lightnessを意味する
    • HSV/HSBはHue、Saturation、ValueまたはBrightnessを意味する
  • 当時はより精緻なモデルの計算コストが高かったため、HSLとHSVは計算速度のために知覚的な正確さを犠牲にしていた
  • その結果、HSLとHSVはRGBを数学的に扱いやすく変換したにすぎず、人が感じる明るさや彩度を正しく反映できない
  • たとえばHSLでSaturation 100、Lightness 50に揃えたカラースケールは、モデル上では同じ明るさだが、実際には青 #00F が黄 #FF0 やシアン #0FF よりはるかに暗く見える
  • HSLでは完全彩度の色がRGBの最大値にマッピングされ、Lightness 50のHue円周上に置かれ、Lightness 0と100はそれぞれ黒と白に対応する
    • より明るい、または暗いバリエーションは、白または黒と「混ざる」形で作られる
    • 中央の縦軸はSaturation 0の中立色、つまりグレーの範囲

CIELABとLCh

  • HSLとHSVが定式化された時期には、すでにより良い代替であるCIELAB色空間が存在していた
  • International Commission on Illumination、すなわちCIEは、1976年にCIELABまたはL*a* b*色空間を定義した
  • CIELABは、数値の変化が似た知覚上の色の変化に対応するよう設計された知覚的に均一な色空間
    • RGBと異なり、見える色の全範囲を包含するよう設計されている
    • 明度を表すL*成分は、人間の明るさ知覚に近いよう調整されている
  • CIELABは3つの軸で構成される
    • L*値は0で黒、100で白を定義する
    • a*軸は緑-赤の反対色軸で、負の値は緑、正の値は赤方向を示す
    • b*軸は青-黄の反対色軸で、負の値は青、正の値は黄方向を示す
  • CIELCh、LCh、またはLch(ab)はCIELABの円筒表現
    • a*とb*の代わりにChromaとHue角を使う
    • Lightnessはそのまま維持される
  • LChのHue角はHSLのHueに似ているが同一ではない
    • HSL/HSVでは、赤、緑、青の3つの加法原色がH=0、120、240°に置かれる
    • LChでは、赤、黄、緑、青がh=0、90、180、270°に置かれる
  • HCLまたはLCh(uv)という類似色空間もあり、LCh(ab)と異なりChromaが0から100まで均一なスケールを持つ

LChでカラースケールを作る方法

  • LChはHSL/HSVと異なり円筒には収まるが、円筒を完全には満たさない
  • Lightness、Chroma、Hueの一部の組み合わせは存在しえない色を作る
    • たとえば暗くて彩度の高い黄色は存在しない
  • 明度スケールで黒や白に近づくほど、人が識別できる色の数は減る
  • 実際の画面では見える色の全範囲を表示できない
    • sRGB色域は一般的な画面を表し、LCh色空間の約1/3しか含まない
    • CSSでも少なくとも現時点ではこの範囲に制限される
  • HSLでSaturation 100、Lightness 50のカラースケールをLCh基準で見ると、黄色が最も明るく、青が最も暗い
    • 緑は青のほぼ3倍明るく、赤の約2倍明るい
  • LChで同じLightnessレベルになるようスケールを作り直すと、色ごとの明るさが視覚的に一貫する
    • Chromaが異なるため、色によっては他より彩度が高くなることがある
    • 通知色や警告色は基本のテキスト色より彩度を高くしたい場合があり、色彩システムではこうした差が有用になりうる
  • Chromaまでより一貫して揃えると、制限されたsRGB色空間の中でも滑らかなスケールを作れる

デザインツールの限界とAccessible Palette

  • 現在、Figma、Sketch、Adobe XDはCIELABやLChをサポートしていない
  • FigmaにはLCH color pickerとChromaticプラグインがあるが、柔軟な色彩システムを作るには十分ではなかった
  • 必要なツールは3つの条件を満たす必要があった
    • 色のバリエーションを作る際に明度の一貫性を維持する
    • 段階間のコントラスト比を制御できる
    • 既存のブランドカラーを取り込めるだけの柔軟性がある
  • LChのサポートが優れたChroma.jsライブラリを見つけた後、コードで新しいパレットを生成する簡単なツールを作った
  • 社内利用と一部の知人への共有を経て、このツールはAccessible Paletteアプリとして公開された
  • Accessible Paletteは、色レベル全体で一貫した明るさと予測可能なコントラスト比を持つ色彩システムを作るためのアプリ

Accessible Paletteの動作方法

  • 開始色を調整するか、既存デザインの色を貼り付けると、ツールはその色のChromaとHueを使って複数のLightness段階のスケールを計算する
  • Lightnessは完全にカスタマイズ可能で、明るいパレットにも暗いパレットにも使える
    • 既存のブランドカラーを含められるよう細かく調整できる
    • Postmarkでは既存パレットで最も多く使われていた黄 #FFDE00、青 #007DCC、緑 #4FC47F を残そうとした
    • これらの色のLightness値88.6、75.2、50.6を、それぞれレベル200、400、600の明るさとして使用した
  • コントラスト比はLightnessに応じて変化し、各レベルについてWCAG 2.1推奨方式とWCAG 3.0 Working Draftの新アルゴリズムの両方で計算する
    • デフォルトではすべての色のコントラストは白背景を基準に測定される
    • 任意のカラースウォッチを選択して、その色を基準にコントラスト比を測定できる
  • レベルはRGBまたはCIELAB色空間を使って生成できる
    • 場合によって結果が異なるため、試してみる価値がある
    • Postmarkの色体系では、CIELABを使うと明るい赤の紫がかった傾向は減ったが、青では紫がかった傾向が増えた
  • 一部の色では全範囲にわたってHue補正が必要になることがある
    • 明るい黄色は暗くなるにつれて緑がかった傾向が出る
    • これを少しオレンジ寄りにするために、負のHue補正を使う
  • アプリは使用中にURLを更新して変更内容を保存する
    • チームと共有したり、FigmaライブラリやCSSカラー変数ファイルに追加して後から参照したりできる
  • 例のパレットとして、新しいPostmark color palette、Google’s Material Design、TailwindCSSベースのパレットがある
    • これらの例は元を正確に複製したものではなく、元の色と明度段階から着想を得た代替案

コントラスト比の計算とWCAG

  • Accessible Paletteが2種類のコントラスト比を表示するのは、WCAG 2.1方式に限界があるため
  • WCAG 2.1は前景色の輝度を背景色の輝度で割ってコントラスト比を計算する
  • この式は線形な応答を返すが、人は明るい色同士のコントラストを暗い色同士よりも高く知覚する
  • 実際の例では、WCAG 2.1の推奨を満たすサンプルのほうが、「不十分」なコントラスト比と表示されたサンプルより読みにくいことがある
  • W3Cはこの問題を認識しており、Andrew Somersは2019年に公開議論を始めた
  • Andrew Somersが提案した新しい作業アルゴリズムはWCAG 3 Working Draftの一部となり、APCA Contrast Calculatorも作られた
  • APCAはAdvanced Perceptual Contrast Algorithmの略で、知覚的により正確で、フォントサイズや太さも考慮する
  • Accessible PaletteはAPCAを使い、可読なテキストの最低推奨レベルとしてスコア60を用いる
    • これはWCAG 2.1の従来の4.5:1コントラスト比推奨に近い基準
  • WCAG 2.1のコントラスト比が完全に無意味というわけではない
    • 中間的な色域では依然としてかなり正確
    • ただし全体としては新しいアルゴリズムが大きな改善
  • WCAG 3方式はまだWorking Draftであり、時間とともに変わる可能性がある
  • 現在の指針への準拠と将来の変化への対応の両方を考えるなら、両ガイドラインを意識して色彩システムを作るのがよい

関連記事

1件のコメント

 
GN⁺ 2023-08-30
Hacker Newsの意見

  • 一般的なディスプレイや印刷システムでは、彩度の高い赤と青は緑より実際には暗いと見るべきです。
    色空間によって正確な式は変わりますが、Grayscale = 0.299R + 0.587G + 0.114Bがよく引用されます。この場合、最も明るい純粋な赤は約30%、純粋な青は11%の明るさなので、ほとんどの場合、明るい赤というのは矛盾に近いものです。
    こうした色を使うことはできますが、常に暗く見えざるを得ません。単にコントラスト規則だけを適用すればアクセシビリティは満たせても、見た目の良い結果まで望むなら、記事で扱っている手法のほうがはるかに有利です。
    https://en.wikipedia.org/wiki/Anaglyph_3D のような赤青立体写真を作るときも、木や草は緑ですが、実際には赤成分が多くチャンネルのバランスが良いため、立体感と色の両方がうまく出ます。
    参考: https://www.dynamsoft.com/blog/insights/image-processing/ima...

    • NTSC放送セーフレンジの時代と、赤をやたら好むクライアントたちを思い出します。
      美しい赤いアートワークがテレビではまったく美しく見えないと説明するのはいつも大変で、放送用ならなおさらでした。
      放送用でなくても、規格外の赤は数フレーム後まで残って見えたり、首を切られたようににじんで見えたりすることがありました。
    • ここには間違っている内容がいくつもあります。
      返信を読んでいたなら、返事をくれればいくつかさらに明確に説明してみます。

  • 実際、WCAG 2.1の推奨基準を満たすサンプルのほうが、「不十分な」コントラスト比のサンプルより読みにくいという点が、ずっと以前から気になっていました。
    「アクセシビリティガイドライン」の公式がむしろ逆効果を生むのに、なぜ標準化されたのか不思議です。

    • コントラストのアクセシビリティで最も広く使われているアルゴリズムとガイドラインに、査読済みの根拠がない点は少し残念です。
      2.1もそうですし、次期標準も同様なので、これほど影響の大きい領域なら、業界がもっと厳密な研究を支援してほしいと思います。
    • W3C/WCAGの中でコントラスト判定式を変えようとする動きがあったと記憶しています。
      もしかすると、単にそうした要望があっただけで、まだ正式には採用されていないのかもしれません。

  • このテーマで見た最高の記事は https://www.handprint.com/HP/WCL/color1.html です。
    とてつもなく長い記事なので、1日費やす覚悟が必要です。
    意外かもしれませんが、ClickHouseでログの色をきれいに付けるときにも、この記事のいくつかのアイデアを使っています: https://github.com/ClickHouse/ClickHouse/blob/master/base/ba...

    • このANSI色をRGBに変換する具体的な方法は見つけにくく、実際には色のリクエストにすぎず、ターミナル設定に依存しているように見えます。
      コードで設定している各メッセージ種別について、期待しているRGB値が何なのか共有してもらえるのか気になります。

  • FigmaのConfigカンファレンスでEugeneに会いましたが、デザイナーたちに同じような実践的なヒントをたくさん教えてくれて、本当に親切で、デザインとアクセシビリティに真剣な人でした。
    この記事で特に称賛したいのはAPCAで、WCAG 2の色コントラストアルゴリズムを継承する可能性が高いものです。
    Figma内部のアクセシビリティ刷新でもAPCAを使い、そのおかげで最終結果はずっと良くなりました。
    EugeneはWCAG 2が失敗する例をうまく示していますが、実際に私たちもそうしたケースに何度も直面しました。
    核心的な助言は、色を正しく合わせるのは本当に難しいということです。
    ツールは役に立ちますが、どこかの時点では自分の目を信じる必要があります。
    結局、こうしたツールは目が色を見る仕組みを数学的に近似しているだけで、最終的な基準はアルゴリズムではなく人間の目なのです。
    ツールやアルゴリズムが合わない結果を出す地点では、調整するか基本に立ち返るほうがよいでしょう。

    • Figma内部のアクセシビリティ刷新にAPCAを使ったという部分を、もう少し詳しく説明してもらえるのか気になります。
      APCAだけを使い、WCAG 2の色コントラストアルゴリズムがコントラスト不足として表示する内容は無視した、という意味なのか知りたいです。
    • 赤緑色覚異常ですが、Figmaのデフォルトのアクセシビリティが十分に良いので、別途アクセシビリティ調整を考えたことはありません。
      よくできています。

  • HCTも紹介しておきたい
    Material Youを実現するために作られた色空間で、ここで述べた明度の測定値と最新の色彩科学に基づく色空間を組み合わせたもの
    LAB/LCHは1976年に登場したもの
    デザインをより直感的にしてくれる。Tの差が40ならボタンに対するWCAG基準を満たし、50ならテキスト基準を満たす、と知っていればよい

    • 興味深い
      HCTがhttps://www.hsluv.org/comparison/とどう比較されるのか気になる
      HCTと同じように、こちらではLの差でコントラスト色を選びやすくなる
      同じ文脈で、https://www.myndex.com/APCA/と、それが標準になったときのアプローチについても考えを聞きたい
      2色間のコントラスト値は、どちらの色が前景でどちらが背景かによって変わるので、今ではTの差だけを比較するだけでは十分ではなさそう
    • HCTを学ぶのに良い資料があるのか気になる
      たとえば、アプリケーションに赤、黄、青、オレンジ、緑、紫、つまり三原色と3つの補色に相当する6色が必要だとしよう
      正確にどの色になるかはそれほど重要ではないが、その6色である程度識別でき、明るさ、場合によっては彩度まで似た感じにそろえたいなら、どうすればよいのだろう
      黄色は非常に明るく、青は非常に暗いので、正確な答えはなく近似値にたどり着く必要がありそう
      こうしたことを学べるツールやチュートリアルがあるのか気になる
    • 公開仕様がどこかにあるのか気になる
      見つけたのはGitHubのmaterial-color-utilitiesコードだけだった
      コードを見ると計算はOkLabよりはるかに複雑に見え、特にHCTからRGBへ向かう方向はなおさらそう見える

  • 記事でoklab/oklchを抜かしているだけでなく、Web/CSSがsRGBしかサポートしていないという主張も誤り
    CSSのcolor()関数は複数の色空間をサポートしている

    • 著者です
      この記事は2年前に公開したもので、ツールの作業を始めた時点ではOkLCHの仕様もまだ出ていなかった
      今ならLCHではなくOkLCHを選ぶだろう。LCHのいくつかの問題を解決しているから
    • CSS Color Module Level 4はまだ勧告候補の草案段階
      ここでいう「サポート」は、より正確には「Microsoft Edge(chromium)とPale Moon(goanna)を除いてサポート」に近い
      https://test.csswg.org/harness/results/css-color-4_dev/group...
    • oklabと複数のLAB系色空間を自分で使ってみたが、Oklabは単純な計算で切り出して使うには素晴らしい
    • Oklchの上に作られた色モデルもある
      ただし明度の代わりにAPCA、つまりWCAG 3のコントラスト比を使う: https://github.com/antiflasher/apcach

  • oklabはLChより良い代替案かもしれない
    https://bottosson.github.io/posts/oklab/

    • 初期の前提からかなり外れている面がある
      明度チャンネルが他のすべての色空間と逆になっており、LはLCHやLABのLとは何の関係もない
      成功がかえって知的な貧困を招いた面もある
      最初のブログ記事には修正すべき内容が非常に多く、CAM16 UCSを使ったグラデーションで正確性を主張し始める地点から論理が大きくずれている
    • このプレイグラウンドは、LChとOKLABを含む16個の色空間を驚くほどよく可視化してくれる: https://color-playground.ardov.me/spaces-3d
    • 完璧ではないが、いくつかの状況で色補間にoklabとoklchを使ってきており、RGBやHSLで補間するより結果は視覚的にはるかに満足できるものだった
    • 自分のサイトでOkLabを満足して使っているが、以前にCIELABを使っていたカラーパレットより目にずっと優しい

  • CIELABの数値が知覚変化に基づくなら、アクセシビリティとはどう相互作用するのか気になる
    こうした知覚の公式が標準的な視力を基準に作られている可能性を心配すべきだろうか
    色覚異常の種類によって変わり得るのか、それともそういう問題ではないのかも気になる
    チャートをできるだけアクセシブルにしようとしているが、色についてはまったく学んだことがないので助言に従っているだけで、自分で導き出すことはできない
    なので、愚かな質問である可能性も十分にある

    • この方面の作業をしたことがある
      コントラストは非線形に変化する
      シミュレーションはかなり簡単に適用でき、Machadoらのシミュレーションは行列変換にすぎない

  • この記事では説明を下の方に置いているが、WCAG 3草案標準の読みやすいコントラストテストであるAPCA Contrastは、WCAG 2.1のコントラスト比より一部の色に対してはるかに公平
    知覚コントラストの背後にある色理論を読みやすく解説した記事: https://www.smashingmagazine.com/2022/09/realities-myths-con...
    APCAを簡潔に説明した記事: https://typefully.com/u/DanHollick/t/sle13GMW2Brp

    • APCAはうまく機能するが、ライセンスが非常に奇妙で制限的
      何かに使う前にその部分を詳しく確認し、本当に使えるか判断したほうがよい

  • コードはどこにあるのか
    Webフォームではなく、どんなソフトウェアでも使えるアルゴリズムが必要