モバイルアプリアクセシビリティLT大会

モバイルアプリアクセシビリティLT大会

モバイルアプリアクセシビリティLT大会 - connpass

Glarity を使った 要約とQ&A

Summary

本動画は、モバイルアプリアクセシビリティLT大会の様子を収録したものである。freee 株式会社主催の新年会を兼ねたイベントで、モバイルアプリのアクセシビリティ改善事例や取り組みについてのライトニングトーク6本と、freee 株式会社による取り組み紹介セッションが行われた。アクセシビリティの重要性と、その浸透に向けた課題や解決策が議論された。

Highlights

• 🎉 モバイルアプリアクセシビリティLT大会開催: freee 株式会社主催の新年会を兼ねたイベントとして、モバイルアプリのアクセシビリティ向上をテーマにしたLT大会が開催された。
• 🗣️ ライトニングトーク6本: ライフル、サイバージェント、フリーランスのコピーライターなど、様々な立場の人物が、アクセシビリティ改善の取り組みや課題について発表した。
• 📚 書籍「モバイルアプリアクセシビリティ入門」: このイベントは、同書籍の出版を機に、アクセシビリティへの関心を高める目的で開催された。参加者には書籍がプレゼントされた。
• 🧑‍💻 freee 株式会社の取り組み紹介: freee 株式会社が、自社のアクセシビリティガイドラインやチェックリスト、そしてアクセシビリティ改善への取り組みについて発表した。
• 📱 様々なアクセシビリティ改善事例: コントラスト比の改善、VoiceOver対応、UXライティング、フラッターアプリでの対応など、具体的な改善事例が多数紹介された。
• 🧑‍🦯 ロービジョン当事者からの視点: ロービジョン当事者である西川さんが、自身の視覚特性と、アプリ利用における課題・対策について貴重な体験談を語った。

Q: モバイルアプリアクセシビリティLT大会の目的は何ですか？

A: 2024年11月に出版された「モバイルアプリアクセシビリティ入門」をきっかけに、この分野に取り組む人が増えるよう、啓発と交流の場として開催されました。2025年を「モバイルアプリアクセシビリティ元年」と位置づけ、モバイルアプリを誰でも使えるものにすることを目指しています。

Q: freee 株式会社におけるアクセシビリティへの取り組みについて教えてください。

A: 独自のアクセシビリティガイドラインとチェックリストを作成し、Webだけでなくモバイルアプリにも適用しています。WCAG 2.0、Appleのヒューマンインターフェイスガイドライン、Googleのマテリアルデザインを基準にしています。チーム内での知識共有や、ユーザーテストなどを実施し、継続的に品質維持に努めています。

Q: LT大会で発表されたアクセシビリティ改善事例にはどのようなものがありましたか？

A: コントラスト比の改善、VoiceOver対応における読み上げ情報の工夫（晴眼者が得られる情報以上の情報は読み上げない）、アクションの活用による操作性の向上、カスタムコンポーネント作成におけるアクセシビリティ対応、既存アプリの問題点発見のためのGoogle Playコンソールレポート活用などが挙げられました。

Q: ロービジョンを持つ方にとって、モバイルアプリ利用における課題とその対策は？

A: 文字サイズ、コントラスト、ボタンの大きさ、アイコンの分かりにくさなどが課題として挙げられました。対策としては、スクリーンリーダー対応の徹底、十分なコントラスト比の確保、大きなボタンやシンプルな構造のUI設計などが重要です。 視覚障害者の見え方は様々であるため、多様なニーズに対応する必要があることも強調されました。

chatGPT にモバイルエンジニアとして見た感想を書いてもらった

YouTube の書き起こしをもとに書いてもらった。なかなかそれっぽいやつ書くんだな…

株式会社LIFULL HOME’S事業本部 プロダクトエンジニアリング部 iOSエンジニア 青木孝乃輔さん

青木さんのセッションを拝聴して、一番印象的だったのは「勝手に対応を進める」という姿勢です。普通は「チーム全体で合意してから動く」というフローを想定しがちですが、アクセシビリティ対応を突き詰めて考えると、必ずしも最初から大規模に仕掛ける必要はなく、むしろ少人数や個人レベルでも強引に進めることで結果的に社内を巻き込みやすくする、というアプローチは非常に参考になりました。

