ios-accessibility

iOS のアクセシビリティ

概要

このスキルでは、VoiceOver、Dynamic Type、支援技術、インクルーシブデザインの実践、UIKit と SwiftUI の実装など、iOS のアクセシビリティに関する専門的なガイダンスを提供します。このスキルを活用して、誰もが使えるアプリの開発を支援してください。

アプローチ

• 早い段階から取り組む — アクセシビリティは開発プロセスの一部です。プロトタイプや MVP の段階から考慮する必要があります。
• ユーザー中心 — アクセシビリティは人のためのものです。チェックリストは役に立ちますが、目指すのはチェックリストを満たすことではありません。障害のあるユーザーに優れた体験を提供することが目標です。
• 完璧を目指すより、改善を重ねる — いつ始めても遅くありません。少しずつ、反復的に改善していきましょう。その効果は大きなものになります。
• 開発しながらテストする — 手動テストも開発の一部です。

エージェントの行動規範

1. アクセシビリティの解決策は一律ではありません。 確信度の高い順に解決策を提案し、それぞれのメリット、デメリット、トレードオフを明確に示してください。
2. 修正を提案する前に、対象のプラットフォーム（UIKit と SwiftUI のどちらか）と、状況に関係する支援技術、アクセシビリティ機能、またはデザイン上の考慮事項を特定してください。
3. ユーザー体験への影響を考慮せずに、アクセシビリティの修正を推奨しないでください。
4. コード変更とあわせて、手動テストの手順も優先して案内してください。自動または半自動の解決策も併記してください。
5. 関連する場合は、複数の支援技術を照らし合わせてください（VoiceOver、Voice Control、Switch Control、Full Keyboard Access）。

避けるべきアンチパターン

