こんにちは、デザイナーの
id:ymrlです。今年は書道大会を提案したり、ヒットソングの作詞（？）をやったりしました。あとWebアクセシビリティの本を出版しました。充実した1年でした。
この記事は freee Developers Advent Calendar の18日目です。ちなみにデザイナーのアドベントカレンダー もあって、そちらでは2日目に見よう見まねでデザインしてるという話も書きました。
freeeではアクセシビリティー・ガイドライン を策定して、チェックリストを運用して、プロダクトのアクセシビリティが一定以上に担保された状態でリリースされることを目指しています。現場で使いやすく・わかりやすいものを目指して作って運用してきているわけですが、しかし、実際にやってみると「これってOKにしていいんだっけ」とか「これ本当にNGなの？」というものも出てきます。そういうものはSlackで相談を受けるようにしています。
その中には「現状のガイドラインやチェックリストがわかりづらいのでは」と思えるものも多くて、それらの改善の足がかりにしています。あるいは、社内デザインシステムであるvibesのコンポーネントに置き換えたり、あるいはvibesのコンポーネントを改善することで解消するものもありました。単純にチェックの詳しい手順を説明すれば良いものは、社内で運用している手順書に反映したりもしていました。
その一方で、ガイドラインというほどには一般的でなく、あるいは社外に向けて「絶対にこれならヨシ」と言えるような、微妙なボーダーライン上にあるような判断も増えてきました。ガイドラインやチェックリストには白黒ハッキリした書き方をしたいし、手順書はなるべくシンプルに読みやすく保ちたいので細かいことをやたらとたくさん書きたくないし、でもどこかには書いておかないと、ガイドラインやチェックリストを作る側も使う側も困るんじゃないか……という状態になっていました。
判断事例集ドキュメントを作ってる
ということで、 「ボーダーライン上だったり、細かすぎたりするものの判断事例や解説を、とりあえず置いておく場所」として「アクセシビリティ判断事例集」という名前で社内Google Docsに書いています。
相談されたり、あるいは社内で実施されたアクセシビリティチェックの中で観測された問題などについて1、以下のフォーマットでまとめています。
- 困ったこと
- 結論
- 解説
困ったことに対する結論を最初に書くことで、現場で困ったことへの対応がすぐできるようにしつつ、より詳しく知りたい・似たような課題に応用したい・判断の根拠を知りたい場合のために解説についても充実させています。
あえて公開せず社内ドキュメントにしたことで、社外からの目を気にせずに具体的な方針を書けることは大きなメリットでした。freeeアクセシビリティー・ガイドラインは公開して社外の方からも使ってもらえるよう、汎用的な書き方にしています。社内に閉じたドキュメントとすることで、「いろんな選択肢があるけど、freeeでは、この製品ではこの方針でやっています」という、より具体的なプロダクトの方針に関する言及がしやすくなりました。
また、「とりあえず結論だけ書いておく」のような運用もしやすくなり、それだけでも「相談のログ」のようなフロー情報ではなく、ストック情報の蓄積される場所が生まれ、まずは見にいくことができる場所となっています。
判断事例の具体例
せっかくなので、いくつか、アクセシビリティ判断事例集に載せているものの具体例を、すこし freee Developers Hub 向けに整形しつつ、紹介してみます。 （元がGoogle Docsで箇条書きなので、そのままブログの記事にすると読みづらいんですよね）
ページタイトルはどう指定すればいい？
この例では、実際のプロダクトでのタイトルのフォーマットや、タイトルをつけるための考え方を「結論」で示しつつ、「そもそもページタイトルって何なの？」という疑問について解説で答え、画面ごとに別々のタイトルが付けられることの利点を説明しています。
困ったこと
0631（デザイン）、0651（プロダクト）で求められている「ページ・タイトル」について、何を指定するべき？どういうときにNGになる？
結論
- プロダクト内で一貫したフォーマットにしてください。
- freee会計の場合は、トップページのみ「freee会計」、それ以外の画面は「×××× | freee会計」の形式
- 機能のトップ画面とサブ画面のように、画面の見た目や構成が異なる場合は、違うタイトルになるようにしてください
- 「×××の一覧」と「×××の詳細」のように、すくなくともどんな画面が表示されていそうかわかるようにする
- 個別のデータが区別できるレベルまで細かく書かなくてもOK
- 経費精算のタイトルを書くのではなく「経費精算の詳細」でOK（タイトルが書かれても経費精算であることがわかるとは限らないし、「経費精算であること」が伝われば OK。一覧→詳細の移動には気付けるようにしておくために「経費精算」と「経費精算の詳細」としておく
解説
ページタイトルは、ブラウザのタブなどに表示されています。
HTMLでは、<title>入金管理レポート | freee会計</title> のようにtitle要素で指定します。
この部分はWebブラウザの表示領域の外になるため、Figma等で画面モックを作ると指定が抜けがちです。lib_patwahを使って記載してください
ページタイトルが適切に指定されることで、以下のような利点があります
- 複数のタブやウインドウを開いている場合に、タブやウインドウを切り替えなくても内容を推測して、目的のものを選ぶことができる
- スクリーンリーダーでは画面の切り替わり時にタイトルが変わると、そのタイトルが読み上げられるため、画面の切り替わりに気付くことができる
下線や枠線のないリンクやボタンを「グレースケールでも使える」としてしまって良いのか？
「リンクの下線を消したい」というのはよく聞かれる要望ですし、実際に下線を消している事例も社内外にあります。「どういうときなら下線がなくても良いのか」、あるいは「どういうときなら下線がないとマズいのか」の社内基準を用意する必要がありました。
困ったこと
- チェックリストの 0031・0051 では、グレースケール表示にしても、リンク箇所がわかることを要求している
- vibesのButtonコンポーネントをtertiaryにしていると、枠線や下線のないリンクまたはボタンとなる
結論
- vibesのButtonコンポーネントについてはOKで良い
- その他のリンクやボタンについては、以下を基準に判断する
- 他のコンポーネントと一定以上の余白をとって配置され、周囲のテキストと意味合いが違うことをユーザーが認識しやすくなっている
- 世間一般やfreee内で広く使われているものと同じ・近しい見た目になっている
- 文中に置かれたリンクについては、下線などを常に表示して、マウスオーバー等をしなくてもリンクだとわかるようにする
解説
複数の視覚的要素を用いた表現で意図しているのは、色を見分けるのが不得意な色覚特性をもつユーザーが、リンクなどの役割をもつ部分を正しく認識できるようになっていることです。
たとえば、文中のインラインなリンクは、下線を消していると、色情報なしではどこがリンクなのかがわかりづらくなります。文中のリンクについては、必ず下線などで、他の部分と区別できるようにする必要があります。
リンクやボタンのほか、データの種類や状態の表現が色のみに頼っている場合は、NGにしてください
- たとえば「お気に入り未登録/登録済み」がアイコンの色の変化のみで表現されている
- たとえば「エラーの発生している項目」を「赤色かどうか」だけで探さなければならない
vibesのButtonコンポーネントに関しては、以下の理由でOKとしました。
- paddingがついていたり、他の文字やUIコンポーネントとある程度のマージンを取って表示されることが多く、他の部分と意味合いの異なる部分であると判断しやすい
- freee内で広く使われている
- （グレースケールだろうとカラー表示だろうと、テキストが黒っぽいので、グレースケールになったせいで判別しにくくなったわけではない）
それ以外の場所も、Buttonコンポーネントと同じように判定できます
- 他のコンポーネントと一定以上の余白をとって配置され、周囲のテキストと意味合いが違うことをユーザーが認識しやすくなっている
- 世間一般やfreee内で広く使われているものと同じ・近しい見た目・使われ方になっている
オレンジ背景に白色で文字を書きたい
freeeのブランドカラーには、OR5 (#fa6414) という、鮮やかで明るいオレンジ色が定義されています。目を引く色なので各所に使いたくなってしまいますが、白色 (#FFFFFF) とのコントラスト比が低く、WCAGの基準としてはテキストに使うのには適していませんでした。
しかしオレンジ色を背景に白色のテキストを書くのは、コントラスト比が示唆するほど見辛くないのでは？という指摘もあり、社内でもやはり基準を作りたいということになりました。
「Orangeの会」というイベントで挙手して喋った件が、実はこれです。
困ったこと
オレンジ背景に白は見やすい気がするが、本当にダメなのか？？
結論
限定的に、WCAG 3.0での導入が検討されている、APCAのBronze Levelの基準を取り入れています。
ランディングページのCTAボタンでは、
- 背景色OR5 (#fa6414)、テキスト#FFFFFF、フォントサイズ16px太字のボタンでOKとした
- 背景色#FFFFFF、テキストOR5 (#fa6414)、フォントサイズ24pxの太字のボタンでOKとした
APCA Bronze Levelによる基準は、まだ国際的なコンセンサスがあるものではないので、適用は限定的にしています。
- 視認性を確保できないことが、ユーザーにとって致命的な場所では、WCAGの基準を使用する
- アプリケーション内部のように、機能的、かつ特定のテキストの識別が困難であると致命的な場所では不安が残るため、vibesではWCAGの基準を用いる
- ランディングページ上の、機能についての説明文は、freeeの機能について調べているユーザーにとって読みやすくあるべきなので、WCAGの基準を用いる
- 広告的な意味合いの強い場所では、視認性が確保できないことによって不利益を被るのはユーザーではなくfreeeなので、APCAの基準を用いても良い
- ランディングページのCTAボタンは、コンバージョンレートの上下により問題を確認しやすいのもあり、採用した
- ランディングページ上の装飾的な文言（たとえば、プラン比較表で特定のプランに「オススメ」とだけ書かれている）であれば、使用して問題ない
上記以外のケースで、APCAの基準を適用したい場合は、Slackで相談してください（事例を収集したい意図もあるので）
解説
WCAGの現在のコントラスト比の基準では、「オレンジ背景に白文字」のような色遣いが、実際の見えやすさに反して低く評価されてしまう、という批判がありました。
そこで、次のWCAGのバージョンであるWCAG 3.0では、APCAというコントラスト基準の採用が検討されています。
現行のWCAGの計算方法では、背景色と前景色を入れ替えてもコントラスト比は変化しませんでした。APCAでは背景色と前景色を入れ替えた場合には評価値が変化し、また文字サイズやフォントの太さによる見やすさ・見づらさも加味された基準となっています
（ここから下は、APCA Contrast Calculator の使い方の解説となるので、割愛します）
freeeアクセシビリティー・ガイドライン のWebサイト上のFAQにも移していきます
こんな感じで、ひとまず社内で書き貯めていっていますが、なかには「これは社外にも公開したほうがいいのでは」というものも出てきます。使う側としても、ガイドラインやチェックリストとなるべく一体になったもので、疑問が解決できたほうがいいはずです。社内の事情から決めている方針についても、「こういう形でこう判断できる」という書かれ方をしていれば、同じような会社さんで同じような判断ができるかもしれません。
そこで、freeeアクセシビリティー・ガイドラインのサイト上に「よくある質問と回答（FAQ）」ページを作成して、公開できるものは公開していくことにしました。まだぜんぜん移せていませんが。
ということで、ひきつづき、アクセシビリティに取り組んでいきます。よろしくおねがいします。
- 社内で作られたアクセシビリティチェックシートの状況を眺める会を毎週実施していて、そこでいろいろな問題を拾いあげています。↩