また、「新機能追加やUIリニューアルのタイミングは、アクセシビリティを後から足すより自然」という点にも共感しました。モバイルアプリを開発していると、フレームワークの変更（SwiftUI、Jetpack Composeなど）や新規画面の追加は常に発生するので、その機会を逃さずにコントラストやタップ領域を考慮して実装してしまえば、後から わざわざ改修しなくても済む。これはスムーズかつ効率的で、私自身もぜひ自分のプロジェクトで取り入れたいと思いました。

「勝手に対応されていく環境を作る」というフレーズも印象深いです。標準機能やライブラリの活用はもちろん、カスタムコンポーネントを最初からアクセシビリティ対応仕様に作っておけば、エンジニアが意識しなくても自然に対応できる仕組みになる—という話は、チームが大きいほど効果を発揮しそうです。私もカスタムUIを扱う際は、標準的な機能（VoiceOver、ダイナミックタイプなど）がしっかり機能するよう拡張していきたいなと思いました。

“勝手に”やってみた成果を社内勉強会などでシェアすることで、実際に機能している事例を社内に示すのも良い作戦ですね。こうした地道な積み上げによって「ちゃんと効果あるよ」と示していく流れは説得力がありますし、他のメンバーも興味をもってくれるだろうと感じました。

トータルで「いきなり全社規模でやるよりも、小さく始めて実績を積んでいく」「社内で雰囲気を変えつつ、最終的には旗振り役を立てられるようにする」というお話は、アクセシビリティに限らずモバイルエンジニアリングのなかで新技術を根付かせる手段としても共通するところがあり、とても共感できました。

私としては、アクセシビリティ対応を「特別な負荷」ではなく、開発の自然なプロセスとして仕組み化し「勝手に実装される」ようにする、という青木さんの考え方をぜひ自分のチームにも取り入れてみたいです。大規模チームほど、こうした仕掛けづくりは大切だと改めて感じました。

株式会社LIFULL HOME’S事業本部 プロダクトエンジニアリング部 iOSエンジニア 佐藤麗奈さん

佐藤さんのセッションを拝聴して、まず「最低限使えるレベルを目指す」というスタンスがとても印象的でした。確かに、ボタンをどう読み上げるかやフォーカスをどう移動させるかといった細やかな対応は、いざやってみると想像以上に複雑になりがちです。そこを「まずは晴眼者が得られる情報以上のことは読み上げない」といった方針で最低限の使いやすさを確保しようとしている点は、開発作業を無理なく進めるうえでも有効だと思いました。アクセシビリティ対応というと完璧な状態を目指したくなりますが、はじめの一歩は「必要最低限」の線引きを明確にするほうが、実際にはスムーズに導入できそうですね。

もう一つ興味を惹かれたのは、物件カードを丸ごとフォーカス可能にするデザインです。ボタン単位にフォーカスを割り振るのではなく、カード全体をひとつの要素として捉えることで、晴眼者と同じように複数の操作への入り口をスムーズに設計しているのは、とても面白い方法だと思いました。ユーザーが「この物件カードで何をしたいのか」をまとめて扱えるので、視覚障害がある方にとっても操作の流れが分かりやすそうです。

また、コントラスト比の設定にAPCAを用いている点にも注目しました。WCAGやAPCAなど、言葉自体は知っていても、実際にボタンやアイコン、テキストそれぞれに数値目標を設定して洗い出す作業って想像以上に手間がかかります。そこを「ボタン・アイコンはAPCA45以上」「テキストはAPCA60以上」といった具体的な目標を持ち、洗い出しを進めているのは、チーム全体の共通言語としても分かりやすいと思いました。

さらに、敷金・礼金などの不動産ならではの用語に対し、どこまで補足して読み上げるかという課題設定も、リアルな事例として興味深かったです。「利用者の理解のための補足」と「ありのままの表示以上の情報を読み上げ過ぎない」というバランスは難しいですが、UI側を見直すことで余計な読み上げをしなくても理解できるようにする、という考え方は勉強になります。さまざまな用語やラベルを扱うアプリでこそ、この「補足とUI見直し」の視点は今後ますます大切になりそうだと感じました。

