关于 taste-accessibility
taste-accessibility 是面向生成式 UI 的无障碍设计技能,适用于构建网页界面的设计与开发流程。它把语义结构、键盘操作、对比度、表单和测试要求纳入生成检查清单。
主要功能
- 01语义结构与标题层级
- 02完整键盘操作支持
- 03WCAG 2.2 对比度与触控尺寸
- 04表单标签和错误提示规则
- 05减少动态效果要求
- 06屏幕阅读器与缩放检查
适用场景
- 01生成网页界面时检查无障碍要求
- 02审查键盘导航与焦点状态
- 03完善表单标签和错误消息
- 04检查动效、对比度和页面缩放
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ madebymustafa/ design-taste --skill taste-accessibility安装后在 Claude Code 中输入/taste-accessibility确认已加载。
详细介绍
taste-accessibility
AI 生成的 UI 默认不可访问。此技能将可访问性设为默认要求。以下规则都会在生成过程中应用,而不是事后修补。
1. 语义结构(代码骨架)
- 每页仅有一个
<h1>;标题级别不得跳级(从 h1 直接到 h3、缺少 h2 = 不合格);标题构成页面大纲——仅阅读标题即可检验。 - 地标:
<header>、<nav>、<main>、<footer>,以及在有意义时提供可访问名称的<aside>/<section>。 - 列表使用列表标签(导航、功能列表使用
<ul>);<table>仅用于表格数据,并使用<th scope>表头。 - 按钮使用
<button>;链接使用<a href>;两者都要有可见文本。仅有图标的控件应使用与可见提示文本相符的aria-label。 - 装饰性图片:
alt=""(空值)。信息性图片:alt 应描述含义,而非外观(“图表:5 月转化率从 18% 降至 9%”,而不是“蓝色折线图”)。 - 在装饰性 SVG/装饰元素上使用
aria-hidden="true"和tabindex="-1";绝不要在可聚焦元素上使用aria-hidden。
2. 完整支持键盘操作(无需鼠标或触屏)
- 所有元素均可到达:Tab 顺序应与视觉顺序一致;非交互元素不得获得焦点(仅在有意为之时使用
tabindex="0")。 - 所有位置的焦点都清晰可见:2px 焦点环,与相邻内容的对比度为 3:1,
outline-offset≥ 2px。没有替代样式时,绝不要使用outline: none。 - 标准交互:Enter 激活按钮/链接;Space 切换状态;Esc 关闭对话框和菜单。
- 对话框/弹出框:打开时焦点移入其中,并限制在其中(或使用平台原生模式);关闭时焦点返回触发元素;覆盖层需带有
role="dialog"、aria-modal="true"和可访问名称。 - 跳过链接:每个营销页面上的第一个可聚焦元素(“跳至内容”),获得焦点时显示。
- 自定义组件(菜单、选项卡、组合框、滑块):正确实现 ARIA 模式(例如,使用带
aria-selected的role="tablist",并支持方向键导航),或改用平台原生元素——原生<select>胜过有缺陷的自定义组件。
3. 对比度与目标尺寸(精确数值,WCAG 2.2)
| 规则 | 要求 |
|---|---|
| 普通文本 | ≥ 4.5:1 |
| 大号文本(≥24px / ≥18.66px 粗体) | ≥ 3:1 |
| UI 组件与焦点 | 与相邻内容相比 ≥ 3:1 |
| 指针目标尺寸 | ≥ 24×24px(AA 2.2);建议且触屏必需 ≥ 44×44px |
| 间距例外 | 24px 的目标与相邻目标之间间隔 ≥ 24px,即可通过 |
- 仅使用占位符作为标签不合格(4.1.2):每个输入都需要通过程序关联的标签(
<label for>或aria-labelledby)。 - 错误状态:不得仅靠颜色传达——应使用文本消息和图标;错误需通过
aria-live="assertive"区域播报;错误消息应指出具体字段并说明如何修正,而不是只说“无效”。 - 在深色和浅色表面上都要提供焦点指示器;检查焦点状态与其所在背景的对比度,而非与页面背景的对比度。
4. 表单(生成检查清单)
- 为每种输入使用正确的
type(email、tel、password、number、search),以及正确的autocomplete令牌(email、name、credit-card-number等)。 - 设置
required和aria-required;使用:user-invalid样式进行验证(而非仅用 :invalid——避免在提交前就造成困扰),并显示可见消息。 - 对于字段数 ≥ 4 的表单,使用单列布局;标签置于输入框上方;提示文本应通过
aria-describedby关联,而非与输入框分离。 - 多步骤向导:播报进度,在顶部汇总错误,并确保上一步/下一步操作可通过键盘完成。
5. 动效与认知
- 遵循
prefers-reduced-motion(参见 taste-motion §7):不得使用视差效果、轮播自动播放或跑马灯。 - 不得自动播放带声音的媒体;轮播在悬停/获得焦点时暂停;内容移动速度不得快于阅读速度。
- 超时(会话、自动前进):至少提前 20s 警告,或提供用户控制(WCAG 2.2.1)。
- 使用通俗易懂的语言;首次使用缩写时应展开说明;不得仅用 emoji 交流。
6. 测试(完成前运行以下检查)
- 键盘遍历:按 Tab 键浏览整个页面——每个停留点都能看到焦点,顺序合理,且没有键盘焦点陷阱。
- 使用屏幕阅读器(VoiceOver/NVDA)朗读:页面标题、标题大纲、每个控件的标签,以及播报的各个区域。
- 对比度:检查所有文本与背景的组合(至少包括:标题、正文、弱化文本、按钮文本、占位符、输入框边框)。
- 调整大小:在 200% 缩放(最大宽度为 1280px)下,不出现水平滚动或文本裁切。
- 检查
aria-label是否不必要地重复可见文本;检查是否存在空按钮或链接。 - 深色和浅色主题都必须通过(切勿只假设一种主题)。
7. 检查清单(出现以下情况时页面不合格……)
- 跳过了某个标题级别。
- 存在没有关联标签的输入框。
- 存在无法通过键盘访问的交互元素。
- 存在不可见的焦点指示器,或使用了没有替代方案的
outline: none。 - 存在低于 4.5:1(大号文本为 3:1)的文本对比度,且没有作为有意设计的例外进行记录。
- 有错误信息仅通过颜色传达。
- 没有处理
prefers-reduced-motion。 - 触控目标小于 24px,且间距不足 24px。
无障碍不是一项功能,而是界面正常运作的基础。不要发布任何未通过此检查清单的内容。
评论
支持 Markdown