Component rulebook

This material is a specification and reference set. It is not an accessibility scanner, a legal opinion, a certification, or evidence of a completed audit. Sample observations are explicitly untested, and WCAG 3 is draft guidance rather than the target here.

Component grammar rulebook

These are composable implementation contracts. Each selected pattern must still be evaluated against the entire applicable registry. WCAG, PATTERN and POLICY distinguish requirements, chosen implementations and stronger defaults. Source IDs resolve in the registry or source catalog.

R01 — Text and design tokens

WCAG: Apply SC-1.4.3 and SC-1.4.11 to the rendered text and essential non-text information. Assess actual adjacent colors in normal, hover, focus, selected and error states where applicable.

POLICY: Store approved foreground/background pairs rather than independently approved colors. A token change invalidates evidence for its consumers. Prefer a safety margin above contrast thresholds. Do not make gradients, imagery or transparency invisible to the test plan.

LAKA: One token repair is Minor Change; restructuring semantic color pairs and consumer checks is Structural Change.

R02 — Layout, zoom and text overrides

WCAG: Apply SC-1.4.4, SC-1.4.10 and SC-1.4.12 independently. Passing a narrow screenshot does not by itself establish zoom or text-override resilience.

POLICY: Prefer content-driven sizing; reserve fixed heights for cases with a tested overflow strategy. Check long translations, empty states, validation messages, sticky content and virtual keyboards. A legitimately two-dimensional table does not excuse surrounding page content from reflow.

Evidence: Record exact viewport in CSS pixels, zoom factor, text override settings and the affected task result.

R03 — Images, SVG and charts

WCAG: Apply SC-1.1.1 according to the object's purpose.

PATTERN: Use alt="" for a genuinely decorative HTML image. An icon-only action needs its purpose on the control; its decorative icon can be hidden. A complex chart may need a concise identification plus an equivalent explanation and/or accessible data representation.

POLICY: Do not auto-generate generic alt text or put an entire dashboard dataset in an image label. Include chart filtering and drill-down functions in the task contract. A table of values is not automatically equivalent to every meaningful chart relationship.

R04 — Headings, landmarks, lists and tables

WCAG: Apply SC-1.3.1, SC-1.3.2 and SC-2.4.6.

POLICY: Select markup for meaning, not appearance. Use an intentional heading hierarchy, real list structures and table header relationships. Do not label every visual card as a landmark. A rule such as exactly one h1 may be an editorial convention, not a universal WCAG success criterion.

Evidence: Compare the meaningful structure with the accessibility tree and reading experience after responsive layout changes.

R05 — Buttons and links

PATTERN: Use a button for an action and a link with a destination for navigation. Preserve expected native interaction unless a reviewed custom pattern is needed. [S-APG-FIRST]

WCAG: Independently assess SC-2.1.1, SC-2.4.3, SC-2.4.4, SC-2.4.7, SC-2.4.11, SC-2.5.2, SC-2.5.3, SC-2.5.8 and SC-4.1.2.

POLICY: Use at least 44×44 CSS pixels for primary touch controls where feasible. Document this as an enhanced product default, not the universal AA rule. [S-TARGET-ENHANCED]

R06 — Focus and sticky overlays

IF a keyboard-focused control is entirely covered by authored content
THEN fail the SC-2.4.11 assertion unless its specific notes resolve the case.
IF it is only partially covered
THEN assess the AA criterion accurately
     AND separately test the product policy of complete visibility.

POLICY: Keep primary actions and their focus indicators fully visible. Check headers, cookie banners, sticky footers, chat panels and on-screen keyboards. Do not repair an overlay by removing keyboard focus styles. [SC-2.4.7, SC-2.4.11]

R07 — Form controls and validation

WCAG: Compose SC-1.3.1, SC-1.3.5, SC-3.3.1, SC-3.3.2, SC-3.3.3 and SC-4.1.2 as applicable; use SC-4.1.3 for qualifying status messages.

PATTERN: Prefer persistent visible labels, programmatic associations, help before entry where needed and specific correction text. Associate inline error text with the affected field. Use a deliberately chosen error-summary focus strategy or status-announcement strategy; do not blindly apply both to every update.

POLICY: Preserve valid nonsensitive values after validation failure. Avoid repeated announcements during typing. Give a disabled submit control an understandable reason or allow submission to reveal clear validation feedback.

PATTERN: Define an accessible dialog name, meaningful initial focus, contained Tab/Shift+Tab navigation, inert background, a visible close action, Escape handling, and logical focus restoration. The appropriate initial target depends on content and consequence; it is not always the first form field. [S-DIALOG]

IF the triggering control still exists on close
THEN normally return focus to it.
ELSE move focus to the logical continuation of the user's task.

WCAG: Check SC-2.1.1, SC-2.1.2, SC-2.4.3, SC-2.4.7 and SC-4.1.2. Controlled focus containment is not an inescapable keyboard trap when the dialog can be exited. The exact APG pattern is implementation guidance, not a separate WCAG level.

R09 — Accordions and disclosure panels

PATTERN: Give each accordion heading an operable button, associate it with the panel and synchronize its expanded state. Enter/Space toggles when toggling is permitted. Define whether multiple panels may remain open; do not apply a one-open-panel policy by accident. [S-ACCORDION]

POLICY: Hidden panel content must not become stray focus stops. When hiding a panel that contains focus, move focus to a sensible remaining control. Test error messages inside collapsed panels.

R10 — Tabs

PATTERN: Use tablist, tab and tabpanel relationships with a single selected tab in this chosen pattern. Define arrow-key movement and manual or automatic activation. Automatic activation is appropriate only when showing the panel does not impose noticeable latency. [S-TABS]

POLICY: Loading panels must not steal focus, collapse container height unexpectedly or remove the active tab. Preserve the logical task when tabs are added or deleted.

R11 — Comboboxes, search and date entry

PATTERN: Choose a precise combobox variant before coding; distinguish focus from selection and synchronize the popup, current suggestion and resulting value. Preserve normal text-editing keys. Implement and test the selected APG interaction model. [S-COMBOBOX]

POLICY: For date input, offer an understandable typed-entry route when a calendar is supplied, validate locale expectations, and keep the picker keyboard operable. Test no matches, delayed results, errors and cancellation. This typed alternative is a product choice, not a universal standalone WCAG criterion.

R12 — Hover help and tooltips

WCAG: Apply all applicable branches of SC-1.4.13.

PATTERN: Make essential help available without hover-only interaction. For a chosen dismissible tooltip, Escape may provide dismissal without moving focus. Use a popover/dialog rather than a tooltip when the revealed content itself contains interactive controls.

POLICY: Do not hide the only field instruction or essential action in a transient overlay. Test keyboard, pointer travel and touch access separately.

R13 — Carousels and motion

WCAG: Evaluate SC-2.2.2 and SC-2.3.1; motion reduction does not replace pause controls or flash-safety evaluation.

PATTERN: A rotating carousel should expose rotation controls, stop rotation when keyboard focus enters, and not restart after focus-triggered stopping without a user request. Label slide-navigation controls and prevent hidden slides from confusing the reading sequence. [S-CAROUSEL]

POLICY: Default promotional carousels to no autoplay. Respect a reduced-motion preference for nonessential animation. This preference policy is supplemental; it is not by itself proof of AA conformance.

R14 — Dragging, sliders and sortable content

WCAG: Evaluate SC-2.1.1 and SC-2.5.7 separately, as well as gesture requirements where applicable.

PATTERN: A sortable record can have Move up/Move down or a choose-position control that works with keyboard and simple pointer activation. Keep the moved item identifiable and expose the new position appropriately.

POLICY: Test first/last positions, filtered lists, undo and concurrent updates. Do not assume that keyboard arrow support satisfies a requirement for a non-drag pointer route.

R15 — Authentication and repeated entry

WCAG: Evaluate every authentication step under SC-3.3.8 and repeated process information under SC-3.3.7.

PATTERN: Preserve password-manager and paste support; test the real account-recovery and one-time-code paths. A passwordless option is a candidate design, not a universal requirement or automatic proof of accessibility.

POLICY: Prefer authentication paths that do not depend on puzzles or personal-memory questions. Keep security controls intact; require a reviewed design rather than disabling security to pass a test.

R16 — Status updates, toasts and asynchronous data

WCAG: Classify whether a change is a status message under SC-4.1.3 before choosing semantics.

PATTERN: Give nonurgent progress/result messages suitable status semantics; reserve interruptive alerts for genuine urgency. Keep important outcomes readable and provide a way to recover missed information.

POLICY: Test repeated updates, deduplication, network errors and retry. A browser DOM snapshot cannot establish what a particular screen reader announced. Record actual assistive-technology behavior where required.

R17 — Checkout and destructive CRUD

WCAG: Apply SC-3.3.4 to covered commitments/data changes and SC-3.3.7 where process data repeats.

POLICY: Review meaningful order details before a purchase; provide clear recovery after failed submissions. For destructive actions, use a risk-appropriate confirmation or tested undo design. Prevent duplicate transactions as a separate functional-safety requirement.

Evidence: Record the complete path, including validation, payment failure, correction, success and confirmation. Test transactions in a sandbox with test credentials; do not place real orders without explicit authorization.

WCAG: Apply SC-2.4.1, SC-2.4.2, SC-2.4.5, SC-3.1.1, SC-3.1.2, SC-3.2.3, SC-3.2.4 and SC-3.2.6 where relevant.

POLICY: Keep the user's location understandable after client-side route changes. Distinguish a website navigation disclosure from an application menu pattern. Include translated content, help routes and error pages in the inventory.

R19 — Media and document handoffs

WCAG: Apply all relevant SC-1.2.x requirements rather than treating transcript, captions and audio description as interchangeable.

POLICY: Include customer-facing receipts, instructions and linked documents in scope decisions. This package does not provide a PDF/UA, native-app or email-client certification scheme. When those outputs are required, add a format-specific evaluation plan instead of assuming an accessible HTML page proves the exported document is accessible.

R20 — Third-party widgets and content authoring

POLICY: Inventory embedded payment fields, consent dialogs, maps, chat and rich-text editors. Require suppliers to provide test access and evidence; validate the integrated result independently. A supplier statement is not a substitute for an integration test.

If an essential dependency cannot be adequately tested, mark its evidence BLOCKED. Do not remove a broken step from an otherwise complete process merely to improve the report. [S-CONFORMANCE]

At Structural Change, enforce meaningful image descriptions, heading semantics and accessible table authoring in the CMS content model. At Paradigm Change, explore multiple independently usable interaction routes with maintained information and function parity.