Flutterのアクセシビリティ向上 〜 DevelopersIO 2026 Osaka 登壇資料
はじめに
2026年9月29日に開催されたDevelopersIO 2026 Osaka Day2にて、「Flutterのアクセシビリティ向上」というテーマで登壇させていただきました。この記事では、当日使用したスライドとあわせて、登壇内容をご紹介します。
登壇内容 - 「Flutterのアクセシビリティ向上」
表紙
「Flutterのアクセシビリティ向上」と題して、クラスメソッド株式会社の持田徹からお話させていただきます。
自己紹介
自己紹介です。
持田徹と申します。
2018年7月に入社しました。
今日ご紹介するアクセシビリティに取り組んで、20年以上経ちました。
国際的なアクセシビリティ専門家団体IAAPの資格があるのですが、その資格の1つ を受験して、つい先日合格しました。
今回、とあるFlutterアプリの開発案件に、アクセシビリティ・スペシャリストロールで参画しました。
今日はその案件で得られたノウハウをシェアしたいと思います。
今日お話しすること
今日お話しすることは、まず最初にAIが開発をする時代に、どうしてアクセシビリティの知識が必要なのかについて。
そして、Flutterで実装する際の、教科書に載っていない落とし穴をシェアできればと思っています。
Webやそのアクセシビリティの話、法律や規則の解説などに関してはスコープ外とします。
アクセシビリティとは
では、「アクセシビリティ」とは何なのかをご説明します。
アクセシビリティの定義
「アクセシビリティ」とは、「アクセス可能な度合い、アクセスのしやすさ」という意味です。
例えばスマホアプリやWebアプリ、Webサイトの画面が、障害者や高齢者の方を含む、より多くのユーザーが、いろいろな利用環境から使えるかどうかを考えます。
利用環境というのは、スマホやPCのようなデバイスや障害のある方が使われる特殊なデバイスなどから利用できるかどうかです。
また、「より多くの場面で」というのも大事です。「場面」とは、例えば眩しい環境とか、騒音で音が聞こえない環境とか、そういった場面のことです。
それらも含めて、できるだけ多くの場面で利用できるようするにはどうしたらいいかという議論が、アクセシビリティの議論です。
アクセシビリティは、英語で accessibility と書くのですが、AとYの間に11文字あるので、 a11y と略されます。
どんなユーザーを想定するのか
アクセシビリティは、どんなユーザーを想定しているのかについて。
まず1つは高齢者です。今年の6月に 令和8年度の高齢社会白書 が公開されました。日本の総人口に占める65歳以上の高齢者の割合は 29.6% で、ほぼ3割ぐらいになったそうです。
また、視覚や聴覚など、身体に何らかの障害がある方はもちろん想定していますし、認知や神経などの、見た目ではわからない障害のある方も含みます。
障害者手帳を持っているわけではないが、手足の骨折やケガ、病気などで一時的に見る・聞く・操作するといった活動に制約がある方も想定されます。
だいたいアクセシビリティの話をしていて、障害者や高齢者という単語が出ると自分たちから遠い話との印象を持たれる方が多いそうですが、例えば「ダークモードじゃないと生産性が上がらない」 という話をよく聞きます。
それもアクセシビリティの話ですし、「キーボード操作じゃないともうやってられない」みたいな話もあるでしょう。
私は来月50歳になるんですが、小さい文字が非常に辛いです。高校生の娘が持っている生徒手帳がまったく読めないんですよ、もう全然見えない。
iPhoneを持っているんですが見づらいので、iPad miniを持ち歩いて、これで見ないともうやってられない。
そういった老眼も、もちろんアクセシビリティの範疇ですので、すごく広いユーザーを想定しているという風に考えてください。
カーブカット効果（The Curb-Cut Effect）
「カーブカット効果」という言葉があります。
街中の歩道がところどころ段差が低くなっているところがあると思いますが、あれをカーブカットと言います。
もともとは、車椅子の方が歩道に上がる際に障害にならないように、カーブカットが設けられます。
しかし、小さいお子さんがいらっしゃる方はベビーカーであったり、スーツケースで移動する時とか、いろんな時にすごく役に立つと思われているのではないでしょうか。
その時にはもはや、車椅子のために作られたものだということは意識されないかもしれないですが、このように、もともと障害のある方を想定して作られたものが、いろんな方の役に立つというのを「カーブカット効果」と言います。
例として、商用電子メールがあります。スライドの右側に写真を載せている、インターネットの父の一人と言われているヴィントン・サーフさん。サーフさんご自身も、奥様のシグリッドさんも、聴覚に障害があります。
電子メールという仕組み自体は1971年にレイ・トムリンソン(Ray Tomlinson)が考案したものですが、サーフさんは「不確かな音声通話を、テキストの明瞭さに置き換えてくれる」という理由で、ご自身の聴覚障害ゆえに早くからその価値に気づき、聴覚障害のある方々に電子メールの利用を熱心に勧めてきた、と本人が語っています。
Around 1971, Ray Tomlinson developed the idea of networked electronic mail, which was hugely attractive to me because it replaced uncertain voice calls with the clarity of text.
Vint Cerf on accessibility, the cello and noisy hearing aids
もしサーフさんご夫妻に聴覚の障害がなければ、電子メールの普及はもう少し違った形になっていたかもしれません。
タッチスクリーンについては、ウェイン・ウェスターマンさんという方が、博士論文を書いている最中に反復運動過多損傷(RSI、腱鞘炎のような症状)になってしまって、指への負担が少ない入力方法を追求したのがきっかけで、共同研究者のジョン・エリアスさんと1998年にFingerWorksという会社を立ち上げ、マルチタッチ対応のキーボードなどを開発しました。この会社が2005年にAppleに買収され、その技術がiPhoneのタッチスクリーンの元になったと言われています。それももともと、手への負担という身体的な制約から生まれた技術です。
普通にテレビを見ていたり、Netflixを観ていると字幕が出ますが、これはもともと聴覚に障害のある方のために作られました。
Closed Captioning for the Hearing Impaired: How it Originated
曲がるストローは、発明者が自分の幼い娘のために作ったものですが、その後病院に売り込んだところ、寝たきりの患者さんがコップの高さを気にせず飲めると評判になって、広まったという経緯があります。
The Straight Truth About the Flexible Drinking Straw
このように、もともと障害のある方に優しく作ると、いろんな人の役に立つ、ということがよく分かるかと思います。
法律上の要請
法律上の要請もあります。
日本には 障害者差別解消法 という法律があり、令和3年の改正により、令和6年4月1日から合理的配慮が義務化されています。これは民間企業も含めて、障害のある方から「このサービス、このスマホアプリはこういうところが不便だ」という要請があれば、過重な負担にならない範囲で、それに応えるよう努める(応じられない場合は代わりの対応を一緒に考える)ことが義務化されています。
この日本の法律では罰則はありませんが、EUやアメリカでは何年も前から罰則のある規定ができていて、EUに関しては 先日私もブログを書きました が、かなりの国で、いろいろな民間の電子サービスも含めて罰則のある法律ができています。
これらの地域でWebサービスやスマホアプリを展開する場合は、障害者も使いやすいUIになっていないと罰則が課される、という状況になってきていますので、公共機関や公共性の高い民間企業、例えば空港や銀行といったところは、そういう配慮が必要なんだと覚えていただければと思います。
スコープ
アクセシビリティの対象範囲は、さきほどご説明したように多岐に渡りますが、今回は視覚に障害がある方が利用されるスクリーンリーダーというものに絞って、深掘りをしていきます。
スクリーンリーダーとは
スクリーンリーダーとは何かというと、視覚に障害があっても、スマホやパソコンが操作できるようにするための、読み上げをする機能やソフトのことです。
普段はスマホやパソコンを目で見て操作されると思いますが、では目が見えなかったら操作できないかというと、それは困るので、画面に書いてあるものを音声で読み上げたりすることで、画面に何が表示されているかを音で判断し操作できるようにするものです。
iPadOSやiOSではVoiceOverという機能があり、AndroidではTalkBackという機能があります。
iPhoneでのスクリーンリーダーのデモ
iPhoneでのスクリーンリーダーのデモとして、VoiceOverをオンにする手順と、画面の読み上げのデモをお見せしました。
- 設定の「アクセシビリティ」を開き、いちばん上の「視覚サポート」にある「VoiceOver」を開いて、トグルをオンにします
- 画面の部品を音声で読み上げる機能が有効になりますので、実際に読み上げさせてみます
- 「VoiceOver切り替えボタン、オン。ダブルタップして設定を切り替えます。VoiceOverで画面上の項目を読み上げられます。項目を選択するには1回タップ、選択した項目を使用するにはダブルタップ。」と読み上げられます
- 続けて読み上げ速度の項目に移動すると、「読み上げ速度、50%、調整可能。値を調整するには1本指で上または下にスワイプします。」と読み上げられ、実際にスワイプして60%、70%と値を変えてみました
デモのおさらい
デモのおさらいをしたいと思います。
VoiceOverをオンにすると、画面に白い「カーソル」が出てきました。
実際にiPhoneでVoiceOverをオンにしていただくとわかると思いますが、操作方法がまったく変わります。
画面をタッチしてもタップなどはできなくなり、このカーソルを動かすことに特化した操作体系になります。
左右にフリックすると、カーソルが項目間を移動します。
白い枠で囲まれたカーソルが、トグルボタンや読み上げ速度などの画面部品の上に移動すると、「そこに何が描かれているか」ではなく、「どんな種類の部品があるのか」と「その画面部品がどんな状態か」が読み上げられました。
例えば読み上げ速度のスライダーでは「読み上げ速度、50%、調整可能」と3つ連続して読み上げられました。
これは、読み上げ速度というラベルがついた部品が、今50%になっており、調整可能な部品(スライダー)で、スワイプを上下すると値が変えられる、という情報が音声ですべて表現されています。
この、画面の部品の種類という概念と、現在どのような値なのかという点がこの後で大切な概念になります。
AI時代になぜアクセシビリティの知識が重要か
では次に、AIで開発する時代に、どうしてアクセシビリティの知識が重要なのかという話をします。
今回のFlutter開発プロジェクトで見た実例
今回、私が関わったFlutterの開発プロジェクトで見た実例ですが、最初にFigmaでスマホアプリのデザインを作りました。
ちょうどこれ1年前くらいの話なので、「Figmaから直接Claude Codeに書かせればそのまま画面ができるんだ」という話題でもちきりだった時期でした。そのFigmaのデザインデータからClaude Codeで実装されました。
できあがった画面実装を見てみると、もちろん見た目はFigma通りのFlutterアプリができているんですが、ボタンなどの部品が、InkWell や GestureDetector という部品で全部実装されていました。
InkWell や GestureDetector は、押せるけれども何の役割も持たない部品です。HTMLで言うと div や span 要素にハンドラーをつけた状態に近くて、 div や span も何の役割も持たない部品なんですが、それのFlutter版だと思ってください。
押したら何かするとは示していますが、それはどういう種類の部品がなのか、そのラベルは何なのかという「セマンティクス」という情報がありません。これらの情報を伝えてもらえないと、スクリーンリーダーは操作できません。そういった情報がない、素の部品だらけみたいな感じになっていました。
イメージで言うと、よくわからないボタンがたくさんあるけれど、押したらどうなるかが全く音声ではわからない、という状態の画面になっていた感じでした。
そのため、特にアクセシビリティに関する指示を入れずに画面実装をすると、アクセシビリティの問題が多いと言えます。
原因の考察：なぜアクセシビリティが欠落するのか？
どうして、アクセシビリティを向上してくださいというプロンプトを入れない、特にアクセシビリティに関する指示をしない状態で画面実装をすると、アクセシビリティの問題が多くなるのでしょうか。
アクセシビリティは非機能要件です。セキュリティやパフォーマンスと同じような性質のものなので、例えばClaudeやChatGPTといったモデルを育てていくときの評価が難しい部類に入ります。
例えば関数の仕様や画面動作では「この値を返せばOKだが、この値を返した場合はダメ」という検証可能な評価ができます。しかし「読み上げたときに、このように聞こえる」という評価は、モデルの評価として検証しづらい部類に入るので、そういったデータはなかなか取り込めないと思われます。
事前学習のデータとしてもないですし、事後学習の段階でも、そういうものは評価軸に組み込まれにくい。結果として、LLMに何も指示せず画面を作ってと言った場合には、そういうものの優先度が下がるんだという話が論文にもいくつかありますし、実際に検証してもそのような動きになりました。なので、このあたりが、もともと何も指定せずに画面を作らせたときに、アクセシビリティの観点で良くないプログラムが出てくる原因かなと思います。
今回のプロジェクトのケースにおける要因分析
今回のプロジェクトのケースにおける要因としては、2つあると思っています。
1つ目は、画面の開発指示、つまりClaude Codeに対して画面を作ってと指示を出すときに、アクセシビリティに関する言及がなかったこと。
もう1つは、Figmaからコードを生成するというプロセスにおける構造的な限界です。
Figmaは画面のデザインをするツールですが、そこには見た目の情報しかありません。
Figmaのデザインで、ウィンドウがあってその上にボタンがあるデザインがある状況で、「これはボタンという役割の部品だ」という情報や「このボタンが押されたら何かをアナウンスする」などの動的な情報を持たせることができません。
そのFigmaを見てClaude Codeが画面を作っている以上、そのようなアクセシビリティや動的な情報は伝わりません。
では「指示すればよい」のか？
では指示さえすればいいのでしょうか。
例えば「アクセシビリティを考慮してください、よくしてください」という一言さえ書いておけば、アクセシビリティに関する知識が全くなくても問題ない実装に仕上がるのかというと、それでは不十分だと考えます。
まず、現在の実装状況と、その品質を確認してアクセシビリティを評価できることが必要です。
前述のような、用途の不明なボタンばかり並んでいる状況を確認して評価できることが必要ですし、その現状をどう改善するのかを具体的に指示することも必要です。
こうして実装されたものを、きちんと評価する能力や知識が実装者側に必要です。
これらのどれかが欠けても、きちんとした品質は確保できないと考えます。
指示の難しさ①：一言だけ付け加えたパターン
実験として、「アクセシビリティを改善して」という一言だけを伝えると品質がどうなるかを確認しました。
ログイン画面だけのFlutterアプリに対して、「アクセシビリティを改善してください」という一言だけを指示すると、いくつか基本的な改善は行われました。
しかし、細かいところを見ると、無意味なコード、実効性のないコードもありました。
よって、一言だけ指示を加えただけでは、品質はあまり上がらないと考えています。
指示の難しさ②：もっと具体的に指示しても
では、もう少し具体的に指示すればということで、都度アクセシビリティ品質を確認せずに画面指示だけを重ねる実験も実施しました。
しかし、細かいところで品質が至らない部分が多数ありました。
よって、具体的に指示をする、指示の粒度を細かくしたとしても、結局その状態を都度評価できなければ、やっぱり品質は上がらないことを確認しました。
このことからも、実装者側にもアクセシビリティの知識がないと評価ができないと考えます。
評価の難しさ：そもそも判定できないケース
もう一つ、そもそも機械的に判定できないケースがあります。
Webのガイドラインですが、W3C WAIによるWebアクセシビリティのガイドライン WCAG(Web Content Accessibility Guidelines) の達成基準に、「画面の文字サイズを200パーセントにした場合でも、画面が崩れずきちんと機能すること」というガイドラインがあります。
視力が弱い方などが画面の文字サイズを拡大して使われているケースがあります。そういうケースでも問題なく使えるようにというガイドラインです。
ただ、FigmaのデザインデータやFlutterの静的なコードの解析では、レンダリング時にどういう見た目になるのかは判定できません。レンダリングしてはじめて判明します。
この点については、Claude Code とのやりとりの中でも、「Claude Codeでは判定することができないので、実装者が確認してください」とのことでした。
そのため、私も前述のプロジェクトでは、Android実機の文字サイズを全部最大にしてテストをし、文字崩れや表示崩れがないか、ボタンなど機能するかなどを確認し、もし不具合箇所があれば改善指示を出す、というループを実践していました。
パフォーマンスの文脈で「推測するな、計測せよ」という話がありますが、これは結局、AIが書いたコードにも当てはまるかなと思っています。
ここまでのまとめ
ここまでのまとめとして、「AIが実装するのだから実装者にアクセシビリティの知識が不要」は誤りだということ。
実装状況の確認、具体的な改善指示、指示したものの正しい評価。
さらに、こういう実装では、こんな落とし穴があるという知識や、あるべき実装の方法、実機での検証。
これらが全部できないと、結局は中途半端なアクセシビリティ品質になってしまうと考えます。
Flutterのセマンティクス基礎
では次に、Flutterのセマンティクスについてお話をします。
Flutterでは2つのツリーが並行して作られる
Flutterには、実は2つのツリーが並行して作られます。
例えばスライドに画像がある「お知らせ一覧」という画面があるとします。お知らせの一覧タイトルとその日付が並んでいる画面です。
Flutterの入門書などでは、このWidgetツリーができますという説明が最初の方にあります。
このWidgetツリーは画面の見た目を作るもので、こちらのツリーのみご存じの方も多いのではと思います。
しかし、実はFlutterをビルドした際に、もう一つの「Semanticsツリー」が並行して作られます。Semanticsツリーは、「SemanticsNode」というノードが連なってできているツリーで、スクリーンリーダーが読む専用のツリーです。前述の話で、ウィジェットで構成された画面部品がどういった種類の部品なのか、どんなラベルなのかなどの情報を、それぞれのSemanticsNodeが持っています。
例えば、ここで例としているお知らせ一覧画面では、Widgetツリーには三角の矢印やお知らせのタイトル、お知らせの日付などたくさんのウィジェットがありますが、セマンティクスとしては、これら全体で1つのSemanticsNode、つまりボタン1つになるので、「タイトルと日付があるボタン」という表現になったりします。
そのため、Widgetの数とSemanticsNodeの数は、異なることが多いです。
Semanticsツリーと3つの基本ウィジェット
このSemanticsツリーを組み立てるための基本的なウィジェットが3つあります。
1つ目が Semantics で、ノードにrole・label・hint・stateといった情報を付与するウィジェットです。
2つ目が MergeSemantics で、複数のノードを1つに統合します。
3つ目が ExcludeSemantics で、子孫のセマンティクスを丸ごと除外します。
MergeSemantics / ExcludeSemantics の具体例
例えば、先ほどの「お知らせ一覧」画面の、お知らせのタイトルテキストを考えた場合、
- 三角形のアイコン
- タイトルテキスト
- 日付
の3つのウィジェットが存在します。
この「お知らせ」の1件をスクリーンリーダーで読み上げる場合、まず「三角形のアイコン」は装飾であり、直接意味を持たないので音声読み上げから除外する処理をします(これは後述の ExcludeSemantics を使います)。
次に、タイトルテキストと日付ですが、これらがバラバラに読み上げられると、日付は、どのお知らせタイトルテキストと関連づけているのが理解が難しくなります。
そこで、日付とタイトルテキストをマージして、これは一つの部品だとスクリーンリーダーに伝えることで、スクリーンリーダーは1つの部品としての音声で表現します。
これが MergeSemantics の例です。
別の例で、例えば星マークアイコンを何度かタップすると、「評価4.0」をしますUIがあるとします。この部品も、
- 星マークアイコン
- 評価4.0
という2つのウィジェットになります。このうち星マークアイコン単体は装飾的な存在で「評価」の表現には必須ではないため、ExcludeSemantics で除外し、数値の 4.0 だけを読み上げるようにして、音声での読み上げを、よりわかりやすくします。
前述の通り、「お知らせ一覧」の個々の「お知らせ」から、装飾的な三角形のアイコンを除外するのにも ExcludeSemantics を使います。
落とし穴ツアー
私が、実際のFlutter開発案件で経験した落とし穴について、「落とし穴ツアー」として一部をお話ししていきます。
① 利用規約の同意問題
利用規約の同意問題というのがあります。
よく見かける画面だと思いますが、スマホアプリを利用する際、まず利用規約に同意しないと使えない場合があります。
その利用規約画面は、画面の中に、HTMLでいうiframeのような、画面の一部がスクロールするようになっていて、そこに長文の利用規約が入っています。
目が見えて、視力に問題がないユーザーであれば、2〜3回スクロールして、スクロールが終わって下まで行ったら、同意ボタンが活性化して押せますよ、という作りです。
リーガル系のコンサルタントも、この構成をすごく推奨します。
では、この画面を、スクリーンリーダーでは、どう操作するのでしょうか。
前述の通り、iPhoneでVoiceOverをONにすると、操作体系が変わります。3本指で上下にスワイプすることで、画面を1ページ分まとめてスクロールする操作が可能です。
ところが今回の実装の利用規約画面では、1本指でのフォーカス移動でも、3本指スクロールでも、思うようにスクロールの終端判定が成立しませんでした。利用規約の内容を音声で確認しながら進めるには、結局、一行ごとにフォーカスを送っていくほかなく、つまり行数の数だけ操作してください、という話になります。
まず、エンドユーザーは、このような操作を強要されることを、事前に認識していません。にもかかわらず、この画面に入ったら、何百回、場合によっては何千回という操作を強要されます。これをしないとアプリが使えないからですね。
さらにテストしていると、Androidでは何百回かスワイプすればスクロールバーが一番下に移動して、このボタンが活性化しましたが、iOSでは、利用規約の一番下の行までカーソルを移動させても「同意する」ボタンが活性化しませんでした。
iOSとAndroidの微妙なデザインの違いから、スクリーンリーダーのカーソルが利用規約の最下行までカーソルが移動しているのに全部スクロールしきらなくて、「同意する」ボタンが非活性のままでした。
このエンドユーザーは、何百回、何千回とスクロールされた挙句にボタンが活性化せず、詰むんですよ。
「こんなことさせていいんですか」と、私はすごく大騒ぎしましたが、周りにはあまりピンときてもらえませんでした。
このiOSとAndroidの違いというケースはまさに、実機で確認しないと気づけない部分だと考えます。
改善として、WebViewから読みこんでいたHTMLを、ネイティブFlutter画面に変換する処理を追加しました。
さらに「第1条」などの文字を見出しにすることで、スクリーンリーダーによる見出しジャンプを可能にしました。
② liveRegion問題
もう一つ、よくある問題として「liveRegion問題」があります。
例えば、新規登録でIDとパスワードを入れて「次へ」を押した場合に、初期の画面には存在せず、後から表示される「インラインエラーメッセージ(バリデーションエラー)」というものがあります。
こうした、後から画面に追加される部品は、スクリーンリーダーが扱うのを苦手とします。例えば「メールの形式が正しくありません」というエラーメッセージが後からツリーに追加されても、スクリーンリーダーはそれに気づきません。
エラーメッセージがこの「インラインエラーメッセージ」だけで表現され、これをクリアしないと次に進めない場合、スクリーンリーダーの利用者は永遠に何が原因で次に進めないのかが把握できなくなってしまいます。
ここで役立ちそうなのがliveRegion(Semantics(liveRegion: true))という機能です。これは、画面上の部品に付与しておくと、その部品の中身(ラベル)が変わったときに、自動的にその新しい内容を読み上げてくれるという仕組みです。例えば、通知件数のバッジが「3件」から「5件」に変わったときに、自動で「5件」と読み上げさせたい、というような場面で使います。
ただ、今回のケースでは、liveRegionは効きません。liveRegionが反応するのは、あくまで「前のフレームにも存在していたノードの中身が変わったとき」だけだからです。今回のエラーメッセージのように、条件分岐によって新しくノードが追加される場合は、そのノードがマウントされた時点では読み上げられない、という落とし穴があります。
そこで使うのがSemanticsService.sendAnnouncementです。これを使って、同じ内容を明示的に音声でも流す処理を追加します。
アクセシビリティの評価の観点では、このsendAnnouncementで何かの情報を流したという事実は、さっきのSemanticsNodeツリーには入りません。アナウンスしたという事実は把握できますが、アナウンスした中身が何なのかは伝わらないので、これも今のところはSemanticsNodeツリーをダンプしても評価できるものではないため、機械的な評価はできません(なおliveRegion自体はツリー上にフラグとして残りますが、sendAnnouncementはそれすら残りません)。
③ モーダルダイアログのフォーカス問題
3番目に、「モーダルダイアログのフォーカス問題」です。
例えば「続行しますか」というモーダルダイアログを表示したときによくあるのが、VoiceOverカーソルがモーダルに乗ってくれず、背後のウィンドウ上の画面部品の間をいつまでも移動してしまう現象です。視覚的にはモーダルが手前に重なっているのに、フォーカスだけは背後に取り残されている状態ですね。
アプリとしてはモーダルを操作しないと次に進めないので、スクリーンリーダーのユーザーからすると、何を操作しても画面が変わらず、何が起きているのか分からなくなってしまいます。
対策としては、モーダルが表示された瞬間にカーソルをその中へ着地させ、表示されている間はカーソル移動がモーダルの中だけで完結するようにする必要があります。
これはClaude CodeにFlutter実装を任せた場合にも「あるある」な落とし穴で、実機でモーダルにフォーカスが乗るか、そこから外に出ないかを必ず確認する必要があります。
実装の大原則：推測するな、計測（実測）せよ
繰り返しになりますが、実装の大原則は「推測するな、計測(実測)せよ」です。
Claude Codeが画面のテストを作ってくれて、それがグリーンになる状態になったとしても、それは実機で問題なく読まれ、操作可能であるということとは全く違います。これはつまり、ウィジェットテストはセマンティクスツリーの形までを保証しますが、それが問題ないということとは全く別の話ということです。
Flutterでは ensureSemantics 、Android側では uiautomator dump などを利用すると、セマンティクスツリーの中身をダンプできますが、それを見たところで十分ではない、ということをこれまでご説明してきました。
最終的には実機でスクリーンリーダーを動かして耳で聞くとか、現象を確認することが大事だと考えます。
まとめ
まとめです。
今日のキーメッセージとしては、AIが実装する時代にもアクセシビリティの知識が必要と考えます。
また、テストがgreenであったとしても実機で問題なく読まれるとは限らないので、推測せず、Claude Codeに任せきりにせず、きちんと実測すること、そして実装者が正しい知識をもって評価することが必要と考えます。
カーブカット効果の話をしましたが、アクセシビリティを向上して画面の品質を高めるということは、ユーザーにもAIにも読みやすいUIを作ることにつながります。
現時点では、という話になりますが、実機で耳で聞く作業は、当面は人間の仕事だと考えます。
それはAIに耳がないからということではなく、こういうUIだったら人はこう感じるよね、とか、もう少し言うと、障害のある方はこういうところが不便だ、という知識を持ってUIを評価して、こういう改善をするべきだと提案したり、プルリクエストを出したりする、その判断や作業をするのは人間だと思いますので、ここはClaude Code任せにはできないなと考えます。
以上です。ご清聴ありがとうございました。