• ラベルに特性名を追加しない — 「閉じる」とし、「閉じるボタン」とはしません（ボタンの特性がある場合、VoiceOver が「ボタン」を自動的に付加します）
• 操作可能な要素に .accessibilityHidden(true) を使用しない — ユーザーがその要素にアクセスできなくなります
• フォントサイズを固定しない — Dynamic Type に対応するため、必ずテキストスタイルを使用してください
• テキストにハードコードした色を使用しない — コントラストとダークモードに対応するため、セマンティックカラー（.label、.secondaryLabel）を使用してください
• 明確な結合ラベルを設定せずに UIKit の要素をグループ化しない — isAccessibilityElement = true の場合は、必要に応じて accessibilityLabel（および値や特性）を設定してください。
• 明確な結合ラベルを設定せずに SwiftUI の要素をグループ化しない — .accessibilityElement(children: .ignore) を使用する場合は、ラベル、値、特性を手動で指定してください。
• 必要がない限り、ヒントを追加しない — コンポーネントが何を表し、何を行うかは、ラベル、値、特性で明確に伝わるようにしてください。明確さや補足情報の追加が必要な場合にのみ設定してください。
• onTapGesture だけに頼らない — Button など、セマンティックなコントロールを優先してください。ジェスチャー処理が避けられない場合は、ボタンの特性と明確なラベルを追加してください。
• Dynamic Type でクロームコントロールを拡大しない — ナビゲーションバー、ツールバー、タブバーでは、Large Content Viewer（iOS 13 以降）を優先してください。.accessibilityShowsLargeContentViewer](https://developer.apple.com/documentation/swiftui/view/accessibilityshowslargecontentviewer(content:)) / UILargeContentViewerItem を使用してください。

一般的なガイダンス

ネイティブコンポーネントを優先する： 可能な限り、カスタムコンポーネントを一から作るのではなく、Apple のネイティブコンポーネントを使い、ニーズに合わせてカスタマイズしてください。

まずデザインシステムを確認する： プロジェクト独自のデザインシステム（カラー、テキストスタイル、コンポーネントカタログ）がある場合は、デザインシステム自体への変更を提案してください。改善したコンポーネントを使用するアプリ全体で、改善の効果が広がります。

プラットフォーム間の一貫性： アクセシビリティの原則は UIKit と SwiftUI のどちらにも適用されますが、API と実装の詳細は異なります。

プロジェクト設定の確認（助言の前に評価）

アクセシビリティに関するガイダンスを提供する前に、次の点を確認してください。

プロジェクトの機能

• プロジェクトでは SwiftUI、UIKit、またはその両方を使用していますか？
• iOS のデプロイメントターゲット — 一部の API には特定のバージョンが必要です。
  • iOS 13 以降：大きなコンテンツビューアー（UILargeContentViewerInteraction）、SF Symbols
  • iOS 14 以降：スイッチコントロールのアクション画像（UIAccessibilityCustomAction.init(name:image:actionHandler:)）
  • iOS 15 以降：AccessibilityFocusState、.accessibilityRotor
  • iOS 16 以降：.accessibilityRepresentation、.accessibilityActions { } 構文
  • iOS 17 以降：.sensoryFeedback
• 最小 OS バージョンを確認する — プロジェクト設定で #available のチェックとデプロイメントターゲットを確認します

プロジェクトの規約

• デザインシステム — プロジェクト独自のデザインシステム（カラー、テキストスタイル、UI コンポーネントカタログ）を定義していますか？適切な場合は、機能ごとに変更するだけでなく、デザインシステムの変更を提案します。
• セマンティックカラーとテキストスタイル — セマンティックカラー（.label、.systemBackground）やテキストスタイル（UIKit の .preferredFont(forTextStyle:)、SwiftUI の .font(.body)）を使用していますか？それともハードコードされた値を使用していますか？
• 既存のアクセシビリティパターン — .accessibilityLabel、.accessibilityTraits などを検索し、プロジェクトのスタイルに合わせます。
• ローカライズ — アクセシビリティラベル、値、ヒントはローカライズする必要があります。プロジェクトのローカライズ規約に合わせます。
• UI の構築方法 — Interface Builder（XIB／Storyboard）ですか？それともコードのみですか？
• カスタムジェスチャ — カスタムジェスチャにアクセシブルな代替手段が必要かどうかを確認します。
• アクセシビリティテストのカバレッジ — アクセシビリティを監査する既存の UI テストはありますか？

設定が不明な場合

上記を判断できない場合は、バージョン固有またはフレームワーク固有のガイダンスを提供する前に、開発者に確認します。

クイック決定ツリー

開発者がアクセシビリティに関するガイダンスを必要とする場合は、この決定ツリーに従います。

1. VoiceOver の問題ですか？

   • 基本概念：references/voiceover.md を読みます
   • UIKit での実装：references/voiceover-uikit.md を読みます
   • SwiftUI での実装：references/voiceover-swiftui.md を読みます

2. Dynamic Type、テキストの拡大、またはアダプティブレイアウトですか？

   • 基本概念：references/dynamic-type.md を読みます
   • UIKit での実装：references/dynamic-type-uikit.md を読みます
   • SwiftUI での実装：references/dynamic-type-swiftui.md を読みます

3. その他の支援技術ですか？

   • 音声コントロール：references/voice-control.md を読みます
   • スイッチコントロール：references/switch-control.md を読みます
   • フルキーボードアクセス：references/full-keyboard-access.md を読みます

4. アクセシビリティのテストですか？

   • 手動テスト：references/testing-manual.md を読みます
   • 自動テスト：references/testing-automated.md を読みます

5. 複数の領域にまたがる懸念事項ですか？

   • コントラスト、ターゲット、動き、触覚フィードバック：references/good-practices.md を読みます
   • 文化と考え方：references/concepts-and-culture.md を読みます

6. クイックリファレンスが必要ですか？

   • よくある間違い、パターン、チェックリスト：references/playbook.md を読みます

7. 定義や情報源が必要ですか？

   • 用語集：references/glossary.md を読みます
   • 情報源と参考資料：references/resources.md を読みます

クイックプレイブック（まずはこちら）

1. フレームワーク（UIKit と SwiftUI のどちらか）と iOS のターゲットを確認します。
2. 支援技術と ユーザーエクスペリエンス上の問題を特定します。
3. 決定木を使って、関連するリファレンスファイルに進みます。
4. 適切な場合は、トレードオフと想定される UX への影響を示した 2～3 個の選択肢を提示します。
5. コードを変更する場合は、必ずテスト方法もあわせて説明します。

よくある間違い、インスペクタの警告、コードパターン、バージョン固有の API、チェックリストについては、references/playbook.md を参照してください。

プロンプトの例と期待される回答形式

プロンプトの例：「VoiceOver が閉じるボタンを「ボタン」と読み上げます。」 期待される回答：

• 不明な場合は、フレームワークと iOS のターゲットを確認します。
• 実現可能な方法が複数ある場合は、トレードオフを示して選択肢を提示します（たとえば、アクセシビリティラベルを追加する方法と、アイコンのみのスタイルを使ったラベル付きボタンにする方法）。
• フレームワークに適したコード例を含めます。
• テスト手順（VoiceOver、Voice Control など）を追加します。

プロンプトの例：「UIKit で Dynamic Type を使うと、ヘッダーのレイアウトが崩れます。」 期待される回答：

• preferredContentSizeCategory の処理と iOS のターゲットを確認します。
• レイアウトの適応方法（スタックの軸を変更する方法と制約を使う方法など）を提案します。
• UIKit のコード例と、大きなアクセシビリティサイズでのテスト手順を含めます。

例外的なケースと注意点

• UIKit と SwiftUI が混在する画面：ビューのレイヤーごとに適切な API セットを使います。
• カスタムコントロールやジェスチャー：必ず VoiceOver／Voice Control に対応する代替手段を用意します。
• iOS のターゲットが不明：バージョン固有の API を提案する前に確認します。
• コードのコンテキストがない：関連するビューのコード、または Accessibility Inspector のスクリーンショットを求めます。
• ローカライズ：ラベル、値、ヒント、およびカスタムコンテンツやアクセシビリティ通知などの文字列パラメーターは、すべてローカライズする必要があります。