アクセシビリティ定期チェックの持続可能な形。理想論ではない、チームで回せる運用に変える考え方。

アクセシビリティの品質劣化を防ぐため、四半期ごとなど定期的な全画面チェックを計画しても、チェックだけで相応の開発リソースを使う想定になり、取り組む前に「やりすぎではないか」という空気がチームに生まれてしまうことがあるのではないでしょうか。

実際、これまでアクセシビリティを推進したチーム内では「他の優先的な開発のリソースを使ってまで、定期的なアクセシビリティチェック機会を作るべきか」という議論が出ました。

一方で、日々のアクセシビリティチェックだけでは「網羅的な品質の低下を見逃すことにならないか」という不安もあり、工数と品質の板挟みが生まれていました。

そこで今回は、「理想論ではない、継続できるアクセシビリティ定期チェック」の仕組み作りの事例をまとめてみたいと思います。

「どの画面をチェックするか」4つの選定基準

まず、定期的なチェックでは「全ての画面のチェック」を追うことをやめ、リスクが高い画面を重点的に守るという戦略で、コストをかけすぎないよう提案しました。

選定となる基準はざっくりいうと以下4点です。

• 重要度が高い： PV数が多い、あるいはコンバージョン（CV）に直結する画面
• 動線に連続性がある： ユーザーが目的を達成するまでの主要な一連の流れがある画面
• 複雑性がある： 複雑なインタラクションや共通コンポーネントが多用されている画面
• 放置度合い： 前回以降、一度も改善やチェックの対象になっていない画面。 現在位置の読み上げなどスクリーンリーダーやOSのアップデートによって挙動が異なるケースもある。また、 「一度も見ていない箇所」をなくすことで、盲点を作らない

チェックをする画面数を選定して少なくすれば、定期的な取り組みも持続しやすくなります。

職能横断グループでチェックをする

そしてエンジニアだけにチェックの負荷と責務が集中するのを避け、PdMやデザイナー含むグループで行う体制作りを提案しました。

Issueテンプレートでチェック項目を用意し、職種の異なるメンバーが同じシナリオを確認する時間を作ります。

チェック項目の一例を挙げてみましょう。

• ツールでの確認
  • Dialog/Accordion など動的な UI は状態までスキャンした
  • 違反が「0件」であることを確認した
• 目視での確認
  • alt属性の内容が適切である
  • ナビゲーション順序に一貫性がある
• キーボード操作の確認
  • フォーカス順序が論理的である
  • キーボードトラップが適切に管理されている
• スクリーンリーダーでの確認
  • 見出しジャンプをしてもコンテンツの意図が伝わる
  • 隠しテキストの追加が妥当である
• テキストの文字サイズ200%拡大表示の確認
  • 横スクロールせずに情報が閲覧できることを確認した

ツールや AI によって自動でチェックできる項目もあれば、人が操作し、目視で妥当かどうか判断すべき項目もあります。

自動チェックは非同期で行っておき、同期的には特に目視で判断すべき項目にフォーカスして、1回あたりの所要時間をおさえます。

実装の妥当さ、デザインの意図、ユーザーの目的遂行のような異なる視点を持つ職種間で、同期的に会話しながらチェックに取り組むことで、1人あたりの負荷は下がりつつも、多角的に「致命的な欠陥」を拾え、知見共有にもなる体制となり得ます。

日々の運用や機能開発でもチェックプロセスを取り入れ、ふだんからメンバーがアクセシビリティチェックに慣れておけば、1時間で複数画面をチェックすることは容易になりますし、定期チェックは「念のための確認」としてより軽い負担で回るようにもなるでしょう。

定期的なアクセシビリティチェックを「当たり前」にする工夫

このように四半期ごとなどの定期的なアクセシビリティチェックというプロセスを導入する際には、チームにとって重たい特別イベントにせず、かといって意味のない軽さにはしない、という取り組み方の塩梅が重要に思います。

たとえばテストの導入と同じように、アクセシビリティを特別なものとして考えるのではなく、品質維持の一環として、自然に当たり前に取り組める形として、チームに根付かせる働きかけが重要です。

理想的ではないかもしれませんが、チームにあう実践的な運用をすることが、長期的な品質担保に繋がると思います。

以下記事も、ぜひ合わせてご覧ください。

また、Gaji-Laboが支援させていただいたジョブメドレーのアクセシビリティ向上の取り組みと、「プロジェクトをやりきる」文化を読んでいただけると、よりリアルにプロジェクトの現場感がわかると思います。こちらもお読みいただけたらうれしいです。