ハイライト
Apple のデザイナー Chris と Lisa は、inclusion gap フレームワークを提唱しました。障害は身体能力と社会の期待との間のギャップから生じるものであり、そのギャップを埋める製品（エレベーター、マイク、カーブカット）は最終的にすべての人に利益をもたらすということです。
主要内容
多くの開発者は、アクセシビリティを「機能を作り終わったあとに VoiceOver label を補足する」コンプライアンス作業と考えています。しかしこの session は、もっと実用的な視点を提供します。7 人に 1 人が何らかの形で障害を持っている（00:39）のに加え、一時的なものもあります。コンサート後の一時的な聴力低下、騒がしい図書館で動画を外放できない状況、周囲がすべて外国語の場面などです。障害を「少数者の特殊なニーズ」と捉えることは、大きなデザインの可能性を見落とすことになります。
この session は、障害を inclusion gap と再定義します。つまり、身体ができることと、社会がそれをできると仮定していることとの距離です（04:55）。2 階建ての建物にエレベーターがなければ、車椅子利用者は上へ行けません。しかし階段が工事中であれば、足の健常な人も同様に上へ行けません。能力の差は実在しますが、障害は環境によって作り出されるものです。このフレームワークに基づけば、デザイナーの仕事は「補填」ではなく、app 内に潜む inclusion gap を見つけ出し、それをイノベーションの機会として捉えることになります。
Chris は実用的な言葉遣いのテクニックとして、障害をスペクトラムとして考え、「some」を付けて表現することを挙げます。「some vision」「some hearing」というように。彼自身は法定盲ですが、色や光、大きな物体は見ることができます（03:29）。この小さな言葉の調整により、デザイン判断は「すべてか無か」の二元的判断から、連続的な区間上の漸進的なトレードオフへと変わります。
詳細
session は、デザイン時に確認すべき 5 つの感覚次元を提示します。視覚、聴覚、運動、音声、認知です（02:35）。この 5 つの次元を軸に、Apple は 4 つの実行可能な原則を提唱しています。
1. 複数の感覚をサポートする（08:54）
動画の字幕は最も典型的な例です。聾者や聴覚障害者にとって必要であり、図書館にいる人にとっても必要です。同じ情報は、少なくとも 2 つの感覚チャネルを持つ必要があります。
新機能の Accessibility Reader は、この点を極限まで追求しています（10:11）。画面内のあらゆるテキストを、視覚的なリーディング、音声のみの読み上げ、または音声とテキストのハイライトを同時に行う 3 つのモードに切り替えられます。サードパーティ app の Crouton はレシピアプリで、レシピの読み込みには 4 つの方法があります。From Image、From Camera、From Text、Hands Free モードです（11:27）。文字を打てない人は写真を撮り、画面を見られない人は文字を打ち、料理中に手が食材で汚れている人は音声でページをめくれます。同じ機能を、4 つの感覚チャネルで実現しています。
2. カスタマイズを提供する（12:46）
各感覚チャネルは、文字を大きくするだけでなく、個別にカスタマイズできるべきです。Accessibility Reader では、文字サイズの調整、配色の変更、San Francisco の高可読性字形への切り替え、フォント全体の変更が可能です（13:10）。
サードパーティ app の Carrot Weather は、レイアウト密度をスライダーで調整できます（13:39）。情報が密集したダッシュボード型レイアウトから、温度の 1 行だけのミニマルなインターフェースまで連続的に変化します。認知的負荷が高い人は最もシンプルなバージョンを選び、気象愛好家は最も高密度なバージョンを選べます。app が人に適応するのです。人が app に適応するのではありません。
3. Accessibility API を採用する（14:26）
VoiceOver、Switch Control、Voice Control、Larger Text。これらの API は何年も前から存在しています。これらを統合することは、ユーザーが外付けの物理ボタン 1 つですべての操作を完了できることを意味します。1 つのボタンで次の項目へ移動し、1 つのボタンで確定します（16:42）。Larger Text は文字サイズを 3 倍まで拡大しますが、その前提としてレイアウトがレスポンシブに調整されている必要があります。
session では Blackbox の例が挙げられています（17:35）。これは iPhone のセンサーを利用して謎解きをするゲームで、たとえば端末を水平に 360 度回転させるといったものです。低視力のプレイヤーは、VoiceOver が読み上げる極めてシンプルなヒント「手がかり：360 個の点線で構成された円」からも、謎を解くことができます。ゲームのメカニズム自体は変わっていません。audio label が追加されただけです。
4. inclusion debt を追跡する（18:45）
包括性は一度やれば終わりのものではありません。session はこれを技術的負債に例えています。1 ラウンドのデザインを終えても、新しい gap が見つかることはあります。それらを記録し、backlog に入れ、反復的に解決していきます。Accessibility Reader 自身も、より豊かなタイポグラフィオプションや、より多くのリーディングスタイルなど、まだ進化を続けています。
デザイン段階の重要な問い：「ユーザーが聾者、盲人、手の不自由な人、話せない人、認知的負荷が高い人だった場合、私の app で核心タスクを完了できるか？」 できなければ、それは inclusion gap であり、同時に製品の機会です。
session を通じて貫かれるもう 1 つの原則：「Nothing about us without us」（07:48）。障害を持つ人々に関するデザイン判断を行う際には、障害を持つ人々が参加しなければなりません。チーム内にいない場合は、少なくとも補助技術を使用しているユーザーをテストに参加させるべきです。
重要ポイント
1. app で inclusion gap 監査を実施する
なぜ価値があるか：5 つの感覚次元（視覚、聴覚、運動、音声、認知）でそれぞれ確認すると、通常 3 〜 5 個の潜在的な gap が見つかります。これらの gap はアクセシビリティの問題であるだけでなく、多くの場合一般ユーザーの痛みでもあります（騒がしい環境、両手が忙しい、言語が通じないなど）。
どう始めるか：app の核心タスクフロー（登録、メイン機能、決済）をリストアップします。各フローを 5 回通し、毎回ユーザーが 1 つの感覚能力を失ったと仮定します。どのステップで行き詰まるかを記録すれば、それが gap です。
2. 「カスタマイズ」を文字サイズから各感覚チャネルへ拡張する
なぜ価値があるか：多くの app の「アクセシビリティ設定」は Dynamic Type のサポートにとどまっています。しかし視覚障害者が必要とするのは配色と字形であり、聴覚障害者が必要とするのは字幕と触覚フィードバックであり、認知障害者が必要とするのはレイアウト密度です。Carrot Weather の密度スライダーは、具体的に参考にできるモデルです。
どう始めるか：核心インターフェースを 1 つ選び、少なくとも 2 つのレイアウトを提供します。情報密集版とミニマル版です。ユーザーが設定で切り替えられ、その選択を永続化します。
3. 動画と音声コンテンツに第 2 のチャネルを追加する
なぜ価値があるか：動画に自動字幕を付けること（Apple は既に Speech フレームワークでローカル文字起こしを提供しています）、音声コンテンツに自動でテキスト要約を生成すること。聾者にとって有益であると同時に、地下鉄で外放できない人にも有益です。
どう始めるか：SpeechAnalyzer または SFSpeechRecognizer を使用してローカル字幕を作成します。長い音声に対しては、Foundation Models を使用して段落ごとの要約を生成し、ジャンプを可能にします。
4. inclusion debt をエンジニアリングフローに組み込む
なぜ価値があるか：包括性は 1 回のスプリントで終わるものではなく、継続的な投資が必要です。gap を技術的負債として追跡することで、各イテレーションで固定の工数を割り当て、1 〜 2 件ずつ解決でき、永久にバックログに残ることを防げます。
どう始めるか：issue tracker に inclusion ラベルを作成します。ユーザー調査、ユーザビリティテスト、App Store レビューで発見した gap すべてにこのラベルを付けます。各スプリントで、10% の工数をこのバックログの処理に充てます。
5. 少なくとも 1 人の補助技術を使用している実ユーザーをテストに参加させる
なぜ価値があるか：シミュレーションテスト（たとえば自分で画面をオフにして VoiceOver を使う）は 30% の問題しか発見できません。残りの 70% は実ユーザーのみが明らかにできます。「Nothing about us without us」はデザイン原則であると同時に、品質保証の手段でもあります。
どう始めるか：地元の盲人・聾者協会に連絡するか、TestFlight の募集時に補助技術ユーザーを探していることを明記します。彼らに核心タスクを与え、どうやって完了するか、あるいは諦めるかを観察します。
関連セッション
- Customize your app for Assistive Access — Assistive Access は、認知障害ユーザーのために設計されたシンプルな iOS モードです。app がこのモードでどうインターフェースを再構築するかを見てみましょう。
- Evaluate your app for Accessibility Nutrition Labels — App Store に今年新たに追加された Accessibility ラベルにより、ユーザーはダウンロード前に app がどの補助機能をサポートしているかを知ることができます。
- Make your Mac app more accessible to everyone — Mac 版のアクセシビリティ API 統合。macOS 上での VoiceOver の特殊な動作とデスクトップのインタラクションモードが含まれます。
- Catch up on accessibility in SwiftUI — SwiftUI の accessibility modifier の全体像です。本 session で推奨される API 入門動画です。
コメント
GitHub Issues · utterances