操作系统提供的辅助功能设置应被应用继承而非重新实现一套
别名: 系统辅助设置 · prefers-reduced-motion · Dynamic Type · 继承系统设置
概念解释
字号、粗体、对比、减少动效、是否朗读屏幕，用户已经在操作系统里设过一次。应用要做的是读这些偏好并继承（inherit OS accessibility settings）：Web 上的 prefers-reduced-motion、prefers-contrast、prefers-color-scheme，iOS 的 Dynamic Type 与 Reduce Motion，Android 的 Font scale 与动画时长缩放。另做一套应用内的「无障碍开关」去复刻这些能力，等于要求用户在每个产品里再设置一遍，而且两套值从第一天起就会分叉。
继承不是「做个跟随系统的主题开关」那么窄。它是把系统已经表达过的身体与情境条件，当成应用排版和运动的输入，而不是再发明一份平行的控制面。
机制
操作系统把辅助偏好暴露成平台 API 和媒体查询，正是为了让所有前台应用共用同一份用户模型。用户在系统里把字号拧到最大，是在对所有应用说话。应用如果只用自己的 font-size: 14px 和自己的动效时间轴，等于把这份用户模型丢在门口。重新实现的那一套还要维护开关、存储、迁移，并且永远赶不上系统新增的项（如每页减少动画、区分不靠颜色、关闭闪烁）。
第二层是信任。辅助功能设置是跨应用的契约：用户改一次，期望走进任何应用都还在。应用另起炉灶，用户无法判断「这里听谁的」。继承把契约保持为一条；平行实现把契约拆成 N 条，每一条都可能是错的。
怎么研究
在系统里打开加大字号、减少动效、增强对比，分别打开一个「声称跟随系统」的应用和一个「有自己无障碍页」的应用，记录哪些系统项被映射、哪些被忽略、应用内开关的默认值是否等于系统当前值。Web 用浏览器的媒体查询仿真；原生用辅助功能检查器读 trait / Configuration。
自变量：系统偏好组合、应用是否声明继承、是否另有内置开关。 因变量：实际字号/动效/对比是否随系统变、映射覆盖了系统的哪几项、用户能否说出「此刻生效的是哪一套」。
边界
游戏、绘图、地图有时必须锁住视口单位，不能无上限跟着 Dynamic Type 涨；这时继承的方式是提供「按系统缩放界面控件、内容区另有阅读模式」，而不是完全不读系统。嵌入式 WebView 未必能收到外壳应用已经读过的偏好，需要把系统值往里传。企业托管设备可能锁死系统项，应用再提供一个本地覆盖是逃生门，不是默认路径。系统没有的能力（如「简化语言」）本来就不存在可继承的源，应用自己做一档不算平行复刻。
怎么落地
- 字号接到 Dynamic Type / Font scale / 浏览器默认字体，而不是写死像素；动效用
prefers-reduced-motion把非必要动画变成切切或缩短。 - 对比与配色跟
prefers-contrast、系统高对比、深色模式走，不要只在应用里做一套皮肤。 - 应用内若要提供「比系统更大」，做成叠加在系统值之上的偏移，而不是替换。
- 验证：只改系统设置、不碰应用，打开应用看字号、动效、对比是否已经变。系统加大、应用仍是设计稿上的 14px，就是没有继承。把系统减少动效打开，看启动动画和页面切换还在不在跑满时长。