行政アプリ全画面TalkBack対応を、デザイナー協業とAIエージェントで自動化していく実体験
- Kenji TazawaAndroid Engineer @ GovTechTokyo Product Engineering Division
行政アプリ開発を担当しており、全コンポーネント・全画面のWCAG 2.2 A/AA準拠TalkBack対応の実装を行っています。 課題は規模と協業です。現状で35のdesignsystemコンポーネント、複数のfeature画面——それぞれに`contentDescription`・セマンティクスロール・フォーカス管理・二重読み上げ防止を正しく実装するには、Compose semantics APIへの深い理解と膨大な工数が必要です。さらにデザイナーとの間で「どのコンポーネントにどの読み上げを付けるか」などを整理する初期コストも無視できません。 解決策として、Figma MCP × Claude Codeカスタムスキル × TalkBack検証の3段階パイプラインを構築し、デザイン側・実装側でフローを統合しました。 デザイン側では、Figmaリポジトリの構造を読み取ってアクセシビリティ用のアノテーション初稿をAIが自動付与し、デザイナーがレビュー&Fixする協業フローを確立。 実装側では、確定したFigmaアノテーションをカスタムスキルが抽出してMarkdownの分類表へ変換し、AIエージェントがCompose semantics APIの実装コードを生成します。画面単位だけでなくコンポーネント単位のコード生成にも対応しています。 汎用コンポーネント専用のTalkBack検証アプリを用意し実機で細かな粒度でTalkBackの検証とデザイナーによる読み上げレビューを行えるようにしています。 このセッションでは検証でで見つかったバグたちも包み隠さず話します: 外側のcontentDescriptionと内部Textが両方読まれる「二重読み上げバグ」、liveRegionにfocusable()を付与すると外部キーボードで二重読み上げになる禁止パターン、——これらはすべて実機TalkBack検証で初めて発見したものです。 このセッションを聴けば、「TalkBackって何から始めればいいの?」という疑問に対して、デザイナー協業フローからCompose実装、実機検証までの自動化パイプラインを作る具体的な答えが見つかります。
対象者
「TalkBack対応をそろそろ本格的にやらなければ」と感じているエンジニア、デザイナー a11y協業フローに課題を感じているチーム