品質保証を上流へシフトする4つのアプローチ
このようにアクセシビリティの重要性が増していく一方で、「アクセシビリティは一度作って終わりではなく、機能を追加する度に壊れてしまう非常にもろいものです」と山内氏は指摘する。アクセシビリティ対応において最も避けなければならないのは、リリース直前のテストで大量の不備が見つかり「今さら直せない」という状況である。そこで必要となるのが、品質を最後の工程のみで守るのではなく、計画や実装の工程にもテストを組み込む「シフトレフト（品質保証の上流移行）」だ。
GovTech東京では、計画・設計・実装・テストの全工程にゲートを設けており、それらを「ツールを使用したテスト」「自動テスト」「手動テスト」「ユーザーテスト」の4つのアプローチに分類している。
ツールを使用したテストでは、「Xcode」や「Android Studio」に標準搭載されているアクセシビリティチェックツールを活用。さらに「Stark for Figma」によるデザイン段階でのテストや、AIツールである「Claude Code with Figma MCP」も活用し、画像代替テキストが適切かどうかなど、静的解析だけではカバーできない「文脈的な正しさ」を確認している。
またチームとしては、国際的なアクセシビリティガイドラインである「WCAG2.2」に基づいて、テスト時にチェックすべき基準を、AIを活用しながら策定している。さらに開発の継続的インテグレーション（CI）、ラベル漏れやタップ領域不足といったアクセシビリティの問題を自動検出する体制を構築し、マージする条件としてユニットテストの通過を必須とした。加えて、デザインと実装の乖離を防ぐべく、「Figma Code Connect」と「Figma MCP」を組み合わせたコンポーネント管理を実施。これにより、アクセシビリティ品質をクリアしたコンポーネントをAI経由で利用することができる。
もちろん、ツールの活用や自動化の仕組みですべてが解決するわけではない。最終的には松村氏のような当事者・協力者によるユーザーテストが欠かせない。そうした本質的な検証に注力するためにも、ツールや仕組みで対応可能な問題は早期に解消するシフトレフトを目指しているのである。
エンジニアが手放してはならない、「画面の向こう側」への想像力
山内氏はセッションのまとめとして「アクセシビリティのために今日からできるアクション」を提案。「特別なツールや予算は必要ありません。標準ツールで見えない問題を可視化することから始まります」と述べた。
まずはOS標準の読み上げ機能を有効にして使ってみる。そして「Accessibility Inspector」や「Compose UI Check」といったエディタの標準的なチェッカーでデバッグする。地道な取り組みのようにも思えるが、自分が書いたコードがどのように評価されるのかを知ることが、アクセシビリティを高める第一歩となるのである。
最後に山内氏は、AI時代だからこそ、エンジニアが画面の向こう側にいるユーザーのことを想像する大切さを訴えた。それを手放してしまえば、どれほど優れたアプリでも本当に必要な人に届かなくなってしまう。「AIが発達したとしても、困っている人を見つけることはまだ人間にしかできないはずです」と、エンジニアがアクセシビリティに向き合う重要性を改めて強調し、セッションを締めくくった。
