界面设计
关于界面的问题不是关于品味的问题。 对比度有比率，目标有尺寸， 回流有必须仍然正常工作的宽度， 布局的信息顺序由用户首先做什么来决定。 这些都由测量和已发布的标准决定， 因此将它们交给用户，问“你更喜欢哪个”， 就把注意力浪费在了本来应由代理完成的工作上。
测量之后剩下的才是真正的问题，
本技能的存在就是为了让这个剩余变得很小，并将证据附在其上。
own-the-call 规定了随后如何提出这个问题。
本技能替代的时刻
| 即将…… | 替代…… |
|---|---|
| 询问用户喜欢哪个颜色、尺寸、间距或位置 | 对照以下标准进行测量；只询问没有阈值能判定的问题 |
| 把视觉选择称为主观 | 说出它通过或失败的标准——对比度、目标尺寸、回流宽度、焦点可见性、信息顺序 |
| 说“看起来不错” | 打开它，截图，并说明在哪个视口测量了什么 |
| 凭眼力调整控件尺寸 | 24×24 CSS px 是WCAG AA 最低值；设计系统可能设置更严格的值（Material: 48dp） |
| 根据外观从调色板中挑选颜色 | 计算对比度：正文4.5:1，大文本和非文本3:1 |
| 在一个窗口尺寸下检查并发布布局 | 检查320 CSS px 宽和256 CSS px 高，回流必须仍能正常工作 |
| 把axe跑出绿色的结果当作无障碍 | axe 能发现大约57%；其余的是键盘、焦点顺序和语义 |
| 设计一个设计系统已经定义的组件 | 使用他们的，并说出用的是哪个 |
| 询问如何画图 | 根据读者首先追踪什么来决定，然后展示一个渲染结果 |
在询问之前，依据标准来决定
四个主体回答了大部分问题， 它们并非完全一致——当它们有分歧时， 采用更严格的那个数值， 因为满足更严格的那个就能同时满足两者。
WCAG 2.2 是最低要求，并且是规范性文件：W3C推荐标准， 也是ISO/IEC 40500。 目标级别为AA；AAA级并非所有内容都能达到，W3C也明确指出这一点。
| 准则 | 级别 | 阈值 |
|---|---|---|
| 1.4.3 对比度（最低） | AA | 文本4.5:1；大文本（≥18pt，或14pt加粗）3:1 |
| 1.4.11 非文本对比度 | AA | 与相邻颜色3:1 |
| 1.4.4 文本缩放 | AA | 在200%缩放时可用 |
| 1.4.10 回流 | AA | 在320px宽或256px高时，无双向滚动 |
| 1.4.12 文本间距 | AA | 行高 ≥1.5倍字体大小，段落间距 ≥2倍，字母间距 ≥0.12倍，单词间距 ≥0.16倍 |
| 2.4.7 焦点可见 | AA | 焦点指示器可见的模式 |
| 2.4.11 焦点不被遮挡 | AA | 获得焦点的控件不被完全隐藏 |
| 2.5.8 目标尺寸（最低） | AA | 24×24 CSS px，或24px间距 |
| 2.4.13 焦点外观 | AAA | ≥2px 周长，焦点与非焦点3:1 |
| 2.5.5 目标尺寸（增强） | AAA | 44×44 CSS px |
设计系统 解决了WCAG未明确的部分：间距比例、
字号比例、组件结构、颜色角色。
采用它的组件不是偷懒，
这本身就是决定——并且它已经包含了已完成的辅助功能工作。
Material Design 3 设置了48×48dp的触摸目标，
比WCAG的24px更严格，
并要求颜色按角色（primary、on-primary、surface）而不是固定十六进制值来选取，
这样主题和暗色模式就不需要再做第二次决定。
对于面向公众的日文作品，数字厅设计系统（design.digital.go.jp，作为活标准的β版）提供了组件、
指南和设计令牌，令牌和示例组件在GitHub上以MIT许可证发布。
axe-core 测量可以测量的内容，并且明确了自己的限制：
平均大约57%的WCAG问题。
因此，绿色运行结果仅是关于57%问题的证据，
说“axe通过”而不提及这个数字会夸大其词——measured-claims 也适用于这个数字，就像其他任何数字一样。
npx @axe-core/cli http://localhost:5173 --tags wcag2a,wcag2aa,wcag22aa
npx lighthouse http://localhost:5173 --only-categories=accessibility --quiet
Lighthouse的无障碍评分是同一个引擎，只不过加了个数字。
它的审计项是axe-core的规则——每一项都链接到Deque的规则页面——
所以57%的限制被继承了下来，
而评分又增加了两种被误读的方式。
它是一个加权平均值，
权重3到10，基于axe的用户影响评估，
手动和最佳实践审计被完全排除在评分之外，
因此这个算术结果无法触及需要人为检查的部分。
每个审计项也是二值的：
一个没有标签的按钮直接“按钮没有可访问名称”失败，
没有部分分数。
因此100分意味着“加权自动化子集通过了”，
一个完美分数的诚实报告应该这么说，而不是“无障碍”。
将它用于需要修复的问题的排名列表；
当发现结果本身比排名更重要时，使用axe的JSON输出。
Lighthouse的性能类别属于web-perf，
而非本技能的范围。
两者都看不到的内容：焦点顺序是否遵循阅读顺序， 标签是否准确描述了它所指的事物， 图标在脱离颜色后是否仍能传达意义， 布局的信息顺序是否与任务匹配。 这些需要由人来阅读，而这个“人”可以是代理。
观察它，然后说出看到了什么
一个没有背后观察的界面声明就是measured-claims中换了一种媒介的“传闻”。
主机有一个浏览器，因此可以进行观察：
mcp__claude-in-chrome__navigate → 页面
mcp__claude-in-chrome__read_page → 结构、标题、标签
mcp__claude-in-chrome__computer → 在指定视口下的截图
mcp__claude-in-chrome__resize_window → 320px，用于测试回流
将视口与发现结果一起报告。 “看起来不错”没有指明任何宽度和测量； “在320px时，第二列折到第一列下方，且没有任何横向滚动”才是一个可供他人核查的读取结果。 键盘顺序通过Tab键遍历并记录为观察到的顺序， 因为这正是axe未覆盖的那一半。
信息顺序是推导出来的，不是选择的
内容放在哪里，取决于读者用它做什么，
这正是reader-map的问题在界面上的应用：谁到来，
他们来做什么，他们首先需要什么。
一个在设置时只用一次的控制项，和一个每分钟都要用的控制项，不会争夺同一个位置。
因此，“这个应该放在哪里”的答案是通过命名任务来给出的， 而不是列出三个位置选项。 当两个任务真正冲突且没有一个占主导地位时， 这才是值得询问的剩余部分——并且提问时要带着这两个冲突任务的名称， 而不是作为关于角落的选择。
这对于图表也同样适用。 读者首先追踪什么决定了流程的方向； 形状跟随轨迹， 并且展示一个渲染结果，而不是描述三个。
真正属于用户的决策
有三件事在测量之后仍然保留：
- 界面服务的目标受众或市场，
当这一点尚未确定时——它决定了适用哪个标准（对于受监管的市场，使用
regulated-claims）。 - 品牌约束——必须使用的颜色、字体或标志。 这个约束属于用户；它是否满足4.5:1的对比度仍需测量， 一个失败的品牌颜色会连同对比度比值和最近的可通过变体一起报告。
- 一个双方都已测量过的权衡，
且证据无法决定结果：密度与可扫描性，
一个屏幕还是两个。
带着双方的测量数据提问，
这是一个
own-the-call承认的问题。
其他所有内容——对比度、间距、目标尺寸、焦点、回流、 组件选择、图形形状、 跟随任务逻辑的位置——都被确定并报告。
检查清单
- 对比度已计算，而非凭眼力：文本4.5:1，大文本和非文本3:1
- 交互目标 ≥24×24 CSS px， 或设计系统更严格的值
- 在320px宽和256px高下检查，无双向滚动
- 每个交互元素上的焦点可见，且不被遮挡
- Tab键顺序已遍历并报告为观察到的结果
- 组件取自设计系统（当它有定义时）， 并已命名
- 已运行axe或Lighthouse，并已说明57%的限制，而非暗示
- Lighthouse无障碍评分报告为加权自动化子集的结果， 绝不说成“无障碍”
- 每个外观声明都带有其观察到的视口
- 留给用户的问题是上述三类， 并附有证据
如何与其他技能连接
own-the-call 决定了在本技能操作后遗留下来的问题形态；
大多数关于界面的问题都不应该到达它那里。
reader-map 提供本技能应用于布局的任务顺序。
measured-claims 管辖这里的每个比率和百分比，
包括57%这个数字。
document-structure 和 cognitive-rhythm 负责页面上的文字；
本技能负责文字周围的框架。
any-screenshot 是在浏览器外捕获屏幕的方式。
加载和交互速度、
Core Web Vitals 和 Lighthouse 的性能评分属于cloudflare插件中的web-perf；
本技能只处理Lighthouse的无障碍类别。
来源
- W3C, “Web Content Accessibility Guidelines (WCAG) 2.2”, W3C推荐标准，2024年12月12日 (www.w3.org/TR/WCAG22/)： 四项原则，A/AA/AAA级别， 以及移除已废弃的4.1.1解析规则。
- W3C, “How to Meet WCAG 2.2 (Quick Reference)” (www.w3.org/WAI/WCAG22/quickref/)： 上表中每个阈值， 在AAA级别下阅读，包含2.4.13和2.5.5。
- Deque Labs, axe-core README (github.com/dequelabs/axe-core)：MPL-2.0； 规则映射到WCAG 2.0、2.1和2.2的A、AA和AAA级别； “平均可以自动发现57%的WCAG问题”。
- Chrome for Developers, “Accessibility scoring in Lighthouse” (developer.chrome.com/docs/lighthouse/accessibility/scoring)： 评分是加权平均值，权重3到10， “基于axe的用户影响评估”， 每个审计项链接到Deque University的axe-core 4.11规则页面； 每个审计项是二值的； 手动和低影响审计项被排除在评分之外。 该页面本身并未说明满分意味着页面无障碍——也没有说相反的话， 因此上面的警告是本技能自己的判断。
- デジタル庁デザインシステム (design.digital.go.jp)：v2.18.2，
标记为β版（作为活标准）。
该网站没有声明WCAG级别或JIS X 8341-3目标。
digital-go-jp/design-tokens、design-system-example-components-react和-html在GitHub上以MIT许可证发布。 - Material Design 3的48×48dp触摸目标及其颜色角色指南来源于引用m3.material.io的二手资料， 而非网站本身：其页面通过脚本渲染，此处无法读取。 48dp数值是设计建议， 而非平台强制的最低要求。
关于这些来源存在分歧， 以及应采用更严格的数值的说法， 是本目录所有者的解读，而非任何来源已发布的立场。
在编写本技能时，上述命令均未运行： 两者都在首次使用时获取包， 而此沙盒拒绝执行新下载的代码。 这些标志来自于每个工具的文档，而非来自实际运行， 因此项目中的首次使用也将是对调用的首次测试。