Accessible Description
可访问描述
可访问描述会补充组件名称没有说明的信息。它可以解释格式、限制或操作结果。
accessible name + role + referenced description -> assistive technology output<label for="email">id="receipt-hint"输出示例accessible name + role + referenced description -> assistive technology outputA11Y另一个例子
“电子邮箱”字段用 aria-describedby 连接到页面上的隐私提示。辅助工具可以读出名称、角色和补充描述。
主要部分
- 01页面上的标签
- 02可访问名称
- 03页面上的补充文字
- 04描述文字引用
- 05计算后描述
- 06辅助工具输出
什么时候用
组件名称之外还有实用细节时，可以添加可访问描述。可以的话，请连接到页面上看得到的文字。
什么时候不要用
不要用补充描述取代标签。长篇且有结构的内容需要独立导航时，可以改用 aria-details。
代码里的名称
accessible name + role + referenced description -> assistive technology output 上线前要检查
每个字段都要有程序能读到的标签。关联提示与错误，并保留已输入内容。检查自动填充、键盘顺序、验证时机、提交状态、失败恢复、缩放与多语言。
预期结果：使用 可访问描述 (Accessible Description) 解决这项需求，同时保留用户当前的操作上下文。 用户场景：“电子邮箱”字段用 aria-describedby 连接到页面上的隐私提示。辅助工具可以读出名称、角色和补充描述。 建议界面模式：可访问描述 (Accessible Description)。 适用理由：组件名称之外还有实用细节时，可以添加可访问描述。可以的话，请连接到页面上看得到的文字。 不应使用的情况：不要用补充描述取代标签。长篇且有结构的内容需要独立导航时，可以改用 aria-details。 产品要求：定义默认、加载、没有内容、错误、成功与恢复状态。保留用户已输入的内容，每个操作后都提供清楚反馈。 无障碍与韧性：使用结构正确的 HTML（语义化 HTML）和完整键盘操作。焦点要清楚可见，布局缩放后仍要好用。也要提供减少动态效果。遵守项目现有规则。除非项目已采用，否则不要新增界面组件库。 验收标准：主要任务可只用键盘完成，在 320px 宽度也能正常使用。焦点与状态变化可被辅助工具读出。加载、失败、重试、取消与减少动态效果都已验证。 证据与限制（证据边界）：标准只涵盖列出的范围，不会替你决定外观、产品做法或 Vibulary 的教学示例。 待确认：产品文字、数据来源、分析事件、支持设备与语言，以及平台特有限制。
检查这份需求
请 AI 编程助手检查当前如何使用 可访问描述 (Accessible Description)。 定义：可访问描述会补充组件名称没有说明的信息。它可以解释格式、限制或操作结果。 生产环境检查：每个字段都要有程序能读到的标签。关联提示与错误，并保留已输入内容。检查自动填充、键盘顺序、验证时机、提交状态、失败恢复、缩放与多语言。 修改程序前，先列出看到的证据、缺口、严重程度，以及最小且安全的修正。