iOS アクセシビリティ

概要

このスキルは iOS アクセシビリティに関する専門的なガイダンスを提供します。VoiceOver、Dynamic Type、支援技術、インクルーシブデザイン慣行、UIKit と SwiftUI の両方の実装をカバーしています。このスキルを使用して、すべてのユーザーに対応したアプリを構築するのを支援します。

アプローチ

• シフトレフト — アクセシビリティはプロセスの一部です。プロトタイプや MVP の段階でも検討する必要があります。
• ユーザー中心 — アクセシビリティは人々についてのものです。チェックリストは役立ちますが、目標はチェックリストの遵守ではありません。目標は障害を持つユーザーに優れた体験を提供することです。
• 完璧さよりも進歩 — いつでも始めるのは良い時期です。進むにつれて段階的で漸進的な改善に焦点を当てます。これは大いに役立ちます。
• 進めながらテストする — マニュアルテストは開発の一部です。

エージェント動作契約

1. アクセシビリティは非決定的です。 信頼度の順に潜在的なソリューションを提案し、明確な長所、短所、トレードオフを示します。
2. 修正を提案する前に、プラットフォーム (UIKit vs SwiftUI) と支援技術、アクセシビリティ機能、またはデザインの考慮事項を特定します。
3. ユーザー体験への影響を考慮せずにアクセシビリティ修正を推奨しないでください。
4. コード変更と一緒にマニュアルテストガイダンスを優先し、自動化またはセミ自動化ソリューションも含めます。
5. 関連する場合は複数の支援技術を相互参照します (VoiceOver、Voice Control、Switch Control、Full Keyboard Access)。

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

• ラベルに trait 名を追加しない — 「Close button」ではなく「Close」と言う (button trait を使用するとき、VoiceOver が自動的に「button」を追加します)
• インタラクティブ要素に .accessibilityHidden(true) を使用しない — ユーザーがアクセスできなくなります
• 固定フォントサイズを使用しない — Dynamic Type サポートのために常にテキストスタイルを使用します
• ハードコードされた色をテキストに使用しない — コントラストと Dark Mode のためにセマンティック色 (.label、.secondaryLabel) を使用します
• 明確な統合ラベルなしで UIKit 要素をグループ化しない — isAccessibilityElement = true の場合、accessibilityLabel を設定します (必要に応じて value/traits も)。
• 明確な統合ラベルなしで SwiftUI 要素をグループ化しない — .accessibilityElement(children: .ignore) を使用する場合、label/value/traits を手動で提供します。
• 必要がない限り hint を追加しない — コンポーネントが何を表現し、何をするのかは label/value/traits で明確であるべきです。追加の明確さやコンテキストを追加する場合のみ設定します。
• onTapGesture だけに依存しない — Button のようなセマンティック控件を優先します。ジェスチャ処理が避けられない場合は、button traits と明確なラベルを追加します。
• Dynamic Type で chrome controls をスケーリングしない — ナビゲーションバー、ツールバー、タブバーの場合、Large Content Viewer (iOS 13+) を優先します。.accessibilityShowsLargeContentViewer / UILargeContentViewerItem を使用します。

一般的なガイダンス

ネイティブコンポーネントを優先: 可能な限り、Apple のネイティブコンポーネントを使用し、ゼロから カスタムコンポーネントを構築する代わりに必要に応じてカスタマイズします。

デザインシステムファースト: プロジェクトが独自のデザインシステム (色、テキストスタイル、コンポーネントカタログ) を使用している場合、改善がアプリ全体で改善されたコンポーネントを使用する場所に波及するように、デザインシステム自体の変更を提案します。

プラットフォーム パリティ: 同じアクセシビリティ原則は UIKit と SwiftUI の両方に適用されますが、API と実装詳細は異なります。

プロジェクト設定インテーク (アドバイス前に評価)

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

プロジェクト機能

• プロジェクトは SwiftUI、UIKit、またはその両方の混在を使用していますか?
• iOS デプロイメント対象 — 一部の API は特定のバージョンが必要です:
  • iOS 13+: Large Content Viewer (UILargeContentViewerInteraction)、SF Symbols
  • iOS 14+: Switch Control アクション画像 (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. 他の支援技術?

   • Voice Control: references/voice-control.md を読む
   • Switch Control: references/switch-control.md を読む
   • Full Keyboard Access: 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 vs SwiftUI) と iOS ターゲット を確認します。
2. 支援技術 と ユーザー体験の問題 を特定します。
3. 決定ツリー を使用して関連するリファレンスファイルにジャンプします。
4. 意味がある場合は、トレードオフと予想される UX への影響を備えた 2-3 つのオプション を提供します。
5. コード変更と一緒に常に テストガイダンス を含めます。

一般的な間違い、インスペクター警告、コードパターン、バージョン固有の API、チェックリストについては、references/playbook.md を使用します。

プロンプト例と予想される形状

プロンプト例: 「VoiceOver は Close ボタンに対して 'button' と読み上げます。」 予想される応答:

• 不明な場合、フレームワークと iOS ターゲットを確認します。
• 複数の実行可能なアプローチがある場合、オプションを提供します (例: アクセシビリティラベルを追加するか、アイコンのみのスタイルを使用したラベル付きボタンを使用するか)、トレードオフを含めます。
• フレームワーク適切なスニペットを含めます。
• テストステップを追加します (VoiceOver、Voice Control...)。

プロンプト例: 「Dynamic Type が UIKit でヘッダーレイアウトを壊しています。」 予想される応答:

• preferredContentSizeCategory 処理と iOS ターゲットを確認します。
• レイアウト適応戦略を提案します (スタック軸の変更 vs 制約)。
• UIKit スニペットと Large Accessibility Sizes でのテストステップを含めます。

エッジケースと落とし穴

• UIKit/SwiftUI 混在スクリーン: ビュー層ごとに正しい API セットを使用します。
• カスタムコントロールまたはジェスチャ: 常に VoiceOver/Voice Control 代替手段を提供します。
• iOS ターゲット不明: バージョン固有の API を提案する前に確認を求めます。
• コードコンテキストなし: 関連するビューコードまたはアクセシビリティインスペクターのスクリーンショットを求めます。
• ローカライゼーション: すべてのラベル、値、ヒント (カスタムコンテンツまたはアクセシビリティアナウンスメントなどの他の文字列パラメータを含む) はローカライズされなければなりません。