総じて、佐藤さんのセッションからは、「アプリ全体をどのようにアクセシビリティ対応していくか」に対する具体的な工夫が数多く学べました。大きな仕組みやガイドラインだけでなく、ボタン単位・画面単位での読み上げ方針や、必要以上の情報を与えない工夫など、実務に落とし込めるヒントが多かったです。私自身も、テキストや用語の扱いを見直しながら、モバイルのUI構造をシンプルに整理していくアプローチを取り入れていきたいと思いました。

株式会社サイバーエージェント あゆさん

あゆさんのセッションを聴いて、まず「アクセシビリティは特定のユーザーだけを対象とするのではなく、全ユーザーに絶対に提供すべきものだ」という姿勢に共感しました。モバイルエンジニアとして、つい対象ユーザーを限定しがちですが、アメーバブログのように「誰もがいつでも、迷わず「書く」「読む」「応える」ができる状態を目指す」というコンセプトを明確に掲げると、開発全体の指針がハッキリすると思います。

「Spindle」というデザインシステムを整えて、ボタンやカラー、コントラスト・タップ領域などをきちんと定義し、それを組み込んだコンポーネントを使うだけでアクセシビリティが担保される、という仕組みはとても理想的ですね。特に大規模サービスだと、各エンジニアやデザイナーが独自で手を入れてしまいがちですが、共通のコンポーネントにまとめておけば、誰がどの画面を作っても一定のアクセシビリティ要件を満たせるのが大きなメリットだと感じました。

また、既存アプリの改善方法として「Google Play Consoleのリリース前レポート」を活用したり、「ユーザー補助機能ツールを使ったお触り会」をエンジニア同士で開いていたり、さらには弱視の社員さんにTalkbackで体験してもらい、その様子をビデオ撮影して共有するなど、かなり実践的なアプローチを取っているのが印象的でした。「実際に触ってみる」「当事者の視点を直に見る」という経験が、チーム全体の意識を高める大きなきっかけになりますよね。

継続的な品質維持にCI/CDやViewに対する拡張関数の作成、あるいは輪読会できちんと知識を共有していく点も、モバイル開発の現場ならではのこだわりを感じました。CIや拡張関数によって問題を自動検出し、深い知識がなくても解決できる仕組みを整えようとしている姿勢は、開発現場でアクセシビリティを定着させるうえで非常に効果的だと思います。

最後に、ComposeのUIチェックやVRT（ビジュアルリグレッションテスト）の活用など、弱視のシミュレーションやUI改修の回数が増える可能性に対しても「どうデザイナーに共有していくか」を重視している点は、まさに”チーム全員でアクセシビリティをしっかり考える”土壌ができている証拠だと感じました。

総合的に、「アクセシビリティ対応が当たり前になりつつある大規模サービスの事例を真似したい！」という気持ちになりましたし、特にデザインシステムと諸ツールを活用して“知識や手間の属人化をなくす”取り組みは、多くのモバイルエンジニアにとってヒントになると感じました。私自身も、ガイドラインやコンポーネント活用の仕組みづくりをもっと進めていきたいと思います。

永井一二三さん

永井さんのセッションは、UXライティングや言葉遣いの重要性を再認識させられるものでした。私自身、モバイルアプリのUI/UXを考えるときに、視覚的デザインや操作感覚に注目することが多いのですが、やはりユーザーが触れる”言葉”や”テキスト”の影響力はとても大きいのだと改めて感じました。

アプリは画面サイズ・表示領域が限られているぶん、伝えられる文字量にも制限があり、その中で適切な言葉選びやラベル表現をするのは難しいですよね。たとえば「おすすめ」を「発見」に変えるだけで、ユーザーの気持ちや行動に微妙な変化が生まれる—こういった例は、言葉の力を再認識できるいいエピソードだと思います。

