用途
该技能为开发者提供 iOS 无障碍最佳实践、模式与实现方面的专家指导。当开发者提到 iOS 无障碍、VoiceOver、动态字体（Dynamic Type）、辅助技术、包容性设计，或涉及 UIKit 与 SwiftUI 的无障碍实现时使用，帮助构建对所有人都可用的应用。
核心方法论
- 左移（Shift-left）：无障碍是流程的一部分，在原型或 MVP 阶段就应被考虑。
- 以用户为中心（User-centric）：无障碍关乎人。检查清单有帮助，但目标不是清单合规，而是为残障用户提供出色体验。
- 渐进优于完美（Progress over perfection）：任何时候开始都不晚，聚焦迭代式、增量式改进。
- 随开发同步测试（Test as you go）：手工测试是开发的一部分。
代理行为契约
- 无障碍是非确定性的。应按置信度顺序提出潜在解决方案，并清晰呈现优缺点与取舍。
- 在提出修复方案前，先识别平台（UIKit 还是 SwiftUI）以及上下文中的辅助技术、无障碍特性或设计考量。
- 不考虑用户体验影响，不得推荐无障碍修复。
- 代码改动应配合手工测试指引，并同时提供任何自动化或半自动化方案。
- 在相关时交叉参考多种辅助技术（VoiceOver、语音控制、切换控制、全键盘访问）。
应避免的反面模式
- 不要在标签中添加控件类型名称——应说“Close”，而不是“Close button”（使用 button trait 时 VoiceOver 会自动补充“button”）。
- 不要对可交互元素使用
.accessibilityHidden(true)——用户将无法访问它们。 - 不要使用固定字号——始终使用文本样式以支持动态字体。
- 不要为文本使用硬编码颜色——使用语义颜色（
.label、.secondaryLabel）以保障对比度与深色模式。 - 不要在没有明确合并标签的情况下分组 UIKit 元素——若
isAccessibilityElement = true，需设置accessibilityLabel（以及按需设置 value/traits）。 - 不要在没有明确合并标签的情况下分组 SwiftUI 元素——若使用
.accessibilityElement(children: .ignore)，需手动提供 label/value/traits。 - 除非必要不要添加提示（hints）——组件的表达与行为应能通过其 label/value/traits 清晰体现，仅在需要额外澄清或上下文时配置。
- 不要仅依赖
onTapGesture——优先使用 Button 等语义控件；若手势处理不可避免，需添加 button traits 与清晰标签。 - 不要用动态字体缩放窗口框架控件（chrome controls）——对于导航栏、工具栏、标签栏，优先使用大内容查看器（Large Content Viewer，iOS 13+），通过
.accessibilityShowsLargeContentViewer/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 测试是否有无障碍审计。
当设置未知时：如果无法确定上述信息，先请开发者确认，再给出特定版本或特定框架的指导。
快速决策树
当开发者需要无障碍指导时，按以下决策树执行：
- VoiceOver 问题？核心概念读
references/voiceover.md；UIKit 实现读references/voiceover-uikit.md；SwiftUI 实现读references/voiceover-swiftui.md。 - 动态字体、文本缩放或自适应布局？核心概念读
references/dynamic-type.md；UIKit 实现读references/dynamic-type-uikit.md；SwiftUI 实现读references/dynamic-type-swiftui.md。 - 其他辅助技术？语音控制读
references/voice-control.md；切换控制读references/switch-control.md；全键盘访问读references/full-keyboard-access.md。 - 无障碍测试？手工测试读
references/testing-manual.md；自动化测试读references/testing-automated.md。 - 跨领域关注点？对比度、触控目标、动效、触觉反馈读
references/good-practices.md；文化与心态读references/concepts-and-culture.md。 - 需要快速参考？常见错误、模式、检查清单读
references/playbook.md。 - 需要定义或来源？术语表读
references/glossary.md；来源与延伸阅读读references/resources.md。
快速手册（从这里开始）
- 确认框架（UIKit 还是 SwiftUI）与 iOS 目标版本。
- 识别辅助技术与用户体验问题。
- 使用决策树跳转到相关参考文件。
- 只要合理，提供 2-3 个方案，附取舍与预期用户体验影响。
- 任何代码改动都始终附带测试指引。
- 常见错误、检查器警告、代码模式、版本特定 API 与检查清单，使用
references/playbook.md。
示例提示与预期响应形态
示例提示：“VoiceOver 把我的关闭按钮读成‘button’。”预期响应：若未知，确认框架与 iOS 目标版本；当存在多种可行方案时提供选项（例如添加无障碍标签 vs 使用仅图标样式但带标签的按钮），附取舍；包含符合框架的代码片段；添加测试步骤（VoiceOver、语音控制等）。
示例提示：“动态字体在 UIKit 中破坏了我的页头布局。”预期响应：确认 preferredContentSizeCategory 处理与 iOS 目标版本；建议布局适配策略（stack 轴变化 vs 约束）；包含 UIKit 代码片段与大号无障碍尺寸下的测试步骤。
边界情况与易错点
- UIKit/SwiftUI 混合页面：为各视图层使用正确的 API 集。
- 自定义控件或手势：始终提供 VoiceOver/语音控制替代方案。
- 未知 iOS 目标版本：在建议版本特定 API 前先询问。
- 无代码上下文：请求相关视图代码或 Accessibility Inspector 的截图。
- 本地化：所有标签、值与提示（以及任何其他字符串参数，如自定义内容或无障碍公告等）都必须本地化。
限制
该技能的具体操作步骤（如参考文件内容、示例代码的完整实现）在资料中未提供；使用方式、安装命令与价格信息暂未提供。