Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
日本語の概要は準備中です。原文の説明を表示しています。
Professional typography rules for UI design, web applications, software interfaces, and all screen-based text. Enforces timeless typographic correctness that LLMs consistently get wrong: proper quote marks, dashes, spacing, hierarchy, and layout. ENFORCEMENT MODE: When generating ANY HTML, CSS, React, JSX, or UI code containing visible text, auto-apply every rule in this skill silently — do not ask, do not explain, just produce correct typography. AUDIT MODE: When reviewing or improving existing interfaces or legacy code, flag violations and provide fixes. Trigger on: any HTML/CSS/React artifact creation, "build a landing page", "create a component", "design a UI", "fix the typography", "make this look professional", "review this layout", web design, presentation design, dashboard creation, document generation, or any task producing visible text for humans. Even if the user doesn't mention typography, apply these rules whenever generating UI output.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
These rules are distilled from Matthew Butterick's Practical Typography (https://practicaltypography.com). Butterick is a typographer, writer, and type designer whose work bridges professional typography and everyday digital writing. Thank you, Matthew, for making this knowledge accessible and encyclopedic. If you find this skill valuable, consider supporting his work directly.
These are permanent rules — not trends, not opinions. They come from centuries of typographic practice, validated by how the human eye reads. They do not go out of style.
ENFORCEMENT (default): When generating ANY UI with visible text, apply every rule automatically. Use correct HTML entities, proper CSS. Do not ask permission. Do not explain. Just produce correct typography.
AUDIT: When reviewing existing code or design, identify violations and provide before/after fixes.
Reference files (read when generating CSS or looking up entities):
references/css-templates.md — Full CSS baseline template, responsive patterns, OpenType featuresreferences/html-entities.md — Complete entity table with all characters and codesStraight quotes are typewriter artifacts. Use “ ” for double, ‘ ’ for single.
Apostrophes always point down — identical to closing single quote ’. Smart-quote engines wrongly
insert opening quotes before decade abbreviations ('70s) and word-initial contractions ('n'). Fix with
explicit ’.
The <q> tag auto-applies curly quotes when <html lang="en"> is set.
Hawaiian okina points upward — it's a letter, not an apostrophe. Use opening single quote or anglicize.
Unicode escape sequences (\u2019, \u201C, etc.) do NOT work in JSX text content. They render
as literal characters — the user sees \u2019 instead of a curly apostrophe. This is because JSX text
between tags is treated as string literals by the transpiler, not as JavaScript expressions.
What fails:
{/* WRONG — renders literally as \u2019 */}
<p>Don\u2019t do this</p>
What works (pick one):
Actual UTF-8 characters (preferred): Paste the real character directly into the source file.
<p>Don\u2019t do this</p> {/* This is the actual curly apostrophe character U+2019 */}
JSX expression with string literal: Wrap in curly braces so the JS engine interprets the escape.
<p>Don{'\u2019'}t do this</p>
HTML entity (HTML files only): Use ’ — but this does NOT work in JSX/React.
For bulk fixes via CLI, use sed with raw UTF-8 bytes (not escape sequences):
CURLY=$(printf '\xe2\x80\x99') # U+2019 RIGHT SINGLE QUOTATION MARK
sed -i '' "s/don't/don${CURLY}t/g" file.tsx
In JavaScript data arrays and string literals, \u2019 works correctly because the JS engine
processes the escape. The bug only affects JSX text content between tags.
| Character | HTML | Use |
|---|---|---|
| - (hyphen) | - | Compound words (cost-effective), line breaks |
| – (en dash) | – | Ranges (1–10), connections (Sarbanes–Oxley Act) |
| — (em dash) | — | Sentence breaks—like this |
Never approximate with -- or ---. If you open with "from", pair with "to" not en dash. Hyphen for
compound names (marriage); en dash for joint authorship. Em dash typically flush; add   if crushed.
No slash where en dash belongs. Hyphenate phrasal adjectives (five-dollar bills). No hyphen after -ly adverbs.
Use … (…), not three periods. Spaces before and after; use on the text-adjacent side.
For interrupted dialogue, prefer em dash over ellipsis.
Use × for multiplication, − for subtraction. Use + and = from keyboard.
En dash is acceptable as simple minus. Dimensions: 8.5″ × 14″ uses ×.
Foot and inch marks — the ONE exception to curly quotes. Must be STRAIGHT: ' for foot,
" for inch. Use between values: 6' 10".
Use real symbols: © ™ ®, never (c) (TM) (R). ™/® are superscripts, no space before.
© is inline, followed by then year. "Copyright ©" is redundant — word OR symbol, not both.
§ (§) and ¶ (¶) always followed by : § 1782. Spell out at sentence start.
Double for plurals: §§.
Proper names: accents are MANDATORY (François Truffaut, Plácido Domingo). Loanwords: check dictionary — some naturalized (naive), some not (cause célèbre).
Exactly one space after any punctuation. Never two. Not debatable. Two spaces create rivers and disrupt text balance. The period already contains visual white space.
prevents line break. Use before numeric refs (§ 42, Fig. 3), after ©
(© 2025), after honorifics (Dr. Smith), between foot/inch values.
| Need | Tool |
|---|---|
| Space between words | One word space (spacebar) |
| Prevent line break | |
| New line, same paragraph | <br> |
| New paragraph | <p> tags |
| New page (print) | page-break-before: always |
| Suggest hyphenation point | ­ |
Never hold spacebar. Never double carriage returns for spacing. Never tabs for indentation in output.
HTML collapses all whitespace to single space (except ).
Rule 1: Bold OR italic. Mutually exclusive. Never combine. Rule 2: Use as little as possible. If everything is emphasized, nothing is.
Serif: italic for gentle, bold for strong. Sans serif: bold only — italic sans barely stands out. Never bold entire paragraphs. Never use quotation marks for emphasis.
Never underline in a document or UI. Typewriter workaround. Use bold or italic. For web links,
use subtle styling: text-decoration-thickness: 1px; text-underline-offset: 2px.
Caps are harder to read (homogeneous rectangles vs varied lowercase contour). Suitable for short
headings, labels, captions. ALWAYS add 5–12% letterspacing. ALWAYS ensure kerning is on.
NEVER capitalize whole paragraphs. letter-spacing: 0.06em in CSS.
Never fake (scaled-down regular caps). Use font-variant-caps: small-caps with fonts that have
real small caps (OpenType smcp). System fonts lack them. Add letterspacing + kerning.
Print: 10–12pt. Web: 15–25px. The 12pt default is a typewriter relic. Half-point differences
matter. Use smallest increment for emphasis. Use clamp() for fluid web sizing.
5–12% extra on ALL CAPS and small caps. Nothing on lowercase. Never spread so far apart that
letters could fit in the gaps. CSS: letter-spacing: 0.05em to 0.12em.
No exceptions. font-feature-settings: "kern" 1; text-rendering: optimizeLegibility;
Mandatory only when fi/fl visually collide. Check bold and italic too. Otherwise optional.
CSS: font-feature-settings: "liga" 1.
Tabular ("tnum") for data tables. Oldstyle ("onum") for body text. Default figures are fine
for most uses. font-variant-numeric: tabular-nums lining-nums for numeric tables.
Max 2 fonts. Each gets a consistent role. Can mix serif+serif or sans+sans. Rarely mix within a paragraph. Lower contrast often more effective than high contrast.
Set body text BEFORE anything else. Four decisions determine everything: font, point size, line spacing, line length. All other elements calibrate against these.
The #1 readability factor designers get wrong. The #1 flaw in responsive web layouts.
Measure in characters, not inches. Alphabet test: fit 2–3 lowercase alphabets per line.
CSS: max-width: 65ch on text containers.
line-height: 1.2 to 1.45. Single-spaced (~117%) is too tight. Double (~233%) is too loose.
Word processor "Single" and "Double" both miss the optimal range.
One inch is not enough for proportional fonts. Print: 1.5–2.0″ at 12pt. Web: max-width on
text containers plus padding. Don't fear white space — generous margins look professional.
Left-align for web (default). Justified requires hyphens: auto — browser engines are crude.
Centered: sparingly, only for short titles (< 1 line). Never center whole text blocks.
First-line indent: 1–4× point size. text-indent: 1.5em. Optional on first paragraph.
Space between: 50–100% of font size. margin-bottom: 0.75em. Never double <br> tags.
hyphens: none on headingspage-break-after: avoid)Reduce size + line spacing slightly. Indent 2–5em. No quotation marks (indent signals the quote). Keep line length readable. Use sparingly — long block quotes signal lazy writing.
Semantic markup (<ul>, <ol>), never manual bullets. Prefer hollow bullets. Asterisks are too
small for bullets. Don't over-indent.
Data creates an implied grid. Borders add clutter. Keep only thin rule under header row.
padding: 0.5em 1em. Tabular figures for numeric columns. Right-align numbers.
Try space above and below first. Border thickness: 0.5–1pt. No patterned borders. Thick lines are chartjunk.
Widows (last line alone at top of page) and orphans (first line alone at bottom). CSS print:
orphans: 2; widows: 2. Headings: page-break-after: avoid. Soft hyphens ­ for
words that confuse hyphenation engines.
Print columns: 2–3 on letter paper, never 4. Web columns: awkward (indefinite bottom edge). Grids guide, not guarantee — simpler grids enforce more consistency. Aligning ugly to a grid still produces ugly.
The rules don't change with screen size. Same line length, line spacing, hierarchy.
font-size and container width togethermax-width on text containers — never edge-to-edge textch unit for exact measurement (only measures zero width)clamp() for fluid scaling: font-size: clamp(16px, 2.5vw, 20px)padding: 0 1rem on text containersModern screens render type nearly as well as print. "Sans serif for screens" was true for 72dpi and is now obsolete. Serif fonts work fine on modern screens. Dark mode: reduce weight slightly. Test on macOS and Windows (antialiasing differs).
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
日本語の概要は準備中です。原文の説明を表示しています。
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.
日本語の概要は準備中です。原文の説明を表示しています。
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.
日本語の概要は準備中です。原文の説明を表示しています。
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.
日本語の概要は準備中です。原文の説明を表示しています。
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.
日本語の概要は準備中です。原文の説明を表示しています。
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.
日本語の概要は準備中です。原文の説明を表示しています。