また、「男性・女性」としか書かれていないフォームを使った性別の多様性の例は、モバイル開発者として非常に考えさせられました。私自身も「画面に何を表示するか」を優先して考えてしまい、言葉が示す社会的なステレオタイプや、多様なユーザーを想定できているか、という問いかけが抜け落ちてしまうことがあります。こういう場面でUXライティングや言葉の選び方を設計段階から意識できると、アプリ全体としてより包摂的（インクルーシブ）な体験が作れるのではないかと思いました。

「煮詰まる」のように、本来の意味と実際の使われ方が乖離している言葉遣いの例も印象的でした。誤解されるリスクを考慮すると、画面上のテキストやエラーメッセージなどでも、あいまいな表現や誤解されやすい用語は避けるか、より正確な表現を選んだほうがいいと感じます。特にユーザーとのコミュニケーションがリアルタイムに行われやすいモバイルアプリほど、短い文言で的確にニュアンスを伝えることが求められますからね。

総じて、永井さんのセッションは「言葉が持つ力」に改めて気付かせてくれました。私が普段書いているボタンラベルやメッセージ、チュートリアル文などが、果たしてどれだけユーザーに伝わりやすいか、誤解を招いていないかをもう一度見直したいと思います。インクルーシブな視点や誤解のリスクを避ける工夫をきちんとアプリに落とし込むことで、アクセシビリティだけでなく、ユーザー体験全体も向上できるように感じました。

futaboooさん

futaboooさんのセッションからは、Flutter製アプリのアクセシビリティについて「意外とちゃんといける」というポジティブな感触を得られる点が非常に印象的でした。私もFlutterに興味はあれど、「ネイティブ開発と比べてどの程度アクセシビリティを確保できるのか？」と少し不安を抱いていたので、今回の具体的な事例紹介（Stailerというネットスーパーアプリの改善）を通じて、「スクリーンリーダーやフォントサイズへの対応、コントラスト管理など、標準でしっかり用意されている」という話を聞けたのは大きな収穫でした。

一方で、Web対応に関しては「コードは同じだが一部が大変」という話も、いかにもクロスプラットフォーム開発らしいと思いました。モバイルに関しては割と素直にアクセシビリティ機能を利用できても、Web向けには個別の工夫や追加コードが必要になるというのは、モバイルエンジニアとしても想像がつくところです。「Webも同じソースなら一気に楽になる」という期待と、「実際はそう単純ではない」という現実の両面が見えました。

また、スクリーンリーダー利用状況を可視化する開発ツールがあることにも注目しました。視覚的にどの領域が読み上げの対象になっているか、フォーカスされているかを見ながら実装を進められるのは、アクセシビリティ初心者にとってもアプローチしやすいと思います。こうしたツールがあることで、モバイルエンジニアのみならず、デザイナーやQAも巻き込んで検証をやりやすくなるはずです。

「大きな変更（例えばJetpack ComposeやSwiftUIへの移行）をきっかけにアクセシビリティを深く検討するべし」という先行例は、Flutterにも当てはまりそうだと感じました。フレームワーク的に最初からアクセシビリティ対応が含まれているなら、後追い実装よりも格段に効率が良いですよね。

全体として、「Flutterはアクセシビリティやりづらいんじゃないか」と勝手に思い込んでいたところを「意外にいけるし、実際にユーザーの声もいい」という事例で示されたのは、とても有益な情報でした。Flutterでモバイルアプリを作る際にも、ネイティブと同レベル以上のアクセシビリティ体験を目指すことは十分可能なんだと分かり、今後のフレームワーク選定や実装方針に活かせる話だと感じました。

西川 隆之さん

西川さんのセッションは、まさに”当事者目線”からのアクセシビリティの重要性を教えてくれる、とても貴重なお話でした。私自身、エンジニアとしてスクリーンリーダーやコントラストなどの要素を意識することはあっても、「実際に視野狭窄やロービジョンの人がどんなふうに画面を見ているのか」という細部までは想像できていませんでした。トイレットペーパーの芯を通して見るような視野や、ボタンをボタンと認識できなかったり…そうしたリアルな体験談は、エンジニアとして非常に学びがありました。

