hey Advent Calendar 2021 及び アクセシビリティ Advent Calendar 2021 の 24日目です。
業務委託で STORES の開発をしている @inouetakuya です。近年ウェブ業界全体でアクセシビリティをカイゼンする取り組みが盛り上がっていますが、hey においても今年いくつかの動きがありました。
今回はその中のひとつに絞って、2021年に行った取り組みのなかで最も効果があったと私が考えている、freee 社のアクセシビリティガイドライン と チェックリスト を丸ごと導入したことについて、その背景や導入理由、そして導入してどうだったか？などをご紹介します。
導入前に抱えていた問題
hey ではもともとアクセシビリティについて「プロダクトがどのような状態になっているのが理想か？」を定めたアクセシビリティガイドラインを独自に作成しようと試みていました。
WebAIM のチェックリスト
その際、WCAG 2.1（W3C 勧告 Web Content Accessibility Guidelines 2.1） は（HTML や CSS といった特定の技術以外にも適用できることを目的に抽象的に書かれているため）具体的に何をすべきかを読み取りにくいと判断し、代わりに WebAIM のチェックリスト をベースにすることを決めていました。
なお、WebAIM のチェックリストは WCAG 2.1 を元に、具体的には何をすべきかをチェックリストの形式で記述してくれているものです。
これをベースに、hey のプロダクトへ適用しやすいようにするために
- 頻繁に参照することを考慮して、日本語訳する
- 誰（デザイナー / エンジニア）がその項目について対応するのかを明記する
- hey のプロダクトには関係のない項目については省略する
といった作業を有志で進めていました。
そのチェック項目の意図は何か？
ただ、有志でのガイドライン検討会においてよく話題に出たのが
あれ？このチェック項目ってなんであるんだっけ？
という点でした。チェック項目に「〇〇すべき」あるいは「〇〇すべきでない」と書かれているのですが、それが何のために存在する項目なのかが分からない。例えば
2.3.3 Animation from Interactions (WCAG 2.1 Level AAA)
Users can disable non-essential animation and movement that is triggered by user interaction.
日本語訳）
2.3.3 インタラクションによるアニメーション（WCAG 2.1 - AAA）
ユーザーは、必要のないアニメーションや、ユーザーの操作によって引き起こされる動きを無効にすることができます。
とあるのですが、アニメーションがあると何が困るのかが分からない。たしかにアニメーションが気に入らない人はいるかもしれないけれど、気に入らないぐらいだと工数をかけて対応する理由にはならないよね、みたいなことを話していました。
そこから WCAG の Understanding の日本語訳 を見て、
この達成基準の意図は、アニメーションがウェブページに表示されるのを利用者が防止できるようにすることである。一部の利用者は、動きのあるコンテンツから、注意散漫又は吐き気を経験することがある。例えば、ページのスクロールによって要素が動く (スクロールに伴う必要不可欠な動きを除く) と、前庭障害が発生する可能性がある。前庭 (内耳) 障害の反応には、めまい、吐き気、頭痛などがある。
え、めまいや吐き気を及ぼす人がいるのかと、ようやくなるほどと理解できる、といったことを繰り返していました。
ガイドライン策定に時間がかかり過ぎる
体感としてはおよそ半数くらいのチェック項目に対して、その意図が読み取れなくて WCAG の Understanding の日本語訳を参照するということを行っており、このままだとガイドライン策定に時間がかかり過ぎてしまうと不安に思っていました。
また、WCAG は更新されていくものであり、WebAIM のチェックリストも更新されていくことが予想され、となるとアクセシビリティガイドラインも更新しなければならないので、そのメンテナンスコストもばかにならないなと考えていました。
freee 社のアクセシビリティガイドラインとチェックリストの導入理由
そんななか もしあなたが『アクセシビリティ試験』をやることになったら WP ZoomUP #68 - connpass という勉強会に参加させてもらい、そのなかで
- freee の伊原さんが「freee アクセシビリティガイドラインとチェックリストをそのまま導入するのが最もコスパがよいと思う」と発言されていたこと
- 勉強会のなかで freee 社のチェックリストを用いて freee 社以外のサイトに対してアクセシビリティチェックを行っているのをみて、チェックリストが機能していたこと
などを見て、これは hey でもそのまま取り入れることができそうという期待が持てました。
そこから hey の有志で検討の結果、私たちがそれまでに抱えていた問題に対して、とても効果的であると判断し、freee 社のアクセシビリティガイドラインとチェックリストをそのまま導入することに決めました。
導入の具体的な理由は下記のとおりです。
- チェック内容が具体的で分かりやすい
- チェック項目の意図が参照しやすい
- チェック対象を「デザイン / コード / プロダクト」で分類されているので誰が対応すべきか判断しやすい
- チェック時にどのツール（スクリーンリーダーなど）を使うかが明記されている
- freee 社の現場でも使われているらしいので実績がある
- ガイドライン策定やメンテナンスのコストから解放される
ガイドラインとチェックリストをどのように使っているか？
hey のフロントエンドエンジニアチームではもともと、日々の開発ではなかなか対応が難しいような技術的課題（技術的負債の返済を含む）に対して、チームメンバー全員で丸一日かけて取り組もうという「大改善デー」というものがありました。
その大改善デーを利用して、フロントエンドエンジニアチームの全員が丸一日かけて
などを行いました。また、その合間に、デザイナーとフロントエンドエンジニアで
- Issue のトリアージ
- Issue をどのように解決すべきか仕様を検討
する会も 2回ほど開催しました。
実際に使ってみてどうだったか？
チェックリストとガイドラインは実用的で機能する
アクセシビリティ大改善デーでは各回の終わりにふりかえりの KPT を行ったのですが、抜粋すると下記のような感じで、一言にまとめると「実用的で機能した」という所感です。
- チェックリスト内の説明が、何をチェックしたら良いのか分かりやすい
- チェックリストのチェック項目の意図がよく分からなくても、リンクからガイドラインへ飛べて参照しやすい
- チェックに使うツール（axe など）がまとめられていて助かる
- チェック項目を絞り込みできるのが助かる
- 思ったよりもチェックにつまづかなかった
また、下記のようにアクセシビリティチェックを通して、アクセシビリティに対するモチベーションが上がった旨の声もありました。
- 思ったよりも OK の項目が多くて、作った当初の努力が伺えた（HTML のセマンティクスあたり）
- 今後の実装にあたり気を付けていこうと思えた
前進できた
また何よりも、ガイドライン策定とチェックリスト作成にかかる工数を、本来割くべきアクセシビリティの向上にあてることができました。
2021年9月〜12月にかけて解決できたアクセシビリティに関する Issue は 44個にのぼります。
対応できた範囲はプロダクトの一部であり、まだまだ課題は残っていますが、自分たちで「前に進めることができた」という点で自信を持つことができました。
謝辞
さて、ここまで筆者が 2021年の hey の取り組みのなかで最も効果があったと考える、freee 社のアクセシビリティガイドラインとチェックリストを丸ごと導入したことについて、紹介しました。
freee 社のアクセシビリティガイドラインとチェックリストの作成及び更新に関わってくださっている皆様にこの場を借りてお礼を申し上げたいと思います。いつもありがとうございます！本当に助かっています！
また、件のガイドラインとチェックリストの導入にあたって、下記のイベントも参考にさせていただきました。関係者の方にお礼申し上げます。
おわりに
W3C の創立者であるティム・バーナーズ・リーが「THIS IS FOR EVERYONE」と言ったように、アクセシビリティは Web の本質的な側面です。
個人の想いとしては、ウェブ業界全体のアクセシビリティの動きがますます盛り上がっていったら良いなと考えています。
今回 hey の取り組みを紹介しましたが、これが各社でアクセシビリティを推進していらっしゃる方の少しでも参考になればと思います。
hey もアクセシビリティの取り組みはまだ始まったばかりで、目標としている「普段の開発に定着させる」というところまでの道のりは遠いですが、2022年も前に進めていく所存です。
やっていきましょう！
