Meet Assistive Access

ハイライト

iOS 17 と iPadOS 17 では Assistive Access（補助アクセス）が導入されました。信頼できるサポーターが設定で構成するシステムレベルのモードで、デバイス UI をコア機能に絞ります。サードパーティ App は変更なしでこのモードで動作し、適応レイアウトの App は Info.plist の 1 キーで全画面表示を有効にできます。

主要内容

iPhone と iPad は強力ですが、認知障害のある人にとって選択肢や操作が多すぎると障壁になります。一般ユーザーが直面するのは数十の App アイコン、通知、検索、Widget などで、情報の選別、操作経路の記憶、無関係な刺激の抑制が求められます。Apple のアクセシビリティチームは VoiceOver やアシスティブタッチで視覚・運動の課題に対応してきましたが、認知障害への支援には空白がありました。

Assistive Access はその空白を埋めます。ロック画面、ホーム画面、各 App 内の操作まで含む完全なシステムレベルモードです。

信頼できるサポーターが「設定」App で構成します。実行可能な App の選択、バッテリーアイコンの表示有無、ロック画面の壁紙設定などです。設定後はアクセシビリティショートカットまたは設定の切り替えで Assistive Access に入ります。

このモードでは全く異なる UI が表示されます。カスタム壁紙と通知表示のロック画面、より大きな App アイコンと目立つ文字のホーム画面。Apple は 5 つのコア機能向けに専用 App を書き直しました：電話（Calls）、メッセージ（Messages）、音楽（Music）、カメラ（Camera）、写真（Photos）。各 App は最基本の機能経路だけを残し、余分なオプションを削除します。

サードパーティ App のデフォルトは自動互換です。縮小された領域で動作し、画面下部に大きな戻るボタンがあります。戻るを押すとホーム画面に戻ります。App 内にハードコードされたレイアウトがあっても Assistive Access で崩れない設計です。

App がすでに適応レイアウト（固定画面サイズに依存しない）なら、Info.plist の 1 キーで全画面表示を申請でき、下部戻るボタン領域を除いた利用可能面積全体を使えます。

詳細

3 つの設計原則

（02:55）Assistive Access の設計は 3 原則に基づきます。

第 1 に、選択肢を減らす。 各ステップの選択が少ないほど決定しやすくなります。ホーム画面は許可された App のみ、各 App 内はコア機能経路のみ、余分なナビゲーション階層を削除します。

第 2 に、エラー防止と回復。 ファイル削除のような結果を伴う操作には明確な確認を示し、ユーザーが結果を理解してから確定します。時間制限のある操作を減らし、すべての操作を簡単に取り消せるようにします。

第 3 に、馴染みがあり予測可能な操作。 文字と画像のマルチモーダルで情報を提示し、一貫した操作パターンで学習コストを下げます。

サードパーティ App のデフォルト動作

（04:46）サードパーティ App は Assistive Access で「そのまま」動作します。システムが自動で 2 つ行います。

1. 画面下部に大きな戻るボタンを追加
2. 戻るボタン用のスペースのため App の描画領域を縮小

デバイス画面サイズに基づくハードコードレイアウトでも表示が壊れません。戻るでホーム画面に戻ります。

コードも適応も不要。これがデフォルトです。

全画面モードの有効化

（05:29）App が適応レイアウトをサポートしている場合、Info.plist に 1 キーを追加して全画面表示を申請できます。

<key>UISupportsFullScreenInAssistiveAccess</key>
<true/>

YES にすると、システムは下部戻るボタンを追加しません。App の描画領域は画面全体に拡張されます。

キーポイント:

• 適応レイアウトを使っている場合のみ YES にすべきです。画面サイズの固定前提があると全画面でレイアウト異常の可能性
• YES でも画面上部のステータスバーは残り、下部の余分な戻る領域はなくなります
• SwiftUI と UIKit の両方の App に適用されます

SwiftUI の適応レイアウト戦略

