WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
The practice of inclusive design

The practice of inclusive design

DesignAccessibilityInclusion
观看原视频

Highlight

Apple 把包容性设计拆成六个可检查的内容实践，帮助开发者从 App Store 截图、界面文案、无障碍、本地化、颜色和身份表达入手，让应用和游戏服务更广泛的人群。

核心内容

很多应用发布前都会认真检查崩溃、性能和截图尺寸，却很少检查截图里出现的人名、食物、节日和头像。开发者常从自己的生活经验取素材。社交 App 里是一群熟人去划船，待办 App 里是给 John 回电话、买生日晚餐，饮食 App 里是煎饼、披萨和汉堡。

这些内容看似无害，却会告诉用户一个事实：这个产品默认服务谁。App Store 每周有 5 亿访问者，覆盖 175 多个地区和 40 种语言。用户还没有下载应用，就已经从名称、预览视频、截图和营销文案判断自己是否被考虑到。

Apple 在这场演讲里没有发布新框架。它给出一套设计检查方法：讲多元故事，避免刻板印象，采用无障碍，按文化本地化，谨慎使用颜色，鼓励自我表达。

这套方法的重点是把“包容性”落到具体界面。一个齿轮按钮不能只让 VoiceOver 读出 “gear shape two”。一个家庭共享功能不能只提供父亲、母亲、孩子三个固定角色。一个姓名表单不能因为连字符、重音符号、长度或姓氏结构不同就拒绝输入。

开发者获得的是一份实践清单。它要求每个面向用户的内容点都接受同一个问题：这个界面对不同语言、能力、文化、性别、年龄和家庭结构的人是否成立。

详细内容

App Store 截图：先检查你在讲谁的故事

（04:18）第一项实践是 Tell diverse stories（讲多元故事）。Apple 指出，应用名称、描述、预览视频和截图会说明产品为谁而建。截图里的示例内容也要经过设计，而不能只取最熟悉的人名和场景。

Inclusive screenshot audit
1. social app: kayaking trip -> community service with a more diverse group
2. to-do app: return John's call -> return Abhi's call
3. to-do app: shop for dinner -> plan Diwali
4. to-do app: read a familiar book -> read Chinua Achebe
5. to-do app: practice an instrument -> practice sign language
6. food app: pancakes, pizza, hamburgers -> foods from more cultures

关键点：

  • social app 对应演讲中的社交应用截图示例。
  • kayaking trip 是开发者可能先想到的熟悉生活方式。
  • community service 把截图改成更多人能理解的公共场景。
  • return Abhi's call 用具体姓名替换默认熟人圈姓名。
  • plan Diwali 把待办事项换成超过十亿人会庆祝的节日。
  • read Chinua Achebe 引入较少被呈现的作者声音。
  • practice sign language 让截图主动呈现对聋人社区的包含。
  • foods from more cultures 提醒饮食应用不要只展示美国常见食物。

这个清单适合发布前检查 App Store 素材。每一张截图都问：这里的人名、活动、食物、节日和对话是否只来自开发团队最熟悉的生活。

刻板印象：让语言和功能都少做假设

（07:55）第二项实践是 Avoid stereotypes（避免刻板印象）。Apple 举了两个具体方向：语言里的性别二分，以及功能里的家庭角色假设。

Copy and role audit
1. unknown gender: he / she -> they
2. video greeting: Hey, guys! -> Hey, everyone!
3. placeholder avatar: masculine person icon -> non-gendered human icon
4. SF Symbols: use gender-neutral glyphs when a generic person is needed
5. family roles: father, mother, child -> family member
6. family size: fixed slots -> start with account owner, then let people add members

关键点：

  • he / she -> they 来自演讲中未知性别时使用中性代词的建议。
  • Hey, guys! -> Hey, everyone! 把视频和界面问候改成覆盖更多人的说法。
  • masculine person icon 会把“通用用户”默认为男性。
  • non-gendered human icon 避免头像占位符暗示性别。
  • SF Symbols 在演讲中被点名提供了可用于应用和游戏的中性字形。
  • father, mother, child 会排除单亲、同性父母、多代同堂、成年子女和监护人家庭。
  • family member 保留功能语义，同时放掉不必要的角色假设。

这里要做词语检查，也要做功能结构检查。演讲中的共享电影库示例说明，如果数据模型只接受父亲、母亲和孩子，界面文案再友好也无法服务其他家庭。

无障碍：让系统能力进入默认测试流程

（13:47）第三项实践是 Adopt accessibility（采用无障碍）。Apple 给出的第一种反例是图标按钮。用户进入应用后，VoiceOver 只读出 “gear shape two, button”。这说明系统知道它是齿轮图标，却不知道它在当前应用里代表账户设置。

Accessibility implementation checklist
1. Dynamic Type: use SwiftUI or UIKit text and layout systems
2. Bold Text: thicken non-text elements that affect legibility
3. VoiceOver glyph button: Gear shape two, button -> Account settings, button
4. VoiceOver state button: glyph button -> Remove favorite, button
5. VoiceOver order: make the prominent Post button read before top-left content
6. Test menu: VoiceOver, Increase Contrast, Reduce Transparency, Reduce Motion, Grayscale Color Filter
7. Control Center: add Text Size toggle for quick testing

关键点：

  • Dynamic Type 要求界面能覆盖 iOS 的文字大小范围。
  • SwiftUI or UIKit text and layout systems 是演讲中提到的自动适配入口。
  • Bold Text 开启后，非文本但影响可读性的圆点、线条等元素也要加粗。
  • Gear shape two, button -> Account settings, button 说明 VoiceOver 标签要表达业务功能。
  • Remove favorite, button 说明标签还可以反映按钮状态。
  • Post button read before top-left content 对应演讲中指定朗读顺序的例子。
  • VoiceOver、Increase Contrast、Reduce Transparency、Reduce Motion、Grayscale Color Filter 都是演讲建议放入 Accessibility Shortcut（辅助功能快捷方式）菜单的测试项。
  • Text Size toggle 可以放进 Control Center（控制中心），方便快速切换字号。

这部分要进入开发流程。演讲建议开发者亲自打开这些设置试用应用：灰度模式检查对颜色的依赖，静音状态检查对音频的依赖，大字号检查文本截断和布局裁切。

本地化：翻译文字之外，还要替换文化场景

（19:20）第四项实践是 Localize for culture（按文化本地化）。演讲先区分翻译和本地化。翻译处理语言、字长、书写系统、配音、字幕、时间、电话号码和货币。本地化还要处理文化含义。

Localization content checklist
1. idiom: Nine cows and one hair -> a drop in the bucket -> a tiny amount
2. app copy: Plan your vacation from A to Z -> Plan your vacation from beginning to end
3. cooking app in India: translate to Hindi -> adapt recipes and ingredients
4. recipe content: beef and sausages -> dishes relevant to local dietary customs
5. festival content: surface recipes typically eaten during local festivals
6. game content: avoid caricatures of real cultures in characters and environments

关键点：

  • Nine cows and one hair 是演讲中用来说明习语难以跨文化理解的中文表达。
  • a drop in the bucket 是对应英文习语。
  • a tiny amount 才是直接含义，最容易翻译。
  • Plan your vacation from A to Z 依赖英文字母顺序，放到韩语等语言里会失效。
  • Plan your vacation from beginning to end 使用直接语言，降低翻译成本。
  • translate to Hindi -> adapt recipes and ingredients 说明印度市场的烹饪应用不能只完成界面翻译。
  • beef and sausages 可能与当地饮食习惯和宗教文化冲突。
  • local festivals 提供了把内容做得更贴近当地生活的入口。
  • avoid caricatures 针对游戏角色和环境，避免把现实族群做成敌人、异域外星人或奇幻种族的素材。

Apple 在这里给出一个实用标准：如果一句文案依赖习语、俚语、幽默或隐喻，就优先改成直白表达。直白文案更容易理解，也更容易翻译。

颜色：同一个颜色在不同地区含义不同

（24:36）第五项实践是 Use color mindfully（谨慎使用颜色）。颜色有文化含义，也有可访问性问题。演讲举了 Stocks（股市）应用的例子：多数本地化版本用绿色表示上涨、红色表示下跌；地区设为中国大陆时，上涨显示为红色。

Color checklist
1. culture: green for gains, red for losses -> Mainland China uses red for gains
2. status dots: unread color dot + flagged color dot -> replace one dot with a glyph
3. contrast setting: test with Increase Contrast turned on
4. system palette: use iOS system colors to get high-contrast support
5. custom palette: calculate luminosity ratio between text and background
6. target ratio: aspire to at least 4.5:1 when Increase Contrast is on

关键点：

  • green for gains, red for losses 是很多地区的股票颜色习惯。
  • Mainland China uses red for gains 来自演讲中对 Stocks 本地化的说明。
  • replace one dot with a glyph 解决色盲用户无法只靠颜色区分“未读”和“已标记”的问题。
  • Increase Contrast 是演讲建议测试的系统设置。
  • iOS system colors 包含支持高对比度模式的额外颜色集合。
  • custom palette 需要开发者自己计算文字和背景的 luminosity ratio（亮度比）。
  • 4.5:1 是演讲建议在高对比度模式下努力达到的最低比例。

这部分最容易被误认为视觉细节。实际问题是信息编码。只用颜色表达状态，色盲用户可能看不到差异；颜色含义不按地区调整，用户可能得到相反理解。

自我表达：表单不要限制用户如何识别自己

（28:05）第六项实践是 Encourage self-expression（鼓励自我表达）。Apple 从姓名表单讲起。很多人的姓名包含连字符、重音符号，长度也可能超出常见限制。有些地区没有“名 + 姓”的结构。

Identity input checklist
1. name validation: allow hyphens and accents
2. name length: avoid fixed minimum and maximum assumptions
3. name structure: first name + last name -> full name field when appropriate
4. personal address: ask for preferred name
5. gender field: Male, Female, Other -> wide range of options plus custom entry
6. gender visibility: allow public or private
7. character creation: age, skin color, body type, hair, clothing, language, vocal tone
8. game design: do not bucket hair, clothing, or voice by gender when gender is not needed

关键点：

  • allow hyphens and accents 对应演讲中姓名校验失败的常见原因。
  • avoid fixed minimum and maximum assumptions 避免短名、长名被拒绝。
  • full name field 适合不需要拆分法定名的场景。
  • preferred name 让应用后续称呼用户时更贴近用户本人。
  • wide range of options plus custom entry 来自 Bumble 注册时提供多种性别选项并允许提交自定义项的例子。
  • allow public or private 让用户控制性别信息是否展示。
  • age, skin color, body type, hair, clothing, language, vocal tone 来自游戏 “Say No! More.” 的角色创建示例。
  • do not bucket hair, clothing, or voice by gender 说明当功能不需要性别时，可以不询问性别。

表单设计经常把产品假设写进数据库字段。演讲提醒开发者，先问这个字段是否真的需要，再决定输入方式。能不问就不问；必须问时，给用户表达空间和修改空间。

核心启发

  1. 做什么：给 App Store 截图做一套发布前内容审计。 为什么值得做：演讲指出截图、名称、预览视频和描述会在下载前告诉用户产品为谁而建。 怎么开始：列出所有截图中的人名、活动、食物、节日和对话，把默认熟人圈素材替换成更多文化和生活方式的示例。

  2. 做什么：给应用增加“文案包容性检查”脚本或人工清单。 为什么值得做：演讲给出具体替换，例如 he / she 改为 they，Hey, guys! 改为 Hey, everyone!。 怎么开始：扫描本地化字符串，标记性别二分、能力歧视词、习语、俚语和隐喻，再交给真实用户或本地化人员复查。

  3. 做什么：把无障碍设置加入每次 UI 回归测试。 为什么值得做：演讲建议使用 VoiceOver、Increase Contrast、Reduce Transparency、Reduce Motion、Grayscale Color Filter 和 Text Size 测试应用。 怎么开始：在测试清单中新增一轮系统设置测试；重点检查图标按钮的 VoiceOver 读法、大字号截断、灰度下状态是否可区分、静音时剧情或操作是否丢失。

  4. 做什么：为国际市场建立“翻译 + 内容替换”流程。 为什么值得做：演讲中的烹饪 App 即使翻译成印地语，仍可能因为牛肉和香肠等内容不符合当地饮食文化而失败。 怎么开始：每进入一个地区，先列出单位、货币、食物、节日、颜色和禁忌内容；让本地人员检查推荐内容和默认示例。

  5. 做什么：重做注册页里的姓名和身份字段。 为什么值得做：演讲指出姓名长度、连字符、重音符号、姓氏结构和性别选项都会影响用户是否能表达自己。 怎么开始：优先使用单个全名字段和 preferred name（偏好称呼）；性别字段只在产品确实需要时出现，并提供自定义、隐私控制和后续修改入口。

关联 Session

评论

GitHub Issues · utterances