Derive a full UI palette from one or two brand colours — state variants, brand-tinted greys, semantic colours. Use when building or expanding a colour system.
日本語の概要は準備中です。原文の説明を表示しています。
WCAG 2.2 AA compliance as required by the European Accessibility Act. Use when designing, building or reviewing any user-facing interface for accessibility.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
The European Accessibility Act (EAA) requires digital products and services in the EU to meet EN 301 549, which references WCAG 2.2 Level AA as the technical baseline. This is not optional — it is a legal requirement for products operating in the EU market.
Default: always build to WCAG 2.2 AA. Deviating requires explicit, documented justification. Do not skip accessibility requirements because of timeline pressure or design preference.
WCAG 2.2 AA organises requirements under four principles: Perceivable, Operable, Understandable, Robust.
Users must be able to perceive all content and UI components.
| Context | Minimum ratio | Enhanced (AAA) |
|---|---|---|
| Normal text (< 18pt / < 14pt bold) | 4.5 : 1 | 7 : 1 |
| Large text (≥ 18pt / ≥ 14pt bold) | 3 : 1 | 4.5 : 1 |
| UI components and graphical objects | 3 : 1 | — |
Check contrast on the real rendered page, not the spec (dembrandt engine, optional). Design-time swatches lie once real text lands on real backgrounds, gradients, and overlays.
get_findings/render_reportrun against the live DOM and surface the actual failing text/background pairs with their measured ratios — a fast way to catch the combinations a static palette review misses. Seeextract-design.
Disabled elements are exempt. WCAG explicitly excludes inactive UI components from contrast requirements (WCAG 1.4.3 exception). A disabled button may use low-contrast text — this is intentional and correct, as it communicates the unavailable state.
Do not use colour as the only means of conveying information (e.g. a red border alone to indicate an error — add an icon or text label).
Weight is part of legibility, and the ratio cannot see it. The contrast formula measures ink colour against background colour and nothing else. It scores a hairline and a heavy weight identically at the same hue, while perceived legibility is the product of both. So the palette's faintest legible colour and the type scale's lightest weight must not land on the same text: a muted or secondary token, the one carrying captions, labels and helper text, takes a weight of at least 500 wherever the body default reads as regular or light. That floor is a house rule, not a WCAG requirement. The standard has nothing to say about weight, which is exactly why the failure gets through the audit. The same physics on dark surfaces is in [[color-mode-and-theme]]. A muted colour is already the palette's least assertive choice, and pairing it with the lightest weight compounds two decisions that both mean recede. The result at caption sizes is text a reader has to work at consciously, while the audit reports a pass.
alt text describing its content or functionalt="" so screen readers skip themaria-label or visually hidden textUsers must be able to operate all UI components.
All interactive elements must be reachable and operable by keyboard alone.
A visible focus indicator is required on every interactive element (WCAG 2.2 strengthens focus visibility requirements).
/* Minimum: do not remove focus outline without a replacement */
:focus-visible {
outline: 2px solid var(--color-focus);
outline-offset: 2px;
}
Never use outline: none without providing a custom focus style. The focus ring is not a design problem to eliminate — it is a navigation tool.
Interactive elements on touch devices must be at least 24×24px (WCAG 2.2) — 44×44px is the recommended comfortable minimum (Apple HIG, Material Design). Small icon buttons need padding to reach this size even if the visual icon is smaller.
Nothing on screen should flash more than 3 times per second.
Pages with repeated navigation must provide a "Skip to main content" link as the first focusable element, so keyboard users can bypass navigation on every page.
Users must be able to understand the content and how the UI works.
lang attribute on the <html> element: <html lang="fi"> or <html lang="en">lang on that elementaria-describedbyContent must be interpreted reliably by assistive technologies.
Use the correct HTML element for the job. Semantics convey role, state, and structure to screen readers for free.
<!-- Correct -->
<button>Save</button>
<nav aria-label="Main navigation">...</nav>
<h1>Page title</h1>
<!-- Wrong — requires manual ARIA to replicate what the element provides natively -->
<div onclick="save()">Save</div>
<div class="nav">...</div>
<div class="heading">Page title</div>
ARIA supplements HTML semantics where native elements fall short. It does not fix broken HTML.
Rule: no ARIA is better than incorrect ARIA. Incorrect ARIA actively breaks screen reader output.
Required patterns:
aria-label or aria-labelledby for components with no visible text labelaria-expanded on toggles, accordions, and dropdownsaria-live regions for dynamic content updates (toast notifications, search results)role="dialog" with aria-modal="true" on modal overlaysaria-current="page" on the active navigation itemDynamic updates (success toasts, loading states, error counts) must be announced to screen readers via aria-live or role="status" — they will not be announced automatically unless the focused element changes.
WCAG 1.4.3 explicitly states: "Text or images of text that are part of an inactive user interface component… have no contrast requirement."
This means:
| Area | Check |
|---|---|
| Contrast | All active text ≥ 4.5:1 (normal) or 3:1 (large/UI) |
| Contrast | Disabled elements exempt — intentionally low contrast is fine |
| Colour | Colour is never the only information carrier |
| Keyboard | All interactive elements reachable and operable by keyboard |
| Focus | Visible focus indicator on every interactive element |
| Touch | Interactive targets ≥ 44×44px on touch surfaces |
| Labels | Every input has a visible label (not just placeholder) |
| Errors | Validation errors identify the field and describe the problem in text |
| HTML | Semantic elements used correctly; ARIA only where needed |
| Language | lang attribute set on <html> |
| Skip link | "Skip to main content" as first focusable element |
| Live regions | Dynamic updates announced via aria-live or role="status" |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Derive a full UI palette from one or two brand colours — state variants, brand-tinted greys, semantic colours. Use when building or expanding a colour system.
日本語の概要は準備中です。原文の説明を表示しています。
Top bar, app launcher, tenant and environment cue, status bar. Use when designing the persistent shell or navigation between apps behind one login.
日本語の概要は準備中です。原文の説明を表示しています。
Product visuals must show the real product with real data. Use when building landing pages, hero sections, screenshots or demo panels.
日本語の概要は準備中です。原文の説明を表示しています。
Shape language across type, radius and icons carries brand personality. Use when starting a design system, picking icons or radius tokens, or reviewing visual consistency.
日本語の概要は準備中です。原文の説明を表示しています。
Rest, hover, active, focus, disabled and loading states, derived from the base colour. Use when designing buttons, links, inputs or any clickable component.
日本語の概要は準備中です。原文の説明を表示しています。
Rebuild a live web page 1:1 from measurement into Figma, Penpot or code, then verify it. Use when reproducing a page or checking a rebuild against the original.
日本語の概要は準備中です。原文の説明を表示しています。