APCA何もわからない

[Accessible Perceptual Contrast Algorithm（APCA）](https://github.com/Myndex/SAPC-APCA)は[WCAG 3.0](https://www.w3.org/TR/wcag-3.0/)において、コントラスト比に関する新しい基準として提唱されているアルゴリズムです。
つたない英語力でその[コンセプトや概略](https://git.apcacontrast.com/documentation/WhyAPCA)を読み込んでみて、なんとなく以下のように理解しました。

- コントラストというのは単純な背景色と前景色の差分だけで判断できるものではない。錯覚とかあるからね。フォントのサイズやウェイト、行間、コンテキストなどから総合的に知覚されるものだ、ということらしい。
- 文字の読みやすさに影響するコントラストの知覚に関しては、フォントサイズやウェイトなどからなる[空間周波数](https://ja.wikipedia.org/wiki/%E7%A9%BA%E9%96%93%E5%91%A8%E6%B3%A2%E6%95%B0)の影響をとくに受ける。
- 空間周波数はWikipediaによると「空間的な周期をもつ構造の性質」とのこと、なんとなく一定の二次平面上のパターンの複雑さってことかなぁ？このパターンの刺激が一定程度を超えると知覚できるようになるってことらしい。これは個人差が当然ある。
- それらを踏まえた検証の結果作られた、文字色と背景色でコントラスト値Lightness contrast (Lc)を計算するアルゴリズムが、このAPCA。そのLcの値に対して、空間周波数の影響を鑑みてフォントサイズとウェイトの推奨値が決まる。
- そういうことでAPCAでは、コントラストの基準は背景色とテキスト色に、フォントサイズとウェイトを加えたテーブル状の複雑なものになる。

ここまでは、まぁ直感的にもわかる気がする。空間周波数はフォントサイズやウェイトだけでなく、余白や行間、縦横比などにも影響されるということで、つまり色だけでなくフォントそのものもコントラストの知覚、ひいては読みやすさに影響するということだな。

ここまでくると、[APCA Contrast Calculator](https://www.myndex.com/APCA/)でやっていることがわかってくるはず。
色を変更すると、Lcとともに適合するフォントサイズとウェイトのサンプルがぐりぐり変わっていく。
![APCA Contrast CalculatorのWebページスナップショット](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2827/846a255b-94b4-2ed9-ed2a-0019fb5ae86d.png)

ここで一つ問題となるのが、欧文書体のフォントサイズとx-heightの関係。欧文書体では、フォントの意匠として小文字のxのサイズがフォントの高さのうちどの程度の比率かというx-heightという値がある。おなじフォントサイズでもx-heightが小さいと実効的な文字サイズは全体的に小さくなり、それは当然空間周波数に影響する。
そのため、このアルゴリズムではx-heightのモデルサイズとして0.5(0.52以上が望ましい)、ウェイトもふくめリファレンスフォントとしてHelveticaやArialを参照している、とされている。（[APCA Contrast Calculator](https://www.myndex.com/APCA/)の「Notes on Font Size & Weight」の項目）
つまり、現状のアルゴリズムで計算しているLcとフォントサイズ・ウェイトの基準は、欧文書体の特定のx-height値以上であることが前提である。

やっとここまで理解が進んだ。
以上を踏まえ、では日本語などCJKなフォントでは、この基準は使えるの？というのが今日のお悩みです。うーん、どうなんだろうと思いつつAPCAのリファレンスフォントであるArialとNotoSansJPで同じ100pxの文字列を並べてみて、観察したのが以下の図です。

![Arial RegularとNotoSansJP Regularでフォントサイズと実効的な文字サイズの比較をおこなった図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2827/8e2402d2-bd26-f90d-d424-39b7909c4d47.png)

いくつかわかるのは

- 同じ100pxのフォントサイズでも、Arialでは100pxの正方形の領域を使い切っておらず実際の文章中に多い小文字は高さで50%程度、横幅はiなどごく小さい。実効的な文字サイズは「フォントサイズ」より大幅に小さい。
- 対してNotoSansでは、かな・カナや漢字はおおむね正方形の領域を広く使っていて、グリフとしてもおおむね等幅。フォントサイズと実効的な文字サイズの差が小さい。
- 小文字の上部に余白ができる分、同じフォントサイズと行間であれば欧文の方が行間が空いているように見える。（日本語のline-heightは欧文より大きめにしたくなる原因だな）
- アルファベットは画数的にEの４が最大なのに対して、漢字の画数は非常に多くなることがあり、線密度が非常に高くなることがある。
- リアルな日本語の場合は、アルファベットが混じることもままある。x-heightが大きめなフォントと合わせるなり、調整されている感じ。

以上を踏まえて、私の感想ですが。
APCAの基準となっているフォントサイズは、欧文のリファレンスフォントより和文書体のほうが実効的な文字のサイズが大きいので、そのまま日本語に当てはめたとしても視認性として大きく劣るということはないのではないかな。あと、漢字は表意文字であるので、より熟語などのコンテキスト依存で判別しているんじゃないかと仮説を持ちました。
和文の視認性の問題としては、魚シリーズなど同じような漢字で画数が多く、コンテキストにも頼れない場合に判別が難しい、といった問題がありそう。

実際のところは、元となった論文とかリサーチと同じことを和文書体でもやってみる必要があるのだろうと思うけど、ちょっと今日のところはおなかいっぱいなのでここまでで。

APCAの適合レベルについても、まだ読み込んでいかないと全然わからない。
「ちょっとわかる」まで道はまだ遠そう。

## おまけ

以下は、[おぢん](https://twitter.com/works014)さんにいただいた、主要な和文書体について、ひらがな、かたかな、漢字がどのようにデザインされているかの比較。（黒：漢字、赤：ひらがな、青：カタカナ）
フォントにもよるが、若干ひらがなが小さく、カタカナはさらに小さめに作られている感じ。
![和文書体の文字種ごとの比較表（１）](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2827/948a75b9-0785-b64b-4127-d2a6dd8b99b9.png)
![和文書体の文字種ごとの比較表（２）](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2827/142fd2e5-23ea-b6fb-9d67-9e1094e6340f.png)

ラグランパンチよ・・・。