WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Evaluate your app for Accessibility Nutrition Labels

Evaluate your app for Accessibility Nutrition Labels

アクセシビリティ
元の動画を見る

ハイライト

James（エンジニア）と Lisa（デザイナー、法的盲）が Landmarks app を共同で評価する形で、Accessibility Nutrition Labels の評価フローを最初から最後まで実演します。

主要内容

App Store のプロダクトページには膨大な数の app が並んでいますが、視覚障害のあるユーザーや色覚特性のあるユーザー、文字を 310% まで拡大しないと読めないユーザーは、ダウンロードしてから「この app は使えない」と気づくケースが少なくありません。Lisa は法的盲であり、最大文字サイズで日々の読書や仕事をこなしています。これまで彼女は、ある app が VoiceOver、Larger Text、Dark Interface に対応しているかどうかを、ダウンロード前に知る術がありませんでした。

Apple は 2025 年に Accessibility Nutrition Labels を発表し、app がサポートするアクセシビリティ機能を App Store のプロダクトページに直接表示できるようにしました。開発者が App Store Connect 上で申告し、ユーザーはダウンロード前にそれを確認できます。申告できる機能は次の 9 項目です。Sufficient Contrast、Dark Interface、Larger Text、Differentiate Without Color Alone、Reduced Motion、Voice Control、VoiceOver、Captions、Audio Descriptions。

評価方法は common tasks（共通タスク）マトリクスです。まず app のコア機能を洗い出し、初回起動・ログイン・購入・設定といった汎用フローを加えます。次に、それぞれの共通タスクに対して各アクセシビリティ機能を 1 つずつ突き合わせて検証します。共通タスクのうち 1 つでも完遂できないものがあれば、その機能は申告できません。本セッションでは James と Lisa が実際に開発中の Landmarks app を評価し、Larger Text のテストで collection の説明文が切れる、テキストフィールドが文字サイズに追従しないといった問題を発見し、申告の前にバグを修正することを決めました。最終的には 6 項目を「サポートあり」、2 項目を「対象外」（音声・映像コンテンツが無いため Captions と Audio Descriptions は空欄）として申告しました。

詳細

評価の出発点は共通タスクのリストです。James は（01:24）で次のように強調しています。ある機能を申告するには、その機能を使ってユーザーが app の共通タスクをすべて完了できなければなりません。共通タスクとは、app の主要機能に加えて、初回起動・ログイン・購入・設定といった汎用フローを指します。

コントラスト（Sufficient Contrast）（05:10）：前景と背景の間に十分なコントラスト比を確保する必要があります。デフォルトの配色で基準を満たさない場合は、Increase Contrast を有効化したときに基準を満たすようにします。Landmarks の方針は、デフォルト配色を高コントラストにし、基準を満たさない一部の色は Increase Contrast がオンのときに代替色へ切り替えるというものです。Light / Dark の両モードで検証する必要があります。

Dark Interface（06:06）：Dark Mode に対応するだけでなく、Smart Invert を有効にしたときに色が誤って反転されないかも検証します。とくに画像や動画などのメディアコンテンツは、本来の色を保つべきです。

Larger Text（07:00）：iOS 上で文字は最低でも 200% まで拡大できる必要があり、Dynamic Type の利用が推奨されます。レイアウトは拡大後の文字を収められるようにし、テキストの切れや重なりがあってはいけません。Lisa は個人的に 310% を必要とするため、可能であれば 200% を超える拡大にも対応することが望ましいとのことです。Landmarks では 235% でテストしたところ、collection の説明文が切れたり、編集画面のテキストフィールドが文字サイズに追従しないといった問題が見つかったため、申告前に修正することを決めました。

Differentiate Without Color Alone（10:24）：色覚特性のあるユーザーが情報を取りこぼさないよう、形状・アイコン・テキストを色と組み合わせて状態を伝えます。例えば削除ボタンであれば、赤色だけでなくゴミ箱アイコンも併用します。

Reduced Motion（11:26）：めまいを誘発しうるアニメーションには、ズーム / スライドのトランジション、点滅、自動再生されるアニメーション、視差効果などがあります。Reduced Motion を有効にしたときは、これらを単に削除するのではなく、別の表現に置き換えるべきです。

Voice Control と VoiceOver は同じアクセシビリティ API を共有しています（14:18）。Voice Control はインタラクティブな要素ごとのメタデータ（ボタンの名前、検索フィールドのラベルなど）に依存します。最も典型的なのは、アイコンのみのボタンに accessibilityLabel を付与するパターンです。

// Add an accessibility label

import SwiftUI

struct LandmarkDetailView: View {
  @Environment(ModelData.self) var modelData
  let landmark: Landmark

  var body: some View {
    @Bindable var modelData = modelData
    DetailContentView()
      .toolbar {
        ToolbarItemGroup {
          Button {
          } label: {
            Image(systemName: "square.arrow.up")
          }
					.accessibilityLabel("Share")
        }
      }
   }
}