（06:28）SwiftUI 開発者は手動位置計算ではなく Stacks と Grids をレイアウトコンテナに使います。

struct ContentView: View {
    var body: some View {
        VStack {
            HStack {
                Text("タイトル")
                Spacer()
                Button("アクション") { }
            }
            LazyVGrid(columns: [GridItem(.adaptive(minimum: 80))]) {
                ForEach(items) { item in
                    ItemView(item: item)
                }
            }
        }
        .padding()
    }
}

キーポイント:

• VStack と HStack はコンテナサイズに自動適応し、手動 frame は不要
• LazyVGrid と .adaptive(minimum:) で幅に応じて列数を自動調整
• .padding() などはシステムのセーフエリアから余白を計算
• UIScreen.main.bounds などの固定サイズ値は使わない

UIKit の適応レイアウト戦略

（06:56）UIKit 開発者は Safe Area と Layout Guide に依存します。

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()

        let label = UILabel()
        label.text = "Hello"
        label.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(label)

        NSLayoutConstraint.activate([
            label.topAnchor.constraint(
                equalTo: view.safeAreaLayoutGuide.topAnchor,
                constant: 20
            ),
            label.leadingAnchor.constraint(
                equalTo: view.safeAreaLayoutGuide.leadingAnchor,
                constant: 16
            ),
            label.trailingAnchor.constraint(
                equalTo: view.safeAreaLayoutGuide.trailingAnchor,
                constant: -16
            )
        ])
    }
}

キーポイント:

• view.topAnchor 直接ではなく safeAreaLayoutGuide を使い、システム要素に隠れないようにする
• Assistive Access 全画面モードでは Safe Area が自動調整され、下部戻るボタンの占有が除かれる
• safeAreaInsets で実行時のセーフエリア値を読み、カスタムレイアウトに使える
• デバイス型番ベースのサイズ判定はハードコードしない

重要ポイント

1. 既存 App で Assistive Access 全画面を有効化

   • レイアウトが完全適応か確認。SwiftUI Stacks/Grids または UIKit Auto Layout + Safe Area なら Info.plist に UISupportsFullScreenInAssistiveAccess = YES を 1 行追加
   • 価値：コスト最小のアクセシビリティ改善。1 設定で認知障害ユーザー体験が向上
   • 始め方：ローカルで Assistive Access に入り、デフォルト動作を観察してから全画面を判断

2. ハードコードレイアウトのページを改修

   • UIScreen.main.bounds、UIDevice.current.model などを Safe Area と適応レイアウトに置換
   • 価値：Assistive Access 以外にも Split View、Stage Manager、外部ディスプレイで有利
   • 始め方：Xcode の View Hierarchy でハードコードビューを特定し、Auto Layout 制約または SwiftUI Stacks に置換

3. 認知障害向け簡素 UI を設計

   • App 内トグルで高度機能を隠し、フォントとボタンを拡大、ナビゲーション階層を減らす
   • 価値：すべての認知障害ユーザーがシステム Assistive Access を使うわけではない。App 内簡素モードのハードルは低い
   • 始め方：Assistive Access の 3 原則（選択肢削減、エラー防止、予測可能操作）を参考に、設定に「簡素モード」スイッチを追加

4. エラー処理インタラクションを見直す

   • 削除、支払い、ログアウトなどに十分な確認があるか確認
   • 価値：良いエラー防止は認知障害ユーザーだけでなく全ユーザーに価値がある
   • 始め方：不可逆操作を監査し、確認ダイアログと取り消し経路を追加

関連セッション

• Build accessible apps with SwiftUI and UIKit — SwiftUI と UIKit の最新アクセシビリティ進展。Assistive Access の適応レイアウト要件と直接関連
• What’s new in SwiftUI — Assistive Access 全画面適応レイアウトの基盤となる SwiftUI の新レイアウト能力
• What’s new in UIKit — 適応的なモダン UI を構築する UIKit の最新強化