mcpField
T
taste-accessibility

taste-accessibility

github.com/madebymustafa设计与 UI20055 次安装11 周前更新
代码仓库

关于 taste-accessibility

taste-accessibility 是面向生成式 UI 的无障碍设计技能,适用于构建网页界面的设计与开发流程。它把语义结构、键盘操作、对比度、表单和测试要求纳入生成检查清单。

主要功能

  1. 01语义结构与标题层级
  2. 02完整键盘操作支持
  3. 03WCAG 2.2 对比度与触控尺寸
  4. 04表单标签和错误提示规则
  5. 05减少动态效果要求
  6. 06屏幕阅读器与缩放检查

适用场景

  1. 01生成网页界面时检查无障碍要求
  2. 02审查键盘导航与焦点状态
  3. 03完善表单标签和错误消息
  4. 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. 测试(完成前运行以下检查)

  1. 键盘遍历:按 Tab 键浏览整个页面——每个停留点都能看到焦点,顺序合理,且没有键盘焦点陷阱。
  2. 使用屏幕阅读器(VoiceOver/NVDA)朗读:页面标题、标题大纲、每个控件的标签,以及播报的各个区域。
  3. 对比度:检查所有文本与背景的组合(至少包括:标题、正文、弱化文本、按钮文本、占位符、输入框边框)。
  4. 调整大小:在 200% 缩放(最大宽度为 1280px)下,不出现水平滚动或文本裁切。
  5. 检查 aria-label 是否不必要地重复可见文本;检查是否存在空按钮或链接。
  6. 深色和浅色主题都必须通过(切勿只假设一种主题)。

7. 检查清单(出现以下情况时页面不合格……)

  • 跳过了某个标题级别。
  • 存在没有关联标签的输入框。
  • 存在无法通过键盘访问的交互元素。
  • 存在不可见的焦点指示器,或使用了没有替代方案的 outline: none。
  • 存在低于 4.5:1(大号文本为 3:1)的文本对比度,且没有作为有意设计的例外进行记录。
  • 有错误信息仅通过颜色传达。
  • 没有处理 prefers-reduced-motion。
  • 触控目标小于 24px,且间距不足 24px。

无障碍不是一项功能,而是界面正常运作的基础。不要发布任何未通过此检查清单的内容。

评论

支持 Markdown