PUAアイコンフォントのアクセシビリティ
UnicodeのPUA（Private Use Area：私用領域）を使ったアイコンフォント（FontAwesomeなど）には、いくつかアクセシビリティ上の問題があります。この記事では、問題点、対処療法的な解決方法、本質的な解決方法（となりうるもの）について簡単にみていきます。
UnicodeのPUAは私用領域、私的な利用のために使って良い文字（コードポイント）のための領域です。私用領域でない定義された文字（コードポイント）はどの環境でも一意に解釈されるのに対して、PUAの文字（コードポイント）は人/フォント/システムによって解釈が異なります。例えば、PUAでない「U+3042」はどの環境でも「ひらがなのあ」に対応しているものとして解釈されますが、PUAの範囲内はそうではありません。
PUAアイコンフォントの問題
PUAアイコンフォントには、いくつかアクセシビリティ上の問題があります。
- 1 スクリーン・リーダーなどにPUAを無視させるのが難しい
- 2 （代替テキストが設定されていない場合）スクリーン・リーダーなどが情報を読み上げられない
- 3 アイコンフォントが使われない環境で、視覚的に情報が伝わらない
1はCSSの擬似要素で追加されたPUAをスクリーン・リーダーが読み上げる、というものです。この問題の解決のためにaria-hidden="true"を使う方法が提案されていますが、その場合でもスクリーン・リーダーがPUAを読み上げる場合があります*1。
2の解決は簡単です。いわゆるスクリーン・リーダー対策と呼ばれるテクニックを使えば、スクリーン・リーダーにだけ特定の情報を読み上げさせることができます。例えば、HTMLに代替テキストを書いて視覚的に隠すとか、title属性を指定するとか、aria-label属性を指定するとか、といった方法があるでしょう。
3.は、いくつかの環境ではPUAがアイコンのグリフで表示されないため、情報を取得できないという問題です。例えば次のような環境です。
- Webフォントをサポートしていない/無効にした場合
- アイコンフォントのダウンロードに失敗したした場合
- ユーザー指定のフォントが優先して使われる場合
ユーザー指定のフォントが優先される場合には、アイコンはアイコンとして表示されません。このため、特にアイコンだけで情報を伝えている場合（隣りにテキストがない場合、など）、ページが何を伝えようとしているのかわりません。
例えば、GitHubはアイコンフォントを多用しており、かつアイコンしか設定されていないボタンも多くあるため、マウスを重ねてツールチップが出てこないと何をするボタンなのかわかりません。
また、PUAはフォントあるいはシステムによってどんな表示をされるのか、予想ができません。ユーザーが使っているフォントにグリフがない場合、多くのブラウザーは四角や四角の中にコードポイントが表示された形で表示しますが、ユーザーが使っているフォントにグリフがある場合には、制作者が想定していたのとは異なる意味をもつグリフが表示される場合があります。Bulletproof Accessible Icon Fontsには、そのような残念な表示になった例がいくつか出ています。四角の中に宇宙人のような顔が表示されていたり、ハングルが表示されていたりと、フォントによって、制作者の意図とかけはなれた情報が伝わってしまいます。
脱線しますが、「ユニコード戦記」には「香港政府がカントニーズに特有の人名用漢字をPUAに割り当てて、行政用に使い始め」、「お馬鹿なことに、得々としてこれを国際ユニコード会議の場で発表する輩」がいたという話がでてきますが、PUAアイコンフォントがやっていることはそれと同じです。
PUAは、たとえそれがある国や地域に限定されるものであったとしても、セミパブリックな用途には絶対に使うべきではない。私用領域はシステム内部での臨時の使い捨ての領域であって、外部から見える符号位置としては限りなく使用禁止に近いものと考えるべきである。
と同書には書かれています。
いずれにせよ、「スクリーン・リーダー対応だけをすればコンテンツがアクセシブルになる」というわけではないため、制作者は3も考えなくてはなりません。そして、3の解決は1や2に比べると難しいです。
Adobe Blankを使う方法
The Paciello GroupがCSUN 2014で行った発表では、PUAアイコンフォントを使ったうえで、
- 代替となるテキストをHTMLに記述する
- 代替となるテキストはAdobe Blankを使って視覚的に見えなくする
という方法が紹介されていました。Adobe Blankはすべての文字が視覚的には見えないフォントです。
- Lessons Learned: Accessibility Theory vs. Implementation Reality セッション情報
- Lessons Learned: Accessibility Theory vs. Implementation Reality スライドと例
- Adobe Blank
この方法を使うと、3.の視覚的な問題も部分的に解決可能です。というのも、ユーザーのフォント設定が優先されている場合には、
- アイコンフォントが指定されている部分はそのまま表示される
- Adobe Blankが指定されている部分もそのまま表示される
ため、代替となるテキストが画面上に表示されるからです。
ただし、Paciello Groupが発表した方法をそのまま使うと、次のような問題が起こります。
- Adobe Blankが読み込まれた/使われているが、アイコンフォントが読み込まれていない/使われていない場合に、代替となるテキストが視覚的に見えない
この場合、画面上にはPUAだけが表示され、代替テキストは表示されません。アイコンフォントが読み込まれ、かつ、使われていることを確認する方法があれば、アイコンフォントが使われていることを確認できた段階で代替テキストにAdobe Blankを適用することで、この問題は解決できるでしょう。
リガチャーアイコンフォント
とはいえ、こんなに頑張らないとアクセシブルにできない技術を使うのは、そもそもどうなのでしょう。シンボルフォント — それは、新しい画像形式では「PUAを使う方法」はヒトの進化における類人猿（？）に例えられています（時間軸では類人猿（？）が現在ということになっていますが…）。
アイコンフォントにはPUAを使わないものもあります。例えば、Ligature Symbolsは、リガチャー（合字）を使ったアイコンフォントです。
このフォントでは「print」や「upload」といった単語に対してアイコンが指定されています。保存用のアイコンを表示する部分には、次のようなHTMLが記述されています。
<td class="lsf symbol">save</td>
Ligature Symbolsでは、代替テキストを別途用意する必要はありませんし、フォントの読み込みに失敗したり、ユーザーのフォント指定が優先される場合のことを特別に考える必要はありません。HTMLにテキストが書かれているので、フォントが読み込まれない/使われない場合には単にテキストが表示されるからです。
リガチャーを使ったフォントはSVGフォントであれば手で作成・調整できます（glyph要素のunicode属性を弄れば良い）。が、SVGフォントはSVG 2では廃止されるので、別の方法を使って効率的に作成・調整する方法を考えるべきでしょう。Ligature Symbolsであればカスタマイズ方法も紹介されていますが、私もフォントの作成方法に明るくないので、フォントもくもく会でもう少し考えを深めてみたいないと思っています。