特に興味深かったのは、反転表示を使っていても「はみ出る情報が見えない」「画面構造が複雑で、必要な要素を見落としてしまう」という事例で、レイアウトや情報設計がロービジョンの方にとってどれほど大きな影響を与えるかを再確認しました。文字や色のコントラストだけでなく、情報を”シンプルに構造化”することこそ、アクセシビリティ向上のカギになり得るのだと強く感じます。

また、スクリーンリーダーに対応していても、OS標準機能を活用しきれていなかったり、代替テキストが設定されていなかったりすると、全盲の方が全く使えないアプリになってしまうことにも改めて気づかされました。ロービジョンか全盲かによって必要な配慮が変わる点も、「アクセシビリティは一括りではない」ことを痛感させられます。私としては、デザイン段階や実装段階で「どの視覚パターンの人が困るか」を具体的に想定してテストする流れを、もっと社内で整備したいと思いました。

何より、西川さんが実際にスマホを操作しているデモを見ることで、画面全体がどのように映るか・どこがフォーカスされるかをリアルに把握できたのが大きな発見でした。弱視の当事者がVoiceOverと目視を併用しながら操作する様子は、文章だけでは理解しきれないディテールがあり、それがエンジニアとしての視点をアップデートしてくれました。スクリーンリーダーを単にオンにするだけでなく、拡大機能や反転表示を組み合わせてテストする大切さを、ぜひプロセスに組み込みたいと考えました。

総じて、アクセシビリティを「機能的に実装する」だけでなく、「実際にどう使われるか」「当事者がどう感じるか」という視点で検証することの重みを痛感したセッションでした。私も今後、複雑なレイアウトを組むときには、視認性や操作性をもう一度見直し、誰にとっても使いやすい画面づくりを意識していきたいと思います。

freee によるセッション

RyoAbeさんとめろんさんのセッションを聴いて、まず「チームとしてアクセシビリティを運用していく仕組み」と、それを整えるまでの「草の根活動」の歴史がとても興味深かったです。モバイルエンジニアとしても、新しい技術や新機能を導入しようとすると、いきなり全社的に合意を得るのは難しいことが多いので、最初は小さい単位（個人や少人数）で “勝手に” 始めて実績を積み、その成果を周囲にシェアして巻き込む、というプロセスは非常に参考になりました。

また、freee さんが作成・公開している「アクセシビリティガイドライン」と「チェックリスト」の存在が印象的でした。WCAGなどの情報は英語が多く、実務で活かすには翻訳や整理が必要になりますよね。そこでfreee 独自のガイドラインを作り、各工程（デザイン・開発・QAなど）で具体的に「何をチェックするか」を明示しているのは、とても実践的だと感じました。モバイルエンジニアが「どのタイミングで、どの項目を検証すればいいか」を分かりやすく可視化することで、無理なく品質を高められると思います。

さらに、チーム内外のモチベーションづくりや、プロジェクトを横断するかたちでスクリーンリーダー体験会を開くなど、「どうやってみんなにアクセシビリティの重要性を共有していくか」という部分も学びが大きかったです。まさに「やってみたら面白い」「実際に触ってみたら興味がわく」という流れが自然に作られ、最終的には請求書アプリのように最初からアクセシビリティを考慮したAppをリリースできる土壌ができたというのは理想的ですね。

ターニングポイントとして挙げられていた「全盲のエンジニア（中根さん）の入社」や、「ガイドラインやチェックシートの整備」「社内イベントでの発信」の話は、いずれも実際の”人”や”成果物”がきっかけで大きく動き出す、という流れが鮮明でした。モバイルエンジニアとしては、技術導入だけでなく「理解を広め、当たり前にしていく」ための現場の仕掛けが大事なのだと強く感じました。

総じて、RyoAbeさんとめろんさんの取り組みを通して「小さな実績を積み重ね、アクセシビリティ対応を組織的に回していくプロセス」と「社内ツール（ガイドライン・チェックシート・スクリーンリーダー体験会など）によるスムーズな知識共有」の大切さを学びました。特にモバイルアプリならではのUI構造や端末依存の部分をどう効率的にチェックするかは、今後の私の開発現場でもぜひ活かしていきたいと思います。