ポイントは次の通りです。

  • Image(systemName: "square.arrow.up")：ボタンには共有アイコンしか表示されておらず、可視のテキストがありません。
  • .accessibilityLabel("Share")：ボタンのアクセシビリティ上の名前を Share と明示的に宣言しています。修飾子は Image ではなく Button に付与します。
  • Voice Control のユーザーが “Tap Share” と発話したときも、VoiceOver のユーザーがフォーカスしたときも “Share” と読み上げられます。1 か所の宣言で 2 つの支援技術が同時に恩恵を受けます。
  • Voice Control の評価では、音声コマンドのみで操作する必要があり、タッチ操作やカーソル操作で補ってはいけません（13:58）。

VoiceOver のテスト（14:53）：Accessibility Shortcut で VoiceOver を有効化し、ジェスチャーまたはキーボード操作のみですべての共通タスクを完了させます。Lisa はその場で、スワイプジェスチャーで collection を閲覧し、ダブルタップでアクティベートし、ランドマークを追加するまでの一連の流れを実演しました。

関係のない機能は申告しないこと（02:25）：Landmarks には音声・映像コンテンツが無いため、Captions と Audio Descriptions は空欄のままにし、「カバレッジを稼ぐ」目的で無理に申告したりはしません。網羅性よりも正確さを優先すべきです。

重要ポイント

  • やること：既存の app について、いますぐ共通タスクのリストを作る。

    • なぜ価値があるか：Accessibility Nutrition Labels を申告する入り口であり、アクセシビリティ評価における最小の実行単位でもあります。リストが無ければ、その後のテストは発散してしまいます。
    • どう始めるか：まずユーザーが app をダウンロードする主要な動機（3〜5 個）を書き出し、続いて初回起動・ログイン・購入・設定という 4 つの汎用フローを追加します。これらを Markdown のテーブルに保存し、列に 9 個のアクセシビリティ機能、行に共通タスクを配置します。

  • やること：235% / 310% の大文字サイズを QA のセルフチェック項目に組み込む。

    • なぜ価値があるか：Lisa のような大文字に強く依存するユーザーは、レイアウトに潜む最も難しいバグ（テキストフィールドが文字サイズに追従しない、説明文が切れる、など）をあぶり出してくれます。これらはデフォルトの文字サイズではまったく見えません。
    • どう始めるか：実機で「設定 > アクセシビリティ > 画面表示とテキストサイズ > さらに大きな文字」を有効化し、235% に設定してコアタスクを一通り走らせます。同時にすべての TextField が複数行に対応しているか、すべてのリストセルが文字サイズに合わせて高くなるかも確認します。

  • やること：「アイコンのみのボタン」すべてに .accessibilityLabel を付与する。

    • なぜ価値があるか：Voice Control と VoiceOver の両方が依存する、最低限のメタデータです。1 行のコードで 2 つの支援技術を同時に有効化できます。
    • どう始めるか：プロジェクト内で Image(systemName: が Button の中に出現する箇所を検索し、1 つずつ .accessibilityLabel("...") を追加します。命名は動詞や対象物の名前にします。例えば “Share”、“Delete”、“Add Landmark” などです。

  • やること：Dark Mode の受け入れ確認に Smart Invert を加える。

    • なぜ価値があるか：自分では Dark Mode に対応しているつもりでも、Smart Invert を有効にすると画像・動画・ブランドカラーが誤って反転され、体験が崩れている app は少なくありません。
    • どう始めるか：「設定 > アクセシビリティ > 画面表示とテキストサイズ > スマート反転」を有効化したうえで app を一通り使い、表示用の画像には .accessibilityIgnoresInvertColors(true) のような仕組みで反転を抑止します。

  • やること：内部 QA で済まさず、実際のユーザーと協力してアクセシビリティテストを行う。

    • なぜ価値があるか：Lisa はセッションの中で繰り返し “Nothing about us without us” と強調しています。どのアニメーションがめまいを誘発するか、どの文字サイズが本当に必要か——内部テストでは得られない信号は、当事者にしか分かりません。
    • どう始めるか：ユーザーリサーチ経由で VoiceOver ユーザー 1〜2 名と、大文字を必要とするロービジョンのユーザー 1 名をリモートテストに招きます。発見された課題は P3 のバックログではなく、リリースの blocker として扱います。

関連 Session

  • Customize your app for Assistive Access — 認知障害のあるユーザー向けに iOS をフォーカスした体験へとカスタマイズする話で、Accessibility Nutrition Labels とは別軸のアクセシビリティ系の取り組みです。
  • Make your Mac app more accessible to everyone — Mac プラットフォームにおけるアクセシビリティ API の実践。本セッションの iOS 評価手法と対比しながら読むと理解が深まります。
  • Principles of inclusive app design — デザインの段階からアクセシビリティに踏み込むセッションで、「なぜ」に答えるもの。本セッションは「どう申告するか」に答えます。

コメント

GitHub Issues · utterances