组件系统要包含行为和状态

组件不仅是外观复用。一个按钮组件至少涉及标签、尺寸、图标位置、点击行为、键盘操作、焦点、加载、禁用和错误恢复。表单字段还涉及标签、说明、必填、格式、错误、成功和自动填充。

可以为常用组件建立状态表：

Framer 等工具把 Component、Variant、Hover 和 Transition 展示得很直观，适合学习组件与状态之间的关系。^[1] 交付时仍要验证实际代码。设计工具中的 Hover Variant 不会自动补齐键盘、触摸、焦点和辅助技术行为。

组件的一致性也需要留出合理差异。同类行动使用同一模式，用户可以复用经验；主要行动和次要行动则需要形成对比。一致性要求相同含义使用相同表达，不要求所有内容具有相同外观。^[2]

响应式设计从内容和容器出发

响应式检查不应只看三张 Desktop、Tablet 和 Phone 画面。真实窗口尺寸连续变化，系统字体、浏览器缩放、键盘弹出和横竖屏都会影响可用空间。

Framer 中的 Fixed、Fill、Fit Content、Viewport、Relative 和 Absolute，提供了一组理解布局的入口。^[1]

• 固定尺寸适合确实不会随内容增长的对象；
• 填充尺寸适合占用父容器可分配空间；
• 内容决定尺寸适合标签、按钮和会随子项增长的容器；
• 视口尺寸适合有明确全屏意图的区块；
• 正常文档流更容易跟随内容变化；
• 绝对定位需要更严格地验证遮挡和断点。

判断元素采用哪种模式，要同时看父容器、方向、内边距、可用空间和内容增长。只看子元素本身，容易在文案更长或语言改变后失效。

断点可以在内容开始拥挤、层级被破坏或操作区域不足时出现，不必完全按照设备名称划分。验收时可以缓慢拖动窗口，观察布局在哪个宽度开始难以使用，再决定是否增加规则。

用真实内容做压力测试

占位文案会掩盖很多问题。交付前至少准备以下状态：

• 最短与最长标题；
• 长姓名、长公司名和长电子邮箱；
• 零条、一条和大量数据；
• 图片缺失、加载失败和极端宽高比；
• 免费、付费、折扣和高位数金额；
• 表单错误、网络中断和重复提交；
• 权限不足、账号过期和空状态；
• 用户将文字放大；
• 一种文字更长的目标语言；
• 从右向左书写的界面。

这些状态可以进入 Storybook、组件预览或专门测试页面。若每次都依靠评审者临时输入，回归检查很难稳定。

可访问性从原生语义开始

网页的视觉结构需要对应代码结构。标题应当表达文档层级，链接用于导航，按钮用于触发动作，列表和表格使用与内容相符的元素，表单控件具有明确标签。

浏览器和辅助技术已经为原生 HTML 提供大量语义与键盘行为。可以使用原生元素时，优先使用原生元素。自定义控件会把焦点管理、键盘交互、状态同步和辅助技术兼容的责任交给开发者。

一轮基础检查可以包括：

1. 不使用鼠标，仅用键盘完成主要任务；
2. 焦点顺序与视觉和任务顺序一致；
3. 当前焦点始终可见，不被粘性导航或弹窗遮挡；
4. 图标按钮具有可理解名称；
5. 输入框有持久标签，不能只靠 placeholder；
6. 错误与对应字段关联，并说明怎样修复；
7. 动态结果能以适当方式通知辅助技术；
8. 图片替代文字根据图片用途编写，装饰图不制造噪声；
9. 放大、重排、减少动态效果后仍能操作；
10. 弹窗打开与关闭时，焦点进入、约束和返回符合预期。

WCAG 可以帮助团队建立发布基线，但它不是一张只在上线前运行的清单。组件设计、开发和内容录入阶段都要保留相关约束。^[3][4]

ARIA 不能替组件补上行为

WAI-ARIA 可以为动态内容和复杂控件补充角色、状态和属性。W3C 的 ARIA Authoring Practices Guide 提供常见模式、键盘支持、名称和描述等实践资料。^[5]

ARIA 角色本身不会让一个 div 自动获得按钮行为。开发者为元素声明按钮角色，也必须实现预期的键盘操作、焦点和状态。错误的 ARIA 可能向辅助技术提供与视觉界面相反的信息。^[5]

因此可以采用三个原则：

• 原生 HTML 能表达时先用原生元素；
• 使用 ARIA 时，同时实现对应行为和状态更新；
• 复杂组件参考当前 APG 模式，并在实际浏览器与辅助技术组合中测试。

APG 是实践指南，不是独立的符合性标准，也不是完整 UI 设计系统。产品仍要回到 WCAG 成功标准、平台行为和用户测试。

自动扫描只能发现一部分问题

自动工具擅长发现缺少名称、部分对比问题、结构错误和明确规则冲突。它无法可靠判断替代文字是否表达了图片用途，焦点顺序是否符合任务，错误信息是否容易理解，或多步骤流程是否让用户迷失。

可以把测试分成几层：

• 自动检查：静态规则、对比、名称和常见代码问题；
• 键盘检查：完整任务、焦点顺序、可见焦点和浮层；
• 屏幕阅读器检查：结构、名称、状态、错误和动态更新；
• 视觉适配检查：缩放、重排、颜色模式和减少动态效果；
• 设备检查：触摸目标、软键盘、横竖屏、低速网络；
• 用户检查：邀请目标用户和使用辅助技术的用户完成真实任务。

测试记录要注明浏览器、系统、设备、辅助技术版本、任务和结果。一次通过不代表未来版本自动通过，核心组件和关键流程需要进入回归范围。

本地化从用户任务延伸出去

把中文替换成英文，只完成了本地化的一部分。正式产品还要处理 Locale、格式、阅读方向、输入方式、内容规则和业务差异。^[6]

Locale 是一组与语言和地区相关的偏好。它会影响日期、时间、数字、货币、复数、排序、星期起点和时区显示。语言相同的两个地区，也可能使用不同格式。

Unicode CLDR 提供广泛使用的 Locale 数据，包括日期、时区、数字、复数、日间时段、语言匹配、文字系统和地区等信息。^[7] 产品通常应通过成熟的国际化框架、平台 API 或基于 CLDR 的库调用这些规则，不要自己维护一张「每个国家怎样写日期」的静态表。

本地化需求可以分为四层：

1. 界面语言：标题、按钮、提示、错误和帮助；
2. 格式规则：日期、时间、数字、货币、单位、复数和排序；
3. 输入与流程：姓名、地址、电话、登录、付款和身份字段；
4. 市场内容：案例、价格、政策、支持方式和产品能力。

第四层不能由翻译工具自动决定。产品在某个地区是否可售、价格是否含税、付款和退款怎样处理，都需要按上线时点和适用范围单独确认。

不用国籍替代用户研究

设计讨论中常见「某地区用户喜欢密集页面」「某国用户只用某种登录」等说法。这些判断可能来自有限项目，不能直接成为产品规则。^[6]

更稳妥的做法是把它们写成待验证假设：

• 目标用户是否熟悉邮箱、手机号、Apple、Google 或企业 SSO；
• 某种信息密度是否帮助他们完成任务；
• 哪种支付和价格表达更容易理解；
• 他们如何填写姓名、地址和公司信息；
• 哪些案例和证明能够建立信任。

验证可以来自目标市场访谈、可用性测试、真实转化数据、客服问题和平台行为。地区信息可以帮助抽样，不能代替对具体用户和任务的观察。