Back to Details

antislop-human

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

antislop-human

antislop-human

Anti AI Slop: Design & Copy Rules. Human skill
Part of the antislop system. Read together with 
antislop.md
(the core). This skill deep-dives the human concern: the UI must stay usable by people with different eyes, hands, and setups. Contrast, keyboard, focus, states, and the mobile details that exclude people.
反AI敷衍：设计与文案规则。人性化技能
属于antislop系统的一部分。请与核心文档
antislop.md
一同阅读。本技能深入探讨人性化需求：UI必须确保不同视力、手部能力及设备环境的用户都能正常使用。涵盖对比度、键盘操作、焦点、状态，以及那些会排斥用户的移动端细节。

How to use this skill

如何使用本技能

  • Load together with 
    antislop.md
    whenever the task builds or edits UI. The core holds the mechanism (the purpose test, the three tiers, the Delivery Gate); this skill holds the human-side depth: the parts of a UI that exclude people with different eyes, hands, and setups.
  • Every entry has the same shape: Tell (the pattern), Why (who it excludes, and why it reads as unfinished), Fix (what to do instead), with the governing core rule cited as R-XX.
  • Accessibility is not a checklist of extras bolted on at the end. It is part of the core promise that "the UI holds up" (C-4). The Delivery Gate in the core remains the gate; the "Human Skill Checklist" at the end of this file is the supplement to run alongside it.
  • The contrast checker (formula + reference table + script) lives in this skill. Use it for every color pairing you cannot verify by eye.
  • This skill keeps only the mobile details that exclude people: zooming, and the on-screen keyboard.
  • 每当任务涉及构建或编辑UI时，请与
    antislop.md
    一同加载。核心文档包含机制（用途测试、三层标准、交付检查门）；本技能聚焦人性化深度：UI中那些会排斥不同视力、手部能力及设备环境用户的部分。
  • 每个条目都遵循相同结构：规则说明（模式）、原因（会排斥哪些用户，以及为何会显得不完善）、修复方案（替代方案），并引用核心规则编号R-XX。
  • 无障碍设计不是后期附加的检查清单。它是“UI稳定可用”这一核心承诺（C-4）的一部分。核心文档中的交付检查门仍为最终关卡；本文件末尾的“人性化技能检查清单”是配合执行的补充内容。
  • 对比度检查工具（公式+参考表+脚本）内置在本技能中。对于所有无法通过肉眼验证的颜色组合，请使用该工具。
  • 本技能仅保留那些会排斥用户的移动端细节：缩放和屏幕键盘。

Color & Contrast

颜色与对比度

Low-Contrast Text

低对比度文本

  • Tell: light grey text on a white or near-white background, thin body text, muted labels chosen because they look "elegant" but are hard to read.
  • Why: it excludes low-vision users and everyone in bright light. It is a visual choice made without checking the standard, which is exactly the kind of default the filter exists to catch.
  • Fix: meet WCAG AA minimums (R-25): 4.5:1 for normal text, 3:1 for large text (18px+). Compute the ratio; do not eyeball it.
  • 规则说明：白色或近白色背景上的浅灰色文本、纤细的正文字体、为追求“优雅”而选择的柔和标签，但这些文本难以阅读。
  • 原因：这会排斥低视力用户和处于强光环境中的所有用户。这是一种未遵循标准的视觉选择，正是过滤器要捕捉的典型默认错误。
  • 修复方案：满足WCAG AA最低标准（R-25）：普通文本对比度4.5:1，大文本（18px及以上）对比度3:1。计算对比度比值，不要仅凭肉眼判断。

Text Over a Photo or Gradient

图片或渐变背景上的文本

  • Tell: white text placed directly over an image or gradient that is light in some areas, checked at one bright spot only.
  • Why: contrast is local. Where the image is light, the text drops below 4.5:1 even if the hero still "looks" fine. R-25 requires testing the whole area the text passes over, not a single point.
  • Fix: add a scrim or a solid color block behind the text, then verify the worst spot, not the best. If any part of the text area fails, the treatment fails.
  • 规则说明：白色文本直接放置在部分区域较亮的图片或渐变背景上，仅在一个明亮区域进行检查。
  • 原因：对比度是局部性的。即使整体看起来没问题，在背景较亮的区域，文本对比度会低于4.5:1。R-25要求测试文本覆盖的整个区域，而非单个点。
  • 修复方案：在文本后方添加遮罩层或纯色块，然后验证最差区域而非最佳区域。如果文本区域的任何部分不达标，则该处理方式不合格。

The Grey-on-Grey Hallucination

灰-on-灰的幻觉

  • Tell: "dark grey on black" or "light grey on white" claimed to pass AA without a computation.
  • Why: this is the most common accessibility hallucination. The eye overestimates contrast on grey pairs, and agents repeat the claim because it sounds plausible. #555555 on black is 2.8:1. It fails.
  • Fix: never assert a pairing passes. Run the contrast checker (below) or apply the formula. When neither is possible, use the reference table.
  • 规则说明：声称“黑底深灰”或“白底浅灰”无需计算即可通过AA标准。
  • 原因：这是最常见的无障碍设计误区。人眼会高估灰色组合的对比度，AI助手会重复这种说法，因为它听起来似乎合理。#555555在黑底上的对比度为2.8:1，未达标。
  • 修复方案：永远不要断言某个颜色组合达标。使用下方的对比度检查工具（脚本）或公式进行计算。如果两者都无法使用，请参考参考表。

Non-Text Contrast

非文本元素对比度

  • Tell: interactive components (buttons, icons, input borders, focus indicators, chart segments) distinguished from their background by less than 3:1.
  • Why: non-text UI carries information by shape and edge. When the edge is a hair of tint, low-vision users cannot find the control. The same bar applies to states like hover and selected.
  • Fix: give every component boundary and every status indicator a 3:1 ratio against adjacent colors (WCAG 1.4.11). Pair icons with a text label that meets 4.5:1.
  • 规则说明：交互组件（按钮、图标、输入框边框、焦点指示器、图表分段）与背景的对比度低于3:1。
  • 原因：非文本UI通过形状和边缘传递信息。当边缘仅为细微色调差异时，低视力用户无法找到控件。此标准同样适用于悬停、选中等状态。
  • 修复方案：确保每个组件边界和状态指示器与相邻颜色的对比度达到3:1（WCAG 1.4.11）。图标需搭配符合4.5:1对比度的文本标签。

The Contrast Checker

对比度检查工具

The home of the contrast checker. Three layers, from most to least convenient:
The script. When a script runtime is available and the file is present, run it instead of computing by hand. The script ships in this skill's folder (
contrast-check.py
, next to this 
SKILL.md
):
bash
python3 "${CLAUDE_SKILL_DIR}/contrast-check.py" "#FFFFFF" "#777777"
对比度检查工具的核心内容。分为三层，从最便捷到最基础：
脚本工具。当有脚本运行环境且文件存在时，请运行脚本而非手动计算。脚本位于本技能的文件夹中（
contrast-check.py
，与本
SKILL.md
同目录）：
bash
python3 "${CLAUDE_SKILL_DIR}/contrast-check.py" "#FFFFFF" "#777777"

normal text: FAIL (4.48 < 4.5)

normal text: FAIL (4.48 < 4.5)

large text: PASS (4.48 >= 3.0)

large text: PASS (4.48 >= 3.0)


If the `${CLAUDE_SKILL_DIR}` variable is not available in this agent, point the script path at this skill's folder directly. The script exists so agents stop hallucinating AA. It takes two hex colors and prints the ratio and the verdict for both text sizes. If the file is missing, the formula and table below are complete on their own. Never block on the script.

**The formula (WCAG 2.x).**

1. Contrast ratio = (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter relative luminance and L2 the darker.
2. Relative luminance L of one color: convert each channel to 0-1 (`c = hex / 255`), then linearize: if `c <= 0.03928`, `c_lin = c / 12.92`; otherwise `c_lin = ((c + 0.055) / 1.055)^2.4`.
3. `L = 0.2126*R + 0.7152*G + 0.0722*B`.
4. Round the ratio to two decimals and compare: 4.5:1 for normal text, 3:1 for large text (18px+, per R-25). The maximum ratio is 21.0 (black on white).

**The reference table** (common pairings, computed with the formula):

| Pairing (text on background) | Ratio | Normal text (4.5) | Large text (3.0) |
|------------------------------|-------|-------------------|------------------|
| Black on white | 21.00 | Pass | Pass |
| White on black | 21.00 | Pass | Pass |
| White on #333333 | 12.63 | Pass | Pass |
| White on #666666 | 5.74 | Pass | Pass |
| #777777 on white | 4.48 | Fail | Pass |
| White on #888888 | 3.54 | Fail | Pass |
| White on #999999 | 2.85 | Fail | Fail |
| #555555 on black | 2.82 | Fail | Fail |

Read the table as a sanity check, not as a substitute. Any pairing not listed, or anything near a threshold, goes through the formula or the script.

如果当前AI助手无法访问`${CLAUDE_SKILL_DIR}`变量，请直接指定本技能文件夹的路径。该脚本的存在是为了避免AI助手在AA标准上产生错误判断。它接受两个十六进制颜色值，输出对比度比值及两种文本尺寸的判定结果。如果文件缺失，下方的公式和表格也可独立使用。切勿因脚本缺失而停滞工作。

**公式（WCAG 2.x）**

1. 对比度比值 = (L1 + 0.05) / (L2 + 0.05)，其中L1为较亮颜色的相对亮度，L2为较暗颜色的相对亮度。
2. 单个颜色的相对亮度L：将每个颜色通道转换为0-1范围（`c = 十六进制值 / 255`），然后线性化：如果`c <= 0.03928`，则`c_lin = c / 12.92`；否则`c_lin = ((c + 0.055) / 1.055)^2.4`。
3. `L = 0.2126*R + 0.7152*G + 0.0722*B`。
4. 将比值四舍五入到两位小数后进行比较：普通文本需达到4.5:1，大文本（18px及以上，符合R-25）需达到3:1。最大比值为21.0（黑底白字）。

**参考表**（常见颜色组合，通过公式计算得出）：

| 颜色组合（文本/背景） | 比值 | 普通文本（4.5） | 大文本（3.0） |
|------------------------------|-------|-------------------|------------------|
| 黑底白字 | 21.00 | 通过 | 通过 |
| 白底黑字 | 21.00 | 通过 | 通过 |
| #333333底白字 | 12.63 | 通过 | 通过 |
| #666666底白字 | 5.74 | 通过 | 通过 |
| 白底#777777字 | 4.48 | 不通过 | 通过 |
| #888888底白字 | 3.54 | 不通过 | 通过 |
| #999999底白字 | 2.85 | 不通过 | 不通过 |
| 黑底#555555字 | 2.82 | 不通过 | 不通过 |

参考表仅用于合理性验证，不能替代计算。任何未列出的颜色组合，或接近阈值的组合，都需通过公式或脚本进行计算。

Keyboard

键盘操作

Removed Focus Outline

移除焦点轮廓

  • Tell: 
    outline: none
    or 
    outline: 0
    with no replacement focus style.
  • Why: keyboard users cannot see where they are. It is the fastest way to make a UI unusable without a mouse, and R-32 forbids it outright.
  • Fix: keep or replace the outline with a visible 
    :focus-visible
    style that meets the same contrast bar (3:1 against its neighbors). Never set 
    outline: none
    without a replacement.
  • 规则说明：设置
    outline: none
    或
    outline: 0
    但未替换焦点样式。
  • 原因：键盘用户无法看到当前焦点位置。这是让UI在无鼠标情况下完全不可用的最快方式，R-32明确禁止这种做法。
  • 修复方案：保留焦点轮廓，或用可见的
    :focus-visible
    样式替代，且该样式需满足相同的对比度标准（与相邻元素对比度3:1）。永远不要在未提供替代方案的情况下设置
    outline: none
    。

Mouse-Only Patterns

仅支持鼠标的交互模式

  • Tell: menus that open on hover only, dropdowns that click-open but do not keyboard-open, drag-and-drop with no keyboard fallback.
  • Why: each one excludes keyboard and assistive-technology users (R-32). If a control cannot be reached and operated by Tab, Enter, or Space, it does not exist for a whole group of people.
  • Fix: every interactive element is reachable and operable by keyboard (R-32): logical tab order following visual order, activation with Enter or Space, and dialogs closable with Escape (R-26).
  • 规则说明：仅在悬停时打开的菜单、仅支持点击打开但不支持键盘打开的下拉菜单、无键盘替代方案的拖拽操作。
  • 原因：每种模式都会排斥键盘用户和辅助技术用户（R-32）。如果一个控件无法通过Tab、Enter或Space键访问和操作，那么对于这类用户来说它相当于不存在。
  • 修复方案：每个交互元素都必须可通过键盘访问和操作（R-32）：Tab顺序遵循视觉顺序，可通过Enter或Space键激活，对话框可通过Escape键关闭（R-26）。

Broken Tab Order

混乱的Tab顺序

  • Tell: focus jumps around the page, skips content, or lands on hidden elements because the DOM order does not match the visual order.
  • Why: tab order that reads the code order instead of the visual order makes navigation unpredictable (R-32). Users lose their place and the page feels broken.
  • Fix: keep the source order matching the visual order, add skip links for long pages, and never give real content 
    tabindex="-1"
    unless it is part of a controlled focus trap such as a dialog.
  • 规则说明：焦点在页面上跳跃、跳过内容，或落在隐藏元素上，因为DOM顺序与视觉顺序不匹配。
  • 原因：遵循代码顺序而非视觉顺序的Tab顺序会让导航变得不可预测（R-32）。用户会失去位置感，页面看起来像是故障了。
  • 修复方案：保持源代码顺序与视觉顺序一致，长页面添加跳转链接，除非是对话框等受控焦点陷阱的一部分，否则永远不要给真实内容设置
    tabindex="-1"
    。

Focus & States

焦点与状态

Weak or Invisible Focus Indicator

微弱或不可见的焦点指示器

  • Tell: a focus ring the same color as the background, a ring that only appears on hover, or an indicator thinner than a 1px border.
  • Why: the focus indicator is how keyboard users know where they are. If it fails the contrast bar or only shows on hover, keyboard-only use breaks (R-32, R-34).
  • Fix: a visible focus indicator on every interactive element, 3:1 against adjacent colors, in every theme you ship. Check it in dark and light mode.
  • 规则说明：焦点环与背景颜色相同、仅在悬停时显示的焦点环，或厚度小于1px边框的指示器。
  • 原因：焦点指示器是键盘用户判断当前位置的依据。如果它不满足对比度标准或仅在悬停时显示，纯键盘操作就会失效（R-32、R-34）。
  • 修复方案：每个交互元素都要有可见的焦点指示器，与相邻颜色对比度达到3:1，且在所有发布的主题中都存在。在深色和浅色模式下都要进行检查。

Color-Only Feedback

仅依赖颜色的反馈

  • Tell: success, error, and status communicated only by color: red error text, green success border, a tinted chip, with no icon, label, or text.
  • Why: it excludes color-blind and low-vision users, and it disappears entirely in forced-colors mode. A status that depends on seeing hue is not a status (C-4).
  • Fix: pair every color signal with text, an icon, or a pattern. Error states are text first: "Password must be at least 8 characters", not just a red border.
  • 规则说明：仅通过颜色传达成功、错误和状态：红色错误文本、绿色成功边框、着色标签，没有图标、文字说明。
  • 原因：这会排斥色盲和低视力用户，且在强制颜色模式下会完全消失。依赖色调感知的状态不能算作有效状态（C-4）。
  • 修复方案：每个颜色信号都要搭配文字、图标或图案。错误状态优先使用文本说明：“密码长度至少为8位”，而不仅仅是红色边框。

Missing UI States

缺失的UI状态

  • Tell: a data view with no empty, loading, or error state, or states that exist but are invisible: a spinner with no text, an empty screen with no explanation.
  • Why: R-27 requires the three states; the accessibility angle is that each must be perceivable and informative, not decorative. A loading spinner with no context reads as a frozen page to screen-reader users.
  • Fix: every data view has all three states (R-27), each announced or visible: an explicit empty message, a loading state with text, and an error state that says what happened and how to proceed.
  • 规则说明：数据视图没有空状态、加载状态或错误状态，或状态存在但不可见：无文字说明的加载 spinner、无解释的空屏幕。
  • 原因：R-27要求这三种状态；从无障碍角度来看，每种状态都必须可感知且提供信息，而非仅作装饰。没有上下文的加载 spinner 对屏幕阅读器用户来说就像是页面冻结了。
  • 修复方案：每个数据视图都要有这三种状态（R-27），且每种状态都要可被宣布或可见：明确的空状态提示、带文字的加载状态，以及说明问题和解决方法的错误状态。

Zoom & Mobile Use

缩放与移动端使用

The layout mechanics behind mobile (breakpoints, scale, grids, overflow, tap targets) are the concern of 
antislop-layoutmobile
. This section keeps only the mobile details that exclude people: zooming, and the on-screen keyboard.
移动端的布局机制（断点、缩放、网格、溢出、点击目标）属于
antislop-layoutmobile
的范畴。本节仅保留那些会排斥用户的移动端细节：缩放和屏幕键盘。

Text That Cannot Zoom

无法缩放的文本

  • Tell: fixed pixel font sizes, or containers with 
    overflow: hidden
    that clip text at 200% zoom.
  • Why: users must be able to resize text (WCAG 1.4.4). If zooming to 200% clips the content or forces horizontal scroll, the text is not resizable in practice.
  • Fix: fluid type that reflows with zoom, no clipping containers on text, and verify the layout holds at 200% zoom on a narrow viewport (R-35).
  • 规则说明：固定像素字体大小，或设置
    overflow: hidden
    的容器在200%缩放时会裁剪文本。
  • 原因：用户必须能够调整文本大小（WCAG 1.4.4）。如果缩放至200%时内容被裁剪或强制横向滚动，实际上文本是不可调整大小的。
  • 修复方案：使用随缩放自动重排的流式文本，文本容器不设置裁剪，在窄视口下验证200%缩放时布局是否正常（R-35）。

Mobile Keyboard Covers the Form

移动端键盘遮挡表单

  • Tell: inputs at the bottom of the viewport hidden behind the on-screen keyboard, with no scroll-into-view and no room for the input.
  • Why: a form the user cannot see or reach is a form they cannot complete. It is a mobile-only exclusion (R-03).
  • Fix: when an input is focused, it scrolls into view above the keyboard, with enough bottom padding that the focused field is never covered. Test with a real device or an emulated keyboard.
  • 规则说明：视口底部的输入框被屏幕键盘遮挡，没有滚动到视图内的功能，也没有输入框的可用空间。
  • 原因：用户无法看到或触及的表单是无法完成的。这是移动端特有的排斥问题（R-03）。
  • 修复方案：当输入框获得焦点时，它应滚动到键盘上方的视图区域，底部留有足够内边距，确保焦点字段永远不会被遮挡。请使用真实设备或模拟键盘进行测试。

Human Skill Checklist

人性化技能检查清单

Run these alongside the core Delivery Gate when the task involves UI. All answers must be yes:
  • Is every text and background pairing verified against the contrast checker (formula, table, or script), including text over images and gradients? (R-25)
  • Does every interactive component boundary and status indicator meet 3:1 against its background? (non-text contrast)
  • Is the focus indicator visible, high-contrast, and present on every interactive element in every theme? (R-32, R-34)
  • Is every interactive element reachable and operable by keyboard, with dialogs closable via Escape and no 
    outline: none
    without a replacement? (R-32, R-26)
  • Are the empty, loading, and error states of every data view present and perceivable, not color-only? (R-27, C-4)
  • Can text be resized to 200% without being clipped, and does the mobile keyboard never cover a focused input? (R-35)
当任务涉及UI时，请配合核心交付检查门执行以下检查。所有答案必须为是：
  • 所有文本与背景的颜色组合是否都通过对比度检查工具（公式、表格或脚本）验证，包括图片和渐变背景上的文本？（R-25）
  • 每个交互组件的边界和状态指示器与背景的对比度是否达到3:1？（非文本元素对比度）
  • 焦点指示器是否可见、高对比度，且在所有主题的每个交互元素上都存在？（R-32、R-34）
  • 每个交互元素是否都可通过键盘访问和操作，对话框可通过Escape键关闭，且未在未提供替代方案的情况下设置
    outline: none
    ？（R-32、R-26）
  • 每个数据视图的空状态、加载状态和错误状态是否都存在且可感知，并非仅依赖颜色？（R-27、C-4）
  • 文本是否可缩放至200%而不被裁剪，且移动端键盘永远不会遮挡获得焦点的输入框？（R-35）