Visual Design Research SystemEvidence, methods, patterns, and references

Comprehensive research synthesis · Version 1.3 · OKF-aligned

Design interfaces that make meaning visible.

A mobile-first reference system for visual hierarchy, evidence, color, accessibility, forms, native HTML, interactive surfaces, ARIA semantics, accessibility trees, iconography, data visualization, settings, notifications, and ethical UX. The interface and embedded knowledge graph use the same research model.

Explore findings
158research references
97synthesized findings
60implementation recommendations
36component contracts
Human-directed, AI-assisted research synthesisResearch owner and accountable editor: Jesse Graupmann · AI research and production contributor: OpenAI ChatGPT, GPT-5.6 Thinking · Underlying source creators remain independently attributed.

Governing doctrine

The integrated conclusion across visual evidence, perception, UX, color, and accessibility research.

A strong interface does not minimize information. It minimizes uncertainty about what matters, what belongs together, what can be acted upon, and how the conclusion was reached.

This system treats visual design as an evidence and interaction architecture. It separates durable empirical findings, formal frameworks, standards, and production precedents so future decisions can use the strongest accurate support.

Core principles

12 rules that govern hierarchy, evidence, interaction, semantics, and accessibility.

Numbers are presentation indexes for this catalog. Stable research IDs remain unchanged for links, citations, and machine-readable reuse.

01

Meaning before decoration

Every prominent visual treatment must communicate evidence, hierarchy, state, relationship, or action.

Strong color, filled containers, large typography, motion, borders, and icon backgrounds consume a limited salience budget. Remove them when they do not improve comprehension or operability.

02

Density is not clutter

Dense interfaces can remain highly usable when grouping, comparison, labels, and alignment are disciplined.

Do not respond to confusion by deleting information first. Diagnose ordering, representation, spacing, alignment, labels, and redundant visual chrome.

03

Task before component

Start with the user question, decision, data type, and required comparison—not with cards, charts, or modals.

A technically polished interface can still solve the wrong problem or represent the wrong abstraction. Component choice occurs after task and evidence modeling.

04

Comparison before claim

A value becomes meaningful through a baseline, target, prior state, control, distribution, or peer comparison.

Arrange comparable evidence in the same visual field. Do not force users to remember values from another tab, slide, or card.

05

Recognition before recall

Keep important options, labels, scope, state, and recovery paths visible or immediately retrievable.

Hidden interactions and unlabeled icons transfer the interface model into the user’s memory. Visible signifiers and persistent state reduce that burden.

06

Accessibility as architecture

Contrast, semantics, focus, reflow, input targets, redundant encoding, and user preferences belong in the design system.

Accessibility is not a final palette audit. It determines token contracts, component states, content structure, interaction recovery, and responsive behavior.

07

Make conclusions reconstructable

Expose enough evidence, method, source, uncertainty, and comparison for readers to challenge or reproduce the conclusion.

A confidence label or signal score without an inspectable basis is an assertion. Provenance should remain quiet but accessible.

08

Guide first, then permit exploration

State the main finding, show the critical evidence, annotate the relationship, and then allow filtering and inspection.

Do not make users derive the thesis from an unstructured dashboard. Do not prevent them from checking the thesis against the evidence.

09

Native semantics before custom behavior.

Begin with the HTML element that already owns the interaction lifecycle. Replace it only when the task cannot be represented adequately.

  • Prefer native labels, form controls, details, dialog, and popover behavior
  • Document every native behavior a custom widget must recreate
  • Use progressive enhancement for emerging primitives
10

Classify behavior before naming the surface.

Modality, anchoring, persistence, focus, dismissal, risk, and user intent determine the component; visual shape does not.

  • Separate navigation, selection, action, disclosure, and configuration
  • Treat drawers and sheets as presentation modes
  • Match interruption to consequence
11

ARIA is a semantic contract, not an interaction implementation.

A role communicates expected meaning and state to accessibility APIs. Authors still own keyboard behavior, focus, pointer interaction, visual feedback, and state synchronization.

  • Prefer native semantics when available
  • Implement the complete keyboard model for custom composites
  • Keep DOM, visual state, and ARIA state synchronized
12

The accessible name is part of the interface API.

Names distinguish controls and enable screen-reader navigation, speech activation, automation, and reliable comprehension. They must be concise, stable, and aligned with visible wording.

  • Use native visible labels first
  • Include visible label text in the accessible name
  • Inspect computed names rather than assuming markup intent
13

Autonomy is a product constraint, not a conversion trade-off.

Optimization is unacceptable when it improves a business metric by making it materially harder for people to understand, express, or reverse their actual preferences.

  • Measure task success and preference fidelity alongside conversion
  • Escalate asymmetric choice architecture to ethical review
  • Treat vulnerable-user impact as a release criterion
14

Equivalent choices deserve equivalent clarity and effort.

Accepting, declining, subscribing, cancelling, consenting, and withdrawing should not be separated by deceptive prominence, hidden paths, or disproportionate friction.

  • Use comparable wording and visual weight
  • Keep material options on the same decision layer
  • Budget friction symmetrically across opposite choices
15

A decision remains ethical only if its future consequences stay visible and reversible.

Transparent entry cannot compensate for silent renewal, hidden future fees, difficult withdrawal, or changed terms that users cannot reasonably inspect.

  • Show recurring and delayed consequences before commitment
  • Make withdrawal reachable throughout the lifecycle
  • Preserve receipts, history, and reversal paths
16

Observed interoperability before certification.

A semantic contract is not production-ready until its behavior has been observed in representative browsers, input modes, and assistive technologies.

  • Separate structural pass from production certification
  • Record environment, expected result, observed result, and evidence date
  • Treat automated checks as triage rather than complete user evidence

Research map

The major concept areas and how they inform design decisions.

Open a domain to inspect its core concepts, governing takeaway, and supporting reference keys.

Visual hierarchy & information densityHierarchy is an attention-routing system built from position, size, weight, contrast, spacing, grouping, and sequence.

Core concepts

  • salience budget
  • macro/micro reading
  • proximity as semantics
  • content dispersion
  • finding-oriented headings

Governing takeaway

One dominant focal point, a small set of secondary anchors, and quiet supporting metadata.

Visual evidence & TufteVisual storytelling should construct a truthful, inspectable argument from integrated evidence rather than decorative narrative.

Core concepts

  • graphical integrity
  • data-ink
  • small multiples
  • layering and separation
  • direct annotation
  • provenance

Governing takeaway

Show enough evidence for the reader to reconstruct the conclusion while making the principal finding immediately visible.

Graphical perception & visual grammarVisual channels have different strengths. Position and length usually support more accurate quantitative comparison than area, angle, volume, or color.

Core concepts

  • visual variables
  • expressiveness
  • effectiveness
  • aligned comparison
  • task-specific encoding

Governing takeaway

Use the strongest perceptual channel appropriate to the data relationship and required precision.

Attention, scanning & cognitionUsers scan before reading. Unique features can guide attention quickly, while combinations of subtle differences create slower visual search.

Core concepts

  • preattentive features
  • front-loaded wording
  • first impressions
  • recognizable patterns
  • aging and peripheral attention

Governing takeaway

Use one dominant visual distinction for important exceptions and keep critical information inside the primary scan path.

Discoverability & interaction guidanceActions must look possible, produce timely feedback, expose state, and provide recovery.

Core concepts

  • signifiers
  • direct manipulation
  • recognition over recall
  • system status
  • progressive disclosure
  • target acquisition

Governing takeaway

Make the interaction model visible during use rather than requiring documentation or memory.

Narrative, annotation & memoryEffective digital stories balance author guidance with reader agency and place explanatory annotations adjacent to supporting evidence.

Core concepts

  • guided exploration
  • annotation
  • object constancy
  • memorability
  • meaningful embellishment

Governing takeaway

State the finding, guide attention to the evidence, then permit verification and exploration.

Color systems & palettesColor is an information-encoding system. Hue, lightness, and chroma perform different jobs and should map to explicit semantic roles.

Core concepts

  • neutral-first structure
  • semantic tokens
  • sequential palettes
  • diverging palettes
  • qualitative palettes
  • contextual color meaning

Governing takeaway

Reserve saturated color for actions, exceptions, selection, and analytical focus—not general decoration.

Contrast & accessible colorA color does not pass accessibility; a specific foreground/background/state pairing does.

Core concepts

  • 4.5:1 text contrast
  • 3:1 meaningful graphics
  • color not sole channel
  • focus visibility
  • forced colors
  • theme preferences

Governing takeaway

Treat WCAG as the compliance floor, then validate perception and task success in context.

Icon communicationThe glyph should carry the concept; color should modify state or emphasis. Important and unfamiliar actions need visible labels.

Core concepts

  • icon plus label
  • accessible names
  • monochrome utilities
  • semantic shape grammar
  • large targets
  • redundant selected state

Governing takeaway

Use icons to reinforce meaning, not to make the user guess it.

Responsive & preference-aware deliveryResponsive design must preserve information and task capability while adapting representation, density, and navigation.

Core concepts

  • semantic zoom
  • 320 CSS-pixel reflow
  • text spacing
  • light/dark modes
  • increased contrast
  • reduced transparency

Governing takeaway

Change layout and representation—not the meaning or evidence available to the user.

Ethical interaction designEquivalent choices require equivalent clarity and effort. Interfaces should not manufacture urgency, hide consequences, or obstruct recovery.

Core concepts

  • dark patterns
  • consent parity
  • sponsorship disclosure
  • reversibility
  • transparent defaults

Governing takeaway

Optimize task success and informed decisions rather than clicks, lock-in, or accidental consent.

Forms & structured input

Forms are structured conversations that combine persistent labels, semantic grouping, constraints, validation, recovery, and confirmation.

  • native form lifecycle
  • persistent labels
  • fieldset and legend
  • error summaries
  • input preservation
  • explicit save semantics

A form is successful when users can understand, complete, correct, and confirm it without losing their work.

Interactive surfaces & interruption

Menus, popovers, dialogs, sheets, toasts, and settings are selected through a common model of intent, focus, persistence, dismissal, and consequence.

  • surface selection matrix
  • notification escalation ladder
  • focus restoration
  • light dismiss
  • responsive transformation
  • settings reachability

Use the least interruptive surface that preserves discoverability, context, state, and recovery.

ARIA, accessibility trees & semantic contracts

ARIA supplements native HTML by exposing roles, names, states, properties, and relationships through browser accessibility trees to platform APIs and assistive technologies.

  • native semantic baseline
  • accessibility tree
  • accessible name computation
  • role contracts
  • state synchronization
  • landmarks
  • composite focus
  • live regions
  • ARIA-AT interoperability

Deceptive design, autonomy & ethical choice architecture

Patterns that deceive, coerce, obstruct, pressure, or materially impair informed choice across acquisition, consent, pricing, subscriptions, privacy, and agent-mediated interactions.

  • autonomy
  • choice symmetry
  • friction parity
  • obstruction
  • sneaking
  • interface interference

Executable design laboratory

Runnable fixtures connect research claims to semantic markup, keyboard behavior, focus and dismissal traces, responsive transformations, and recorded evidence.

  • fixture registry
  • feature detection
  • keyboard trace
  • focus restoration
  • support matrix
  • automated checks
  • manual evidence
  • report export

A design rule becomes operational when teams can run it, inspect the result, record the environment, and protect it from regression.

Research findings

97 synthesized conclusions translated into design-system implications.

Each finding distinguishes the observed or documented insight from its practical design implication. Reference keys link directly to the detailed source register.

Visual hierarchy & information density5 findings

Information density and visual density are different variables.

High information density can remain understandable when related values are aligned, grouped, consistently labeled, and visually quiet. Sparse layouts can still be confusing when every element competes equally.

Design implication: Prefer structural clarity over indiscriminate removal of information.

Hierarchy should communicate reading order before the user reads.

The first viewport should expose page identity, scope, the dominant finding, and the next useful action.

Design implication: Use position, scale, weight, and spacing before adding decorative color or containers.

Spacing is semantic.

Proximity communicates belonging. Larger gaps should separate groups; smaller gaps should bind related labels, values, and actions.

Design implication: Use spacing tokens as relationship rules, not arbitrary decoration.

Strong visual treatments require a salience budget.

Saturated color, filled badges, large icons, shadows, borders, and motion are preattentive signals. Repeating them everywhere removes hierarchy.

Design implication: Reserve strong treatments for the primary action, selected analytical focus, or genuine exception.

Finding-oriented headings outperform category-only headings for communication.

A category such as “Security” organizes content. A heading such as “Identity is becoming the control boundary for agent tools” communicates meaning.

Design implication: Use category labels as quiet context and the finding as the primary heading.

Visual evidence & Tufte5 findings

Visual storytelling is an evidence architecture.

The strongest structure connects claim, evidence, comparison, mechanism, implication, qualification, and source.

Design implication: Do not separate the conclusion from the evidence needed to evaluate it.

Graphical integrity applies to UI emphasis as well as charts.

A small change should not receive the same alarm treatment as a major change. Visual magnitude and urgency should correspond to the underlying effect.

Design implication: Calibrate size, color, and status emphasis to evidence magnitude.

Small multiples preserve context and comparison.

Repeated consistent structures let users learn the visual grammar once and focus on variation across time, environments, products, or scenarios.

Design implication: Prefer small multiples to overplotted charts or animation when comparison matters.

Direct labels and annotations reduce decoding travel.

Labels, event markers, and explanatory notes should be placed adjacent to the evidence they describe rather than in remote legends or paragraphs.

Design implication: Annotate deployments, thresholds, policy changes, and major inflection points directly.

Confidence and signal scores need an inspectable basis.

Readers should be able to determine the sources, independence, time window, classification logic, and uncertainty behind an analytical score.

Design implication: Expose evidence counts and method behind signal labels.

Graphical perception & visual grammar3 findings

Aligned position and length are generally the most precise common visual encodings.

Area, angle, volume, and saturation impose more perceptual estimation error for exact comparisons.

Design implication: Prefer tables, dot plots, and bars for operational and analytical precision.

Truthful encoding is necessary but not sufficient.

A chart can represent the data correctly and still use an ineffective visual channel for the task.

Design implication: Evaluate both expressiveness and perceptual effectiveness.

Chart choice should follow the relationship being explained.

Time, distribution, hierarchy, flow, geography, dependency, and exact comparison require different representations.

Design implication: Do not use cards or pie charts as universal defaults.

Attention, scanning & cognition4 findings

A single distinctive visual feature can guide search faster than a conjunction of subtle features.

Finding a unique color or orientation is easier than finding an item defined by a combination such as medium-blue, thin-border, slightly different icon.

Design implication: Use one strong distinguishing property for important exceptions.

The 50-millisecond result concerns visual appeal—not complete understanding.

Very brief exposure can produce stable aesthetic judgments, but it does not prove users comprehend navigation, content, or usability in that interval.

Design implication: Optimize the first viewport for immediate orientation without overstating the research.

Users scan headings and leading words before committing to reading.

Meaningful headings and front-loaded labels improve the layer-cake scan pattern and reduce wasted inspection.

Design implication: Put differentiating words first and avoid generic “Learn more” actions.

Peripheral placement is a material discoverability risk for older adults.

Critical alerts and actions placed only at viewport edges can be missed, especially under clutter or complex search.

Design implication: Keep critical state and primary actions in the central reading path.

Discoverability & interaction guidance6 findings

Signifiers must communicate what is interactive.

A passive pill that looks like a filter creates false affordance. A control that looks like text hides capability.

Design implication: Align visual treatment with actual behavior.

Recognition is easier than recall.

Visible labels, current filters, recent choices, state, and recovery paths reduce memory demand.

Design implication: Do not hide important options behind undocumented gestures or hover.

System status is part of the content.

Users need to know what scope is active, whether results are loading, what changed, when data refreshed, and whether an action completed.

Design implication: Use persistent scope, progress, result counts, and clear outcome feedback.

Progressive disclosure works only for secondary content.

Hiding primary evidence, comparison values, or necessary controls may make a page look simpler while increasing cognitive and interaction cost.

Design implication: Keep essential meaning visible and collapse only supporting depth.

Direct manipulation should be incremental and reversible.

Visible objects, immediate feedback, preview, undo, reset, and preserved context reduce the gap between intention and outcome.

Design implication: Make filters, sorting, pinning, and generated classifications reversible.

Target size and distance affect acquisition time.

A compact glyph can remain visually small while living inside a substantially larger interactive target.

Design implication: Use at least the normative minimum and larger platform targets for frequent mobile actions.

Narrative, annotation & memory3 findings

Narrative and exploration should coexist.

Author guidance helps users notice the main finding. Reader control enables verification and discovery.

Design implication: Lead with a conclusion and annotation, then expose filters, detail, and raw evidence.

Animation is useful for continuity, not decoration.

Transitions can help users track reordering or changes in representation, but they can delay access and make prior states disappear.

Design implication: Use motion for object constancy and honor reduced-motion preferences.

Minimalism and memorability are not identical.

Meaningful imagery, distinctive titles, and selective embellishment can improve recognition and recall without necessarily damaging comprehension.

Design implication: Reject arbitrary decoration, not all visual identity.

Color systems & palettes7 findings

Hue, lightness, and chroma are separate communication channels.

Hue distinguishes categories; lightness supports order and contrast; chroma controls emphasis and attention.

Design implication: Do not treat color as a single decorative variable.

Traditional color harmony does not guarantee usable UI color.

A harmonious palette may fail text contrast, state discrimination, dark mode, forced colors, or color-vision accessibility.

Design implication: Prioritize semantics, accessibility, discriminability, and state before brand harmony.

Palette family must match data semantics.

Sequential palettes represent ordered magnitude, diverging palettes represent deviation around a meaningful midpoint, and qualitative palettes represent unordered categories.

Design implication: Do not select a palette solely because it looks balanced.

Rainbow scales create false boundaries and weak ordering.

Uneven perceptual transitions can overemphasize some ranges and flatten others.

Design implication: Use perceptually ordered sequential or diverging scales such as Viridis or Cividis where appropriate.

Color semantics are contextual and learned.

Associations can accelerate interpretation when they fit the subject, but they vary across concepts, cultures, and contexts.

Design implication: Treat “blue means trust” and similar claims as hypotheses, not universal laws.

Neutral-first palettes preserve semantic capacity.

Neutral surfaces and text should carry most structure so saturated colors remain available for state, selection, action, and analytical focus.

Design implication: Avoid category-colored card backgrounds and multicolored metadata icons.

UI palettes and data palettes require separate contracts.

A button color communicates interaction priority; a chart color must support discrimination, ordering, and comparison. Reusing them creates semantic collisions.

Design implication: Create dedicated token namespaces for action, state, accent, and data visualization.

Contrast & accessible color6 findings

Contrast is pairwise, contextual, and stateful.

A color does not pass by itself. Foreground, background, font characteristics, state, and compositing determine the result.

Design implication: Test every permitted token pairing across default, hover, pressed, selected, focused, disabled, light, dark, and forced-color modes.

Secondary metadata still requires readable contrast.

Dates, sources, timestamps, helper text, and captions do not receive a lower contrast requirement merely because they are visually subordinate.

Design implication: Create hierarchy with typography, spacing, and placement—not illegible gray.

Color must not be the sole carrier of meaning.

Selection, warning, error, required state, and chart categories need additional text, icon, shape, position, pattern, or numeric cues.

Design implication: Design redundant encoding into components rather than adding it during audit.

WCAG is the compliance floor, not the end of perceptual quality.

Passing ratios does not guarantee comfortable reading, strong hierarchy, or category discrimination.

Design implication: Combine automated checks with task testing, CVD simulation, grayscale, zoom, and real-device review.

Light and dark appearances should be treated as separate adaptive palettes.

Polarity effects vary by user and task. Simple inversion often breaks contrast, chroma, shadows, and chart discrimination.

Design implication: Respect system preference, allow override, and validate each theme independently.

Focus is a first-class visual layer.

Keyboard location must remain obvious on every surface, avoid clipping, differ from selection, and survive sticky headers and forced colors.

Design implication: Use dedicated focus tokens and test obscuration and scroll behavior.

Icon communication4 findings

The icon shape should identify the concept; color should modify state.

Monochrome utility icons are easier to theme, validate, and adapt than multicolored glyphs.

Design implication: Use currentColor and semantic foreground tokens for controls.

Visible labels materially support initial icon use.

Icon-only interfaces increase interpretation and learning demands, especially for unfamiliar or consequential actions.

Design implication: Use icon plus persistent text for primary navigation and important functions.

Accessible names describe function, not appearance.

An icon button should be named “Save article,” not “floppy-disk icon.”

Design implication: Align visible labels and programmatic names; hide decorative SVGs from assistive technology.

Icon containers consume disproportionate salience.

A colored circle or rounded square behind an icon makes minor metadata appear operationally important.

Design implication: Reserve containers for major actions, identity, strong state, or visible target boundaries.

Responsive & preference-aware delivery3 findings

Responsive design should adapt representation, not remove evidence.

Mobile layouts may transform a table into labeled comparison rows, but should not silently drop columns needed for understanding.

Design implication: Define semantic zoom levels for overview, section, item, and detail.

Sticky headers need one measured offset contract.

Independent fixed heights cause stacked or overlapping headers when content wraps, browser text scales, or safe areas change.

Design implication: Measure the app header and expose one CSS variable used by every sticky subheader and scroll margin.

Preference-aware delivery is broader than dark mode.

Interfaces can respond to color scheme, increased or reduced contrast, forced colors, reduced motion, and reduced transparency.

Design implication: Treat these as supported design-system modes, not component exceptions.

Ethical interaction design2 findings

Equivalent choices need equivalent clarity and effort.

Consent, rejection, enrollment, cancellation, and destructive recovery should not be asymmetrically designed to advance business goals.

Design implication: Audit choice prominence, wording, defaults, and effort symmetry.

Engagement metrics are not task-success metrics.

More clicks may indicate interest or may indicate confusion, poor discoverability, and unnecessary interaction cost.

Design implication: Measure location time, comparison accuracy, recovery, comprehension, confidence, and accessibility outcomes.

Forms & structured input6 findings

Native semantics reduce interaction lifecycle debt.

Native form controls, dialog, details, and popover behavior inherit browser participation, keyboard behavior, state, validation, and platform integration that custom widgets must otherwise reproduce.

Design implication: Require a native-element assessment before approving a custom interaction component.

Forms are structured conversations, not collections of inputs.

Usable forms establish purpose, request only necessary information, group related questions, explain constraints, and confirm outcomes.

Design implication: Design the form sequence and recovery model before styling individual fields.

Persistent labels outperform placeholder-dependent identification.

A visible label remains available after entry and creates a larger activation target while placeholder-only identification disappears and can be confused with example data.

Design implication: Use explicit labels for every field and reserve placeholders for optional examples.

Form grouping reduces perceptual and cognitive scope.

Fieldset, legend, optgroup, headings, and visual proximity make relationships explicit and let users process smaller meaningful groups.

Design implication: Group controls in code and visually; keep legends concise and individual labels self-explanatory.

Error recovery requires summary, field guidance, and preserved work.

A color change or generic failure message does not explain what failed, where it failed, or how to correct it.

Design implication: Provide form-level results, linked inline errors, corrective language, preserved valid input, and clear retry or confirmation.

Custom controls inherit the complete form contract.

A custom control must address naming, value, validation, form association, disabled state, reset, autofill, keyboard, touch, and assistive-technology behavior.

Design implication: Gate custom controls with a lifecycle checklist and require form-associated custom elements only where they materially help.

Interactive surfaces, settings & interruption14 findings

Interactive surfaces differ primarily by interruption and persistence.

Inline content, disclosures, popovers, drawers, dialogs, alerts, and toasts can contain similar content but impose different focus, dismissal, and context costs.

Design implication: Choose the lowest-interruption surface that still meets the user’s task and consequence requirements.

Focus is application state, not decorative styling.

Opening, navigating, replacing, and closing a surface changes the user’s location in the application and must have deterministic focus behavior.

Design implication: Document entry, containment, escape, action completion, and restoration for every interactive surface.

Dismissal policy must reflect data-loss risk.

Outside click, Escape, navigation, timeout, and replacement are not equivalent when a surface contains draft or consequential state.

Design implication: Define whether each dismissal path saves, cancels, preserves a draft, warns, or is disabled.

Website navigation is not an application menu.

ARIA menus use specialized arrow-key and roving-focus behavior that is unnecessary for most site navigation and can conflict with ordinary link expectations.

Design implication: Use nav, links, and disclosure buttons for typical navigation; reserve menu roles for application-style commands.

Context menus are accelerators, not primary discovery mechanisms.

Context menus are hidden until a secondary click, long press, or keyboard command, so many users will never discover them.

Design implication: Keep context menus short and ensure important commands are also available in the visible interface.

Toasts are unsuitable for critical or durable information.

Transient notifications can be missed, vanish before comprehension, and provide no durable recovery record.

Design implication: Use toasts for noncritical confirmation; use inline, banner, history, or dialog surfaces when information persists or requires action.

Notification persistence should match consequence duration.

A condition that remains true after a message disappears should have a persistent representation, while routine confirmations should not dominate attention.

Design implication: Define a notification escalation ladder from inline guidance through alert dialog based on urgency and durability.

Drawers and sheets are presentation modes, not semantics.

A side or bottom panel may represent navigation, complementary information, nonmodal editing, or a blocking dialog, each with different semantic and focus requirements.

Design implication: Choose nav, aside, section, or dialog semantics based on behavior rather than slide-in animation.

Mobile layouts should transform interaction surfaces, not merely resize them.

A desktop popover or side inspector may become a sheet or full-screen task on compact screens while retaining the same state and save model.

Design implication: Document responsive surface transformations and verify semantic, focus, and persistence equivalence.

Settings are navigable state models, not modal forms.

Settings contain persistent system state, dependencies, defaults, consequences, and repeated retrieval tasks that require stable navigation and search.

Design implication: Provide categories, deep links, current-state summaries, search, reset, dependencies, and clear save semantics.

Search and deep links materially improve settings reachability.

Users often know the setting concept but not the category or location where a product stores it.

Design implication: Index titles, synonyms, descriptions, and affected features; make individual settings directly addressable.

Advanced HTML interaction primitives require progressive enhancement.

Popover is broadly available, while newer declarative command and dismissal features may have uneven deployment and behavior across product support matrices.

Design implication: Define baseline, enhanced, and experimental tiers with feature detection and tested fallbacks.

Disclosure, tabs, menus, and popovers are not interchangeable.

They may all hide and reveal content, but their user intent, semantics, keyboard models, persistence, and comparison affordances differ.

Design implication: Classify the task as navigation, selection, command, disclosure, or contextual information before choosing a component.

Overlay stacking must be deliberately constrained.

Nested dialogs, cascading popovers, toasts over modals, and drawers opening menus create ambiguous Escape order, focus restoration, and visual hierarchy.

Design implication: Define a top-layer policy, prohibit unnecessary nested modality, and test replacement and restoration sequences.

ARIA, accessibility trees & semantic contracts23 findings

Native HTML is the first semantic layer.

HTML elements already carry implicit roles, naming mechanisms, relationships, keyboard behavior, and browser accessibility mappings.

Design implication: Use ARIA only to fill a real semantic gap or express dynamic state that native HTML cannot convey.

ARIA changes the accessibility tree, not the component behavior.

Adding a role does not add keyboard handling, focus movement, pointer behavior, validation, selection logic, or visual styling.

Design implication: Treat every custom ARIA widget as an implementation contract with explicit behavior and tests.

Role choice commits the interface to user expectations.

Roles communicate both purpose and conventional operation; a menu, tab, grid, tree, and listbox each imply different states and keyboard behavior.

Design implication: Select roles from the task model and reject roles chosen only because their names resemble the visual design.

Allowed ARIA is constrained by the host element.

ARIA in HTML defines which role overrides and aria-* attributes are valid, redundant, or prohibited on each HTML element.

Design implication: Automate HTML–ARIA conformance checks and prefer implicit native semantics over redundant explicit roles.

Accessible names are computed, not copied from one attribute.

Browsers follow an ordered algorithm across aria-labelledby, aria-label, native labeling, contents, and fallback sources to produce one flat name string.

Design implication: Inspect the computed accessible name and avoid conflicting or empty high-precedence naming attributes.

Visible labels should anchor accessible names.

When a visible text label differs from the programmatic name, speech-input users may be unable to activate the control by saying what they see.

Design implication: Use visible text as the native label or include the visible wording at the start of the accessible name.

Names and descriptions serve different jobs.

The accessible name identifies the object; the description supplies optional supporting context. Long instructions inside a name create repetitive, hard-to-scan announcements.

Design implication: Keep names concise and place constraints, help, and errors in descriptions or nearby structured content.

State attributes are not interchangeable.

aria-current, aria-selected, aria-checked, aria-pressed, aria-expanded, aria-invalid, aria-busy, and aria-disabled represent different concepts and apply to different roles.

Design implication: Create a semantic state taxonomy and prohibit generic selected or active styling from driving arbitrary ARIA attributes.

ARIA state must change with the visible state.

Stale aria-expanded, aria-selected, aria-checked, or aria-busy values create a second, contradictory interface for assistive-technology users.

Design implication: Update visual, DOM, and ARIA state in one transaction and test every transition.

Required context and owned roles make structure part of the contract.

Some roles are meaningful only inside specific parent roles or with specific descendants; malformed hierarchy can be ignored or misrepresented.

Design implication: Validate parent/child role relationships, especially list/listitem, tablist/tab, menu/menuitem, grid/row/cell, and tree/treeitem.

aria-controls describes a relationship but does not manage it.

The attribute does not show, hide, move focus, establish ownership, or guarantee assistive-technology navigation to the controlled element.

Design implication: Use aria-controls only where the relationship is meaningful and implement the actual interaction separately.

aria-owns is a high-risk accessibility-tree override.

aria-owns can reorder or reparent accessible objects independently of the DOM, making reading, focus, and maintenance harder to reason about.

Design implication: Prefer correct DOM containment; require an explicit exception and accessibility-tree test before using aria-owns.

aria-hidden and presentation solve different problems.

aria-hidden removes a subtree from the accessibility tree, while role none/presentation suppresses an element’s semantics but ordinarily retains descendant content.

Design implication: Never place aria-hidden on a focusable element or an ancestor of focusable content; use none/presentation only to remove misleading wrapper semantics.

Landmarks translate visual layout into navigable structure.

Meaningful banner, navigation, search, main, complementary, form, and contentinfo regions help screen-reader users understand and jump through page structure.

Design implication: Use native sectioning elements, label repeated landmarks, and avoid turning every card into a region.

Landmark value declines when regions become numerous or generic.

Over-landmarking creates a noisy navigation list and weakens the distinction between page-level regions and ordinary sections.

Design implication: Maintain a landmark budget and reserve named regions for content important enough to navigate to directly.

Composite widgets need a deliberate focus strategy.

Menus, tabs, grids, trees, toolbars, and listboxes ordinarily expose one page tab stop and use roving tabindex or aria-activedescendant internally.

Design implication: Document which strategy is used, where DOM focus lives, how virtual focus is announced, and how users exit the component.

Automatic selection should follow focus only when latency is negligible.

In tabs and similar widgets, automatic activation can make arrow-key exploration slow or disruptive when content loads or changes context.

Design implication: Use manual activation when selection triggers latency, navigation, expensive rendering, or consequential state.

Static tables and interactive grids are different products.

A table preserves document reading and ordinary tab order; a grid moves users into an application-style composite requiring full cell navigation.

Design implication: Use native tables for information and adopt grid only when interactive density justifies the keyboard and interoperability burden.

Live regions require an interruption policy.

Status, alert, log, timer, aria-live, aria-atomic, aria-relevant, and aria-busy affect when and how changing content is announced without focus.

Design implication: Map urgency and persistence to the least disruptive live-region behavior and avoid duplicate announcements.

aria-disabled communicates state but does not disable behavior.

Unlike the HTML disabled attribute, aria-disabled does not remove focusability, suppress events, or block form submission.

Design implication: Use native disabled by default; use aria-disabled only when discoverability requires focus and implement all blocked behavior explicitly.

APG examples are patterns to study, not components to copy blindly.

APG repeatedly warns that example code may have browser, assistive-technology, mobile, and touch support gaps.

Design implication: Use APG for the semantic and keyboard contract, then implement within the product system and run real interoperability tests.

Accessibility-tree inspection closes the gap between markup intent and user-agent output.

The DOM and source attributes do not show the final computed role, name, description, state, and relationships exposed to assistive technologies.

Design implication: Add accessibility-tree inspection and computed-name snapshots to component review and regression testing.

ARIA-AT evidence guides prioritization but does not replace product testing.

Interoperability reports cover specific examples, browsers, assistive technologies, versions, configurations, and assertions.

Design implication: Use ARIA-AT to identify risk, then test the actual component with supported browser and assistive-technology combinations.

Executable laboratory · 10 findings

Executable fixtures expose contract drift.

Static documentation can remain correct while the shipped behavior diverges in focus, keyboard, dismissal, state, or responsive transformation.

Design implication: Generate fixtures and tests from the same component contract used by the handbook.

Automated checks are necessary but cannot certify usability or interoperability.

Machines can detect many structural failures, but they cannot fully determine announcement quality, comprehension, task success, or assistive-technology behavior.

Design implication: Separate automated, manual, assistive-technology, and disabled-user evidence in every report.

Feature detection is safer than browser-name assumptions.

Declarative commands, dialog dismissal, popovers, and anchor positioning evolve independently across engines and product support windows.

Design implication: Detect capabilities at runtime and retain a tested fallback for every progressive feature.

Browser support is a component-contract property.

A feature may be valid HTML but unsuitable as a baseline dependency for an organization’s device and assistive-technology matrix.

Design implication: Record baseline, progressive, and experimental tiers with detection, fallback, and verification date.

Test evidence is versioned product data.

An unlabeled statement that a component “works with VoiceOver” becomes stale as browser, OS, component, and assistive-technology versions change.

Design implication: Preserve the complete environment tuple, fixture version, expected behavior, result, notes, and evidence date.

Focus and dismissal traces reveal hidden application state.

Many severe interaction failures occur during entry, replacement, Escape, outside click, submission, and restoration rather than in the resting visual state.

Design implication: Record focus transitions and close reasons as first-class fixture output.

One fixture registry prevents documentation and implementation drift.

When examples, test expectations, and component contracts use unrelated IDs and copies, fixes do not propagate reliably.

Design implication: Use stable fixture IDs linked to component IDs, sources, checks, and known limitations.

Responsive transformations are separate behavioral variants.

A desktop popover becoming a mobile sheet can change focus containment, dismissal, context visibility, and save behavior even when the task name stays the same.

Design implication: Test each supported transformation as a named fixture variant.

Ethical parity can be partially measured but not inferred from style alone.

Computed size, contrast, order, and layer depth can reveal asymmetry, but truthfulness, consequence, and vulnerability require contextual review.

Design implication: Combine parity calculations with the autonomy assessment rather than issuing an automated legal verdict.

Production certification requires observed representative use.

Structural validity, linting, and simulated fixtures do not establish task success across real devices, assistive technologies, and disabled users.

Design implication: Keep release status explicitly provisional until representative evidence satisfies the declared support matrix.

Implementation recommendations

60 prioritized actions for building and governing the system.

P0 establishes the information and accessibility foundation. P1 defines the core experience. P2 adds advanced analytical and machine-readable capability.

P0 · Foundation6 recommendations

P0System foundation

Adopt a task-to-visual contract before rendering.

Prevents card-first and chart-first generation.

Implementation guidance
  • Identify audience and decision
  • Define primary questions and comparisons
  • Classify data types and uncertainty
  • Select interaction and density requirements
  • Choose the representation only after the contract is complete
P0Content model

Use a claim–evidence–comparison–implication schema.

Creates a reusable communication unit for articles, cards, presentations, and AI-generated summaries.

Implementation guidance
  • Claim: what changed
  • Evidence: what supports it
  • Comparison: compared with what
  • Explanation: likely mechanism
  • Implication: why it matters
  • Qualification: uncertainty or exception
  • Provenance: source and method
P0Design tokens

Build primitive, semantic, and component token layers.

Separates intent from implementation and enables safe remapping across themes and preferences.

Implementation guidance
  • Primitive palette values
  • Semantic roles for text, surface, action, state, focus, and data
  • Component-specific state tokens
  • Independent light, dark, increased-contrast, and forced-color mappings
P0Accessibility

Create an allowed contrast-pair matrix.

Contrast belongs to permitted token combinations, not individual colors.

Implementation guidance
  • Normal text ≥ 4.5:1
  • Large text ≥ 3:1
  • Meaningful graphics and boundaries ≥ 3:1
  • Validate every interactive state
  • Test final composited colors, not source alpha values
P0Evidence

Make analytical classifications inspectable.

Signal, confidence, priority, and risk labels must be auditable.

Implementation guidance
  • Show source count and independence
  • Expose time window
  • Document classification rules
  • Separate observed fact from inference and forecast
  • Provide source links and limitations
P0Semantics

Use semantic HTML as the structural baseline.

Improves navigation, accessibility, printing, parsing, and future LLM extraction.

Implementation guidance
  • Landmarks for header, nav, main, aside, footer
  • Logical heading hierarchy
  • time, figure, figcaption, table, details, summary
  • Buttons for actions and anchors for navigation
  • Accessible names aligned with visible labels
P0Semantic architecture

Create a native-semantics and ARIA override matrix.

Teams need a deterministic answer for when native HTML is sufficient and which overrides are allowed.

  1. List each component’s preferred HTML element
  2. Record implicit role and naming mechanism
  3. List permitted ARIA deltas
  4. Document rejected role overrides
  5. Validate against ARIA in HTML
P0Component contracts

Require an ARIA semantic contract for every custom widget.

A visual component contract is incomplete without role, name, state, relationships, keyboard, and focus behavior.

  1. Define role and native fallback
  2. Define required name and description
  3. Define states and update events
  4. Define required context/owned elements
  5. Define keyboard and focus model
  6. Define prohibited attributes and patterns
P0Naming

Create an accessible-name and description contract.

Naming bugs are easy to introduce through aria-label overrides, hidden content, duplicate IDs, and inconsistent visible labels.

  1. Prefer native visible labeling
  2. Define name source and precedence
  3. Require visible-label inclusion
  4. Separate concise name from supporting description
  5. Inspect computed output
P0State governance

Adopt a semantic state taxonomy.

Current, selected, checked, pressed, expanded, disabled, invalid, and busy are distinct user concepts.

  1. Map each visual state to one semantic concept
  2. Restrict attributes to supporting roles
  3. Update DOM, visual, and ARIA state atomically
  4. Test transitions and initial state
  5. Lint invalid combinations
P0Keyboard

Gate composite widgets on a complete keyboard model.

ARIA roles do not provide the expected arrow-key, Home/End, typeahead, or escape behavior.

  1. Define page tab stop count
  2. Choose roving tabindex or aria-activedescendant
  3. Document arrow and activation keys
  4. Define disabled-item focus policy
  5. Define entry, exit, and restoration
  6. Test with zoom and screen readers
P0Structure

Define a landmark architecture and budget.

The visual page hierarchy needs an equivalent navigable semantic hierarchy without landmark noise.

  1. Map top-level layout to native landmarks
  2. Name repeated navigation, search, and complementary regions
  3. Use section regions only when important and named
  4. Keep ordinary cards out of the landmark list
  5. Test landmark navigation order

P1 · Core implementation14 recommendations

P1Mobile hierarchy

Make the first mobile viewport answer four questions.

The user needs orientation before exploration.

Implementation guidance
  • What is this
  • What scope or time period is active
  • What is the principal finding
  • What is the next useful action
P1Mobile navigation

Use one sticky app header and measured sticky section headers.

Prevents overlapping sticky layers when text wraps or browser settings change.

Implementation guidance
  • Measure header with ResizeObserver
  • Write height to --app-header-height
  • Use the variable for section header top offsets
  • Set scroll-padding and scroll-margin from the same contract
  • Honor safe-area insets
P1Information density

Use cards only for self-contained conceptual objects.

Lists and tables are more efficient for repeated scanning and exact comparison.

Implementation guidance
  • Cards for distinct stories and recommendations
  • Compact lists for headlines
  • Tables for repeated attributes
  • Small multiples for repeated trends
  • Detail views for one-entity depth
P1Metadata

Place supporting metadata in one predictable footer region.

Prevents dates, source, tags, and signal from competing with title and meaning.

Implementation guidance
  • Title first
  • Summary or finding second
  • Evidence or implication third
  • Metadata footer last
  • No passive date or source pills
P1Search

Provide modal search across findings, methods, components, and sources.

A long research system requires direct retrieval, not only navigation.

Implementation guidance
  • Keyboard shortcut and visible trigger
  • Search title, summary, tags, keys, and citation wording
  • Filter by content type and evidence class
  • Return anchors with context snippets
  • Keep search dismissible and keyboard operable
P1Scope

Keep active scope visible.

Users can misinterpret filtered data as the complete dataset.

Implementation guidance
  • Current section
  • Active filters
  • Result count
  • Sort order
  • Data completeness
  • Last refresh time when applicable
P1Interaction

Make filtering and editing reversible.

Undo and reset reduce risk and support exploration.

Implementation guidance
  • Visible selected state
  • Clear all
  • Undo destructive changes
  • Preserve prior view state
  • Preview transformations before apply
P1Icons

Use icon plus text for important or unfamiliar actions.

Labels reduce interpretation and learning demands.

Implementation guidance
  • Use conventional icons only for compact repeated utilities
  • Provide accessible names
  • Use currentColor
  • Keep glyph and target size separate
  • Do not depend on tooltip-only explanation
P1Color

Use a neutral-first semantic palette.

Preserves saturated color for meaningful state, action, selection, and analytical focus.

Implementation guidance
  • Neutral canvas and surfaces
  • Readable primary, secondary, and metadata text
  • Dedicated action colors
  • Dedicated semantic status roles
  • Separate accent and data palettes
P1Data visualization

Choose palette family from data semantics.

Color order and category meaning must correspond to the underlying relationship.

Implementation guidance
  • Sequential for low-to-high
  • Diverging around a meaningful midpoint
  • Qualitative for unordered categories
  • Cyclic for connected endpoints
  • Avoid rainbow scales
P1Data visualization

Prefer direct labels and shared scales.

Reduces legend lookup and makes comparison spatial rather than memorial.

Implementation guidance
  • Label lines at endpoints
  • Annotate important events
  • Keep small-multiple scales consistent
  • Show exact values on demand
  • Expose baselines and units
P1Responsive

Define semantic zoom levels.

Mobile should adapt representation without deleting evidence.

Implementation guidance
  • Overview: counts and major changes
  • Section: compact findings and comparisons
  • Item: summary, evidence, implication
  • Detail: method, sources, raw values
P1Preferences

Support light, dark, contrast, forced-color, motion, and transparency preferences.

Accessibility and environmental needs extend beyond one theme toggle.

Implementation guidance
  • Respect system defaults
  • Allow explicit override
  • Persist user choice
  • Validate each mode independently
  • Avoid mechanical inversion
P1Focus

Create a focus-ring token that works across all surfaces.

Focus must remain visible, unclipped, and distinct from selection.

Implementation guidance
  • Use inner and outer contrast where necessary
  • Test light, dark, brand, and semantic backgrounds
  • Avoid overflow clipping
  • Ensure sticky layers do not obscure focus
  • Test forced colors
P1Status communication

Extend the notification ladder with live-region semantics.

Visual surfaces and announcement behavior need one shared urgency model.

  1. Map toast to status by default
  2. Reserve alert for important time-sensitive content
  3. Use aria-busy during coherent updates
  4. Avoid simultaneous focus movement and duplicate live announcements
  5. Persist consequential failures outside transient regions
P1Hidden content

Create one hiding, inertness, and presentational-semantics policy.

display:none, hidden, inert, aria-hidden, and role none/presentation affect visibility, focus, and accessibility semantics differently.

  1. Document each mechanism’s visual and accessibility effects
  2. Prohibit aria-hidden on focusable subtrees
  3. Use inert for blocked background interaction where supported
  4. Use presentation only to remove misleading semantics
  5. Test focus after show/hide transitions
P1Relationships

Restrict aria-owns and document aria-controls semantics.

Accessibility-tree reparenting and weak control relationships are difficult to debug and easy to overstate.

  1. Prefer DOM containment
  2. Require an exception record for aria-owns
  3. Keep owned order aligned with reading and focus order
  4. Use aria-controls only for real controlled regions
  5. Inspect the resulting tree
P1Data components

Separate table, grid, and treegrid acceptance criteria.

These structures have radically different reading modes, focus density, implementation cost, and assistive-technology risk.

  1. Default to native table for static data
  2. Use grid for dense interactive cells only
  3. Use treegrid only for real hierarchical tabular interaction
  4. Define virtualization metadata
  5. Test edit, selection, sort, and row expansion separately
P1Tooltips and popups

Separate tooltip descriptions from interactive popovers.

A tooltip is noninteractive supporting text; a popover can contain controls and needs a different focus and dismissal contract.

  1. Use aria-describedby for tooltip association
  2. Open on both focus and hover
  3. Allow Escape dismissal
  4. Keep interactive content out of tooltip
  5. Use popover or dialog for actionable content
P1Testing

Add computed accessibility-tree snapshots to component review.

Source markup cannot prove what browsers expose as role, name, description, state, and hierarchy.

  1. Inspect the accessibility tree in supported browsers
  2. Record computed role/name/state
  3. Compare initial and changed states
  4. Capture landmark and composite hierarchy
  5. Review unexpected presentational descendants
P1Interoperability

Maintain a browser and assistive-technology support matrix.

ARIA support varies by role, attribute, pattern, implementation technique, browser, and assistive technology.

  1. Use ARIA-AT reports to prioritize risk
  2. Test supported desktop combinations
  3. Include mobile screen readers for touch surfaces
  4. Record must-have and should-have failures
  5. Avoid coding to temporary bugs when a robust pattern exists

P2 · Advanced capability4 recommendations

P2Data exploration

Add linked highlighting across related evidence.

Coordinated views turn disconnected components into an analytical system.

Implementation guidance
  • Highlight related findings and sources
  • Connect timeline events and metrics
  • Subdue unrelated context without removing it
  • Keep focus and selection semantics distinct
P2Density

Offer compact and comfortable density modes.

Different users and tasks require different amounts of visible context.

Implementation guidance
  • Compact for scanning and comparison
  • Comfortable for touch and explanation
  • Reading mode for long-form content
  • Do not change the information model between modes
P2Machine readability

Embed the same research data as structured JSON.

Future agents should not have to reconstruct concepts from styled DOM fragments.

Implementation guidance
  • Stable IDs and citation keys
  • Explicit relationships between findings and sources
  • Separate source type and claim language
  • Include version, generated date, and methodology
  • Provide JSON export from the SPA
P2Validation

Measure task success rather than engagement alone.

Clicks and time-on-page can reflect confusion rather than value.

Implementation guidance
  • Time to locate
  • Comparison accuracy
  • Comprehension of primary finding
  • Error and recovery rate
  • Keyboard and mobile completion
  • Decision confidence
P2Automation

Generate role, state, and keyboard documentation from structured contracts.

ARIA guidance drifts when code, visual examples, and documentation are edited independently.

  1. Store semantic contracts in JSON
  2. Generate reference tables and test cases
  3. Link components to normative and APG sources
  4. Export contracts into OKF concepts
  5. Validate derivative counts and IDs
P2Standards monitoring

Track ARIA 1.3, AccName 1.2, HTML-AAM, and Core-AAM status separately from current requirements.

Draft features and mappings change frequently and should not silently become product requirements.

  1. Tag every source by publication status
  2. Define current conformance baseline
  3. Record experimental properties separately
  4. Review drafts on scheduled cadence
  5. Promote only after support and policy review

P0 · Forms & surfaces foundation6 recommendations

P0Surface selection

Create an interaction-surface selection matrix.

Prevents component choice based on visual shape or implementation convenience.

Implementation guidance
  • Classify intent as information, navigation, selection, action, configuration, or confirmation
  • Record scope, anchoring, modality, interruption, persistence, focus, and risk
  • Select the least interruptive surface that satisfies the task
  • Document alternatives rejected and why
P0Forms

Define a canonical form blueprint.

Creates one reusable structure for labels, groups, constraints, errors, success, save state, and recovery.

Implementation guidance
  • Start with purpose and completion expectation
  • Use one primary visual column
  • Keep labels persistent
  • Group related controls programmatically and visually
  • State constraints before validation
  • Preserve input and link errors to fields
  • Confirm success and next state
P0Native HTML

Adopt a native-first component policy.

Native elements inherit form, keyboard, focus, platform, and accessibility behavior that custom widgets must reproduce.

Implementation guidance
  • Document the native primitive considered
  • Explain why it is insufficient
  • List inherited behaviors that must be recreated
  • Require no-JavaScript or failure fallback where feasible
  • Test assistive technology and browser combinations
P0Focus and dismissal

Create one focus and dismissal protocol.

Focus and close behavior should not vary unpredictably among dialogs, menus, popovers, drawers, and sheets.

Implementation guidance
  • Define trigger and entry target
  • Define containment and traversal
  • Define Escape and close-request behavior
  • Define outside-click policy
  • Define completion and cancellation
  • Restore focus to trigger or logical successor
  • Record data preservation for every path
P0Notifications

Create a notification escalation ladder.

Stops every update from becoming a toast or every warning from becoming a modal interruption.

Implementation guidance
  • Classify whether knowledge or action is needed now
  • Classify whether the condition persists
  • Use inline guidance and validation first
  • Use toast/status only for noncritical transient confirmation
  • Use banners for persistent conditions
  • Use dialogs only when action or interruption is justified
P0Menus

Separate navigation, selection, and command menus.

These tasks have different semantics and keyboard expectations despite sharing dropdown presentation.

Implementation guidance
  • Use nav and links for destinations
  • Use select, listbox, combobox, or radio groups for values
  • Use menu roles for application commands
  • Use disclosure for ordinary expandable navigation
  • Retain native link context behavior

P1 · Operational surface guidance6 recommendations

P1Responsive behavior

Define responsive surface transformations.

A compact viewport often changes the appropriate surface without changing the underlying task.

Implementation guidance
  • Map popover to sheet or full-screen task
  • Map persistent sidebar to drawer
  • Map inspector to collapsible panel
  • Preserve entered state and save semantics
  • Retest focus, dismissal, and back navigation
P1Settings

Add a settings information-architecture pattern.

Persistent configuration requires findability, dependencies, defaults, and repeated retrieval.

Implementation guidance
  • Create stable categories and visible current values
  • Index settings and synonyms for search
  • Support deep links to settings
  • Explain consequences and dependencies
  • Provide reset or restore defaults
  • Choose immediate apply versus explicit save deliberately
P1Context menus

Require visible redundancy for important context-menu commands.

Hidden secondary interactions cannot carry primary capability.

Implementation guidance
  • Provide commands in a toolbar, detail view, or visible overflow menu
  • Keep context menus short and relevant
  • Support keyboard invocation when applicable
  • Preserve ordinary browser context behavior
  • Place destructive commands last
P1Toasts

Create a toast queue and persistence policy.

Unbounded or transient notification streams create missed messages and interruption fatigue.

Implementation guidance
  • Deduplicate repeated messages
  • Limit simultaneous toasts
  • Avoid focus movement
  • Pause or avoid timeout when action is present
  • Persist consequential events in history
  • Provide an alternate recovery path
P1Browser support

Add a browser-support tier to each interactive component.

Emerging HTML features can create fragmented behavior if used as invisible assumptions.

Implementation guidance
  • Baseline: widely supported native behavior
  • Enhanced: feature-detected improvement
  • Experimental: opt-in evaluation only
  • Document fallback and semantic equivalence
  • Record tested browser and assistive-technology combinations
P1Custom controls

Gate form-associated custom elements.

Form participation APIs reduce some custom-control debt but do not guarantee usability or accessibility.

Implementation guidance
  • Verify label association
  • Verify submitted value and form owner
  • Verify reset, disabled, and validation lifecycle
  • Verify autofill expectations
  • Verify keyboard, touch, and screen reader behavior
  • Define unsupported-browser fallback

P2 · Validation and automation4 recommendations

P2Component laboratory

Build an interactive component laboratory.

Static guidance cannot expose focus, dismissal, responsive, forced-color, and error-recovery behavior.

Implementation guidance
  • Include live native-first examples
  • Show keyboard trace
  • Show responsive transformation
  • Expose component contract JSON
  • Record tested support and known gaps
  • Provide copyable minimum examples
P2Automation

Automate semantic and ARIA linting.

Many interaction failures are structurally detectable before manual review.

Implementation guidance
  • Detect missing labels and accessible names
  • Detect invalid menu role composition
  • Detect modal dialogs without titles
  • Detect color-only status and unlabeled errors
  • Detect broken aria-controls relationships
  • Require human review for behavior and task fit
P2Validation

Test keyboard, touch, forced colors, zoom, and screen readers for every surface family.

A surface can be correct in desktop pointer use while failing focus order, touch discovery, or adapted presentation.

Implementation guidance
  • Run keyboard-only completion
  • Test touch and long-press alternatives
  • Test 200% and 400% zoom
  • Test forced-colors and reduced motion
  • Test at least one screen reader per supported platform
  • Record support rather than assuming APG example compatibility
P2Knowledge system

Generate component documentation and examples from one behavioral contract.

The visual guide, LLM data, OKF concepts, tests, and code examples should not describe different behavior.

Implementation guidance
  • Use stable component IDs
  • Store native primitive and ARIA delta
  • Store focus and dismissal policy
  • Store responsive transforms and browser tier
  • Generate guide content, validation prompts, and example metadata from the same record

v1.5 · Executable laboratory · 10 recommendations

P0Fixture registry

Create a canonical executable-fixture registry.

Stable fixture records link component contracts, semantic baselines, expected keyboard behavior, automated rules, manual tests, references, and known limitations.

Implementation guidance
  • Define stable fixture IDs
  • Link component and responsive variant IDs
  • Store expected outcomes
  • Store automated and manual checks
  • Generate SPA and reports from the registry
P0Validation evidence

Separate automated, manual, AT, and user evidence.

A single pass/fail field conceals which layer was actually tested.

Implementation guidance
  • Classify every result by evidence mode
  • Record environment tuples
  • Preserve inconclusive outcomes
  • Require human review for semantic quality
  • Prevent automated passes from setting production certification
P0Browser capability

Add feature-detection and fallback metadata.

Browser-version assumptions are fragile and cannot represent embedded WebViews or enterprise support windows.

Implementation guidance
  • Define baseline, progressive, experimental tiers
  • Provide a detection expression
  • Document fallback behavior
  • Record verification date
  • Display current runtime capability separately
P0Release governance

Block certification on baseline fixture failures.

A research handbook should not describe a component as supported when its own required fixtures fail.

Implementation guidance
  • Identify baseline fixtures
  • Define blocking checks
  • Require no unresolved high-severity failure
  • Record approved exceptions
  • Publish certification status visibly
P1Interaction traces

Capture keyboard, focus, dismissal, and state traces.

Trace evidence makes lifecycle failures reproducible rather than anecdotal.

Implementation guidance
  • Log focusin and relevant keydown events
  • Record open and close reasons
  • Record state changes
  • Limit and redact sensitive values
  • Attach traces to the test report
P1Responsive variants

Create named fixture variants for mobile transformations.

The mobile equivalent may use a different modality and keyboard/focus contract.

Implementation guidance
  • Name each variant
  • Preserve user goal and save model
  • Test compact viewport and virtual keyboard
  • Compare dismissal consequences
  • Link equivalent variants
P1Support matrix

Store browser and assistive-technology results in the research model.

Support claims need versioned, inspectable evidence and known limitations.

Implementation guidance
  • Record OS, browser, AT, input, viewport
  • Record expected and observed results
  • Use pass, fail, partial, not-tested
  • Add evidence date and reviewer
  • Expose stale records
P1Ethical parity

Automate measurable choice-parity indicators.

Size, order, contrast, opacity, layer depth, and required interactions can identify review candidates.

Implementation guidance
  • Calculate comparable target area
  • Compare visual emphasis
  • Record default state
  • Count interaction steps
  • Require contextual autonomy review
P1Reports

Export a machine-readable validation report.

A report should be reusable in CI, governance, audits, and future-agent review.

Implementation guidance
  • Include fixture and component IDs
  • Include environment and capability results
  • Include every rule result
  • Include manual evidence and limitations
  • Version the report schema
P2Regression

Preserve fixture and accessibility-tree snapshots.

Versioned snapshots make semantic regressions visible during review.

Implementation guidance
  • Capture DOM and computed semantic expectations
  • Capture visual fixture images
  • Diff expected focus order
  • Store browser/AT evidence separately
  • Require reviewer approval for intentional change

Component block consistency

Shared anatomy and visual rules for ordered sequences and catalog indexes.

Ordered sequence

1
Step title

Optional explanation aligns independently from the number marker.

2
Next step

Every item in the same family uses identical anatomy.

Use for pipelines, workflows, blueprints, and escalation ladders.

Catalog index

01
Indexed reference record

Use when numbering supports retrieval but does not imply a workflow.

Use for principles, validation methods, and stable reference catalogs.

Component communication playbook

43 reusable component and semantic contracts.

Sticky application headerGlobal identity, search, mode controls, and section navigation.

Anatomy

  • Product title
  • Current document scope
  • Search trigger
  • Theme and density controls
  • Horizontally scrollable section navigation on mobile

Use

  • Keep height compact
  • Measure actual height
  • Use text labels for non-obvious controls
  • Maintain visible focus
  • Honor safe-area insets

Avoid

  • Multiple independent fixed headers
  • Large hero content inside sticky region
  • Icon containers for every control
  • Hiding search behind an unfamiliar icon

ARIA semantic contract

Native preferenceheader with nav and labelled controls
RoleImplicit banner at page scope; navigation landmarks for section links
NameVisible product identity; unique labels for repeated navigation landmarks and icon controls
Statesaria-current on the active section link when synchronized · aria-expanded on controls that reveal menus or panels
Relationshipsaria-controls only for actual controlled regions
KeyboardDocument tab order; horizontally scrollable navigation remains keyboard operable
Focusordinary document focus; sticky layout must not obscure focus
ProhibitedMultiple page-level banners · Unlabelled repeated navigation landmarks · Icon-only controls without names
Sticky section headerMaintain local context in long research pages.

Anatomy

  • Section number or category
  • Finding-oriented title
  • Concise section purpose
  • Optional count

Use

  • Use the global measured offset
  • Allow the next section to push the prior header away
  • Keep it shorter than the global header
  • Set matching scroll-margin

Avoid

  • Stacking several sticky subsection levels
  • Fixed pixel offsets
  • Repeating long descriptions in the sticky state

ARIA semantic contract

Native preferencesection with a real heading; sticky positioning is presentational
RoleImplicit region only when the section is named and important enough for landmark navigation
NameVisible heading via native structure or aria-labelledby
StatesNone
Relationshipsaria-labelledby to the section heading where a named region is appropriate
KeyboardNo custom keyboard model; anchor targets must account for sticky offsets
Focusdocument order; programmatic navigation may focus the heading with tabindex=-1 when needed
Prohibitedrole=region on every visual grouping · Heading levels chosen only for size
Research finding rowCommunicate one conclusion and its operational implication.

Anatomy

  • Finding title
  • Evidence summary
  • Why it matters
  • Citation keys

Use

  • Lead with the conclusion
  • Keep evidence and implication adjacent
  • Use reference keys as quiet verification links
  • Group by domain

Avoid

  • Generic category titles
  • Large status badges
  • Multiple card backgrounds inside the row

ARIA semantic contract

Native preferencearticle or section with heading, prose, and ordinary links
RoleNo custom widget role
NameFinding title is the structural heading and accessible identifier
StatesNone
RelationshipsCitation links remain ordinary links; supporting evidence may use labelled details/disclosures
KeyboardNative document and link navigation
Focusdocument order
ProhibitedClickable card semantics without a single clear action · region landmark for every finding
Content cardRepresent one self-contained story, recommendation, or conceptual object.

Anatomy

  • Linked title
  • Summary
  • Evidence or implication
  • Single metadata footer

Use

  • Use neutral surfaces
  • Make the title the main anchor
  • Keep metadata quiet
  • Use one local primary action

Avoid

  • Cards for repeated exact comparison
  • Category-colored backgrounds
  • Date, source, signal, and tag pills together
  • Large decorative icons

ARIA semantic contract

Native preferencearticle, section, li, or div selected by content relationship
RoleNo generic card role exists; interactive descendants retain native roles
NameUse a visible heading when the card is a self-contained object
Statesaria-selected only when hosted in a role that supports selection
RelationshipsNone
KeyboardDo not make the whole card a custom button when it contains nested controls
FocusOnly actual actions receive focus
Prohibitedrole=button on containers with multiple links or controls · tabindex=0 on passive cards · region landmark proliferation
Dense comparison tableSupport scanning and exact comparison across repeated attributes.

Anatomy

  • Descriptive caption
  • Aligned headers
  • Sortable columns
  • Row labels
  • Optional detail disclosure

Use

  • Align numbers
  • Use typography and separators before color
  • Make sort state explicit
  • Preserve labels when transformed for mobile

Avoid

  • Heatmap-only exact values
  • Saturated status rows
  • Low-contrast metadata
  • Silent column removal on mobile

ARIA semantic contract

Native preferencetable, caption, thead, tbody, th scope
RoleImplicit table structure; grid only when the whole structure is an interactive composite
Namecaption preferred; aria-labelledby when an external visible heading is the name
Statesaria-sort on currently sorted header only
RelationshipsHeaders through native scope/id relationships
KeyboardDocument reading and native focusable controls
Focusordinary tab sequence
Prohibitedrole=grid only to reduce tab stops or style cells
Status and alertCommunicate information, success, warning, or error with recovery.

Anatomy

  • Semantic icon
  • State name
  • Message
  • Optional action

Use

  • Use color, icon, and text
  • Explain recovery
  • Use role-specific foreground/background pairs
  • Reserve bold treatment for urgent states

Avoid

  • Colored dot only
  • White text on unchecked yellow
  • Using gray for both secondary and disabled
  • Warnings that visually overpower errors

ARIA semantic contract

Native preferencevisible text region with native focusable recovery actions
Rolestatus for polite advisory updates; alert for important time-sensitive updates; alertdialog only when a response is required
NameUsually announced from message contents; concise visible state label
Statesaria-live, aria-atomic, aria-relevant, and aria-busy only according to the update contract
RelationshipsField or section messages may be referenced with aria-describedby or aria-errormessage when appropriate
KeyboardStatus and alert do not move focus; actionable persistent messages expose normal controls
Focusnone unless the user must act, in which case use an appropriate focused surface
ProhibitedRoutine success as assertive alert · Color-only state · Critical failure only in an auto-dismiss message
Icon controlProvide compact recognition for a conventional action.

Anatomy

  • Button target
  • Monochrome SVG
  • Accessible name
  • Optional persistent label

Use

  • Use currentColor
  • Keep target larger than glyph
  • Use visible label for primary or unfamiliar action
  • Test every state and forced colors

Avoid

  • Multicolored utility icons
  • Tooltip-only meaning
  • Tiny click targets
  • Same glyph for conflicting concepts

ARIA semantic contract

Native preferencebutton or link with decorative svg aria-hidden when visible text names the action
RoleImplicit control role from button or link; standalone meaningful image uses img semantics
NameVisible label preferred; aria-label or aria-labelledby for justified icon-only controls
Statesaria-pressed for toggle buttons only · aria-expanded for disclosure controls only · aria-disabled only with blocked behavior
RelationshipsTooltip may supplement through aria-describedby but must not be the sole important label
KeyboardNative activation; target remains large enough without enlarging the glyph
Focusnative control focus
ProhibitedRole or name on decorative SVG duplicated by the parent · Accessible name describing the glyph instead of the action · Color-only state
Filter control and scope barNarrow information while preserving visible context.

Anatomy

  • Filter label
  • Selected state
  • Result count
  • Clear/reset action
  • Current sort and scope

Use

  • Use aria-pressed or native state
  • Use check or removal affordance in addition to color
  • Update count and status
  • Keep reset visible

Avoid

  • Passive tags styled as filters
  • Color-only selection
  • Hidden active filters
  • No path back to all results

ARIA semantic contract

Native preferenceform, fieldset, native buttons, checkboxes, radios, select, or search input
RoleNative form semantics; toolbar only for a coherent command group; listbox/combobox only when their full interaction model is implemented
NameVisible filter labels and a named filter region when useful
Statesaria-pressed for independent toggle filters · aria-checked for checkable options · aria-expanded for filter disclosures · aria-busy on the coherent results region during update
RelationshipsResult count/status associated through visible text and live status where needed
KeyboardNative controls; composite arrow navigation only when a documented composite pattern is chosen
FocusPreserve focus on the changed filter; do not reset to page start after results update
ProhibitedPills that look interactive but are passive · aria-selected on unsupported generic buttons · Silent scope changes
Analytical chartExpose a relationship, trend, distribution, or comparison.

Anatomy

  • Finding-oriented title
  • Units and scope
  • Appropriate encoding
  • Direct labels
  • Annotation
  • Source and method

Use

  • Use position and length for precise comparison
  • Match color family to data
  • Show baselines and uncertainty
  • Provide tabular alternative when needed

Avoid

  • 3D effects
  • Rainbow scales
  • Remote legends
  • Dual axes without compelling justification
  • Animation replacing comparison

ARIA semantic contract

Native preferencefigure and figcaption plus accessible text/table alternative matched to the analytical task
Roleimg only when the chart can be represented by one concise alternative; otherwise structured HTML and native controls
NameFinding-oriented visible caption; concise accessible name distinct from the full description
Statesaria-busy while a coherent chart update is incomplete · aria-pressed or aria-selected only on real controls/selection roles
Relationshipsaria-describedby may reference a concise summary, not an enormous flattened data dump
KeyboardAll interactive marks or controls require a documented navigation model; provide nonvisual data access
FocusPrefer controls outside the graphic; composite focus only for justified exploratory marks
ProhibitedHundreds of SVG nodes exposed without a usable model · Color-only series distinction · aria-label containing the entire dataset
Citation referenceLet readers verify a concept and reuse accurate attribution language.

Anatomy

  • Stable key
  • Source title and link
  • Evidence class
  • Use-for summary
  • Recommended citation language
  • Boundary or caveat

Use

  • Use the strongest accurate verb
  • Distinguish standard, study, review, framework, practice, and draft
  • Link claims to source keys

Avoid

  • Presenting framework as proof
  • Treating draft as current requirement
  • Quote aggregators when primary source exists

ARIA semantic contract

Native preferenceordinary link within prose or a reference list using semantic headings/lists
RoleImplicit link; details/summary for optional reference metadata
NameHuman-readable source title or stable citation key with enough context
Statesaria-current only when navigating a current reference view
RelationshipsBacklinks and cited-by relationships are visible links; aria-describedby only for concise supplementary metadata
KeyboardNative link and disclosure behavior
FocusNative; deep links land on a visible named target
ProhibitedRaw URL as the only understandable label · Tooltip-only citation metadata · Custom link role on noninteractive text
Sponsored content blockDisclose commercial content while providing enough information for an informed evaluation.

Anatomy

  • Clear sponsorship label
  • Product or service name
  • Problem addressed
  • Material differentiation
  • Verification caveat
  • Destination link

Use

  • Keep disclosure visible
  • Use equivalent readability
  • Separate claims from editorial assessment
  • State what should be independently verified

Avoid

  • Native-looking undisclosed promotion
  • Urgency theater
  • Oversized visual prominence
  • Editorial endorsement implied by styling

ARIA semantic contract

Native preferencearticle, section, or aside with explicit visible sponsorship disclosure
RoleNo special ARIA sponsor role; complementary only when the block is truly secondary to main content
NameVisible sponsor and offer heading; disclosure included in text, not only an accessible label
StatesNone
RelationshipsSource and sponsor links remain ordinary links
KeyboardNative links and controls
FocusDocument order
ProhibitedDisclosure hidden only from visual users or only from assistive technology · Banner or alert role used to force attention · Sponsored card indistinguishable from editorial content
FormCollect related input and commit a user-controlled transaction.

Anatomy

  • Purpose and completion expectation
  • Persistent labels and instructions
  • Logical field groups
  • Validation summary and inline messages
  • Primary submit and secondary cancellation
  • Success or next-state confirmation

Use

  • Ask only for necessary information
  • Use one visual column by default
  • Preserve input through errors
  • State save semantics and consequences
  • Use native submission and validation relationships

Avoid

  • Placeholder-only labels
  • Clearing fields on error
  • Unexplained required data
  • Multiple equal primary actions
  • Timeouts without extension
Native baseline
form
Task
input
Modality
nonmodal
Interruption
low
Persistence
until-completed-or-abandoned
Focus
entry: document-order · contain: False · restore: next-logical-task
Dismissal
explicit: False · Escape: False · light dismiss: False · timeout: False
Responsive transforms
multi-step-form · full-screen-form
Support tier
baseline

ARIA semantic contract

Native preferenceform with labels, fieldset, legend, native controls
Roleimplicit form landmark only when named; do not add role=form to every form
NameVisible heading via aria-labelledby when the form needs landmark navigation
Statesaria-busy while submitting if form remains perceivable
Relationshipsaria-describedby for form-wide instructions sparingly
KeyboardNative document and form-control order
Focusnative; focus error summary after failed submit when appropriate
ProhibitedUnnamed duplicate form landmarks
Form fieldCollect one understandable value with persistent identity and constraints.

Anatomy

  • Visible label
  • Native control
  • Optional hint or format
  • Required/optional state
  • Units or range
  • Inline error and success only when useful

Use

  • Associate label explicitly
  • Place guidance adjacent and programmatically described
  • Accept forgiving formats
  • Use appropriate autocomplete and input type
  • Keep valid secondary text readable

Avoid

  • Placeholder as label
  • Color-only invalid state
  • Formatting rules revealed after submission
  • Decorative icon inside every field
  • Disabled state as unexplained gray
Native baseline
input | textarea | select
Task
input
Modality
nonmodal
Interruption
low
Persistence
persistent
Focus
entry: control · contain: False · restore: natural-tab-order
Dismissal
explicit: False · Escape: False · light dismiss: False · timeout: False
Responsive transforms
same-semantic-control
Support tier
baseline

ARIA semantic contract

Native preferencelabel plus native input/select/textarea
Roleimplicit native role
NameNative label preferred; visible label included in name
Statesaria-invalid after validation failure · aria-disabled only when native disabled is unsuitable · aria-required only when native required is unsuitable
Relationshipsaria-describedby for help and error text · aria-errormessage only with tested support and valid invalid state
KeyboardNative control behavior
Focusnative
Prohibitedaria-label overriding visible label · aria-hidden help referenced as description without testing
Field groupBind controls that share one question, constraint, or conceptual scope.

Anatomy

  • Fieldset or semantic grouping
  • Concise legend or heading
  • Related controls
  • Shared instructions
  • Group-level validation when needed

Use

  • Use fieldset and legend for related radios and checkboxes
  • Align visual and programmatic boundaries
  • Keep individual labels independently meaningful
  • Use optgroup for grouped options

Avoid

  • A border with no semantic grouping
  • Long repeated legends
  • Separate cards for every radio option
  • Grouping by color alone
Native baseline
fieldset + legend | optgroup
Task
input-group
Modality
nonmodal
Interruption
low
Persistence
persistent
Focus
entry: first-control · contain: False · restore: natural-tab-order
Dismissal
explicit: False · Escape: False · light dismiss: False · timeout: False
Responsive transforms
stacked-controls
Support tier
baseline

ARIA semantic contract

Native preferencefieldset and legend; native radio/checkbox group
Roleimplicit group; radiogroup only for custom radio implementation
NameLegend or visible group heading
Statesaria-required/invalid only at the level users need announced
Relationshipsaria-describedby for group instructions or group-level error
KeyboardNative checkbox/radio behavior unless custom composite
Focusnative
ProhibitedGeneric div with visual heading but no programmatic group
Validation summaryExplain submission failure and route users to each affected field.

Anatomy

  • Outcome heading
  • Error count
  • Linked list of field errors
  • Same language as inline errors
  • Retry guidance

Use

  • Place after submission near the form heading
  • Move or announce focus deliberately
  • Preserve all valid input
  • Link each entry to its field
  • Explain correction rather than error code

Avoid

  • Generic “something went wrong”
  • Red border only
  • Toast-only validation
  • Clearing the form
  • Different wording between summary and field
Native baseline
section + links + aria-live where appropriate
Task
error-recovery
Modality
nonmodal
Interruption
medium
Persistence
until-resolved
Focus
entry: summary-heading-or-first-error · contain: False · restore: affected-control
Dismissal
explicit: False · Escape: False · light dismiss: False · timeout: False
Responsive transforms
sticky-inline-summary
Support tier
baseline

ARIA semantic contract

Native preferenceheading, list of links, and ordinary region; live semantics only when injected
Rolealert for newly injected urgent summary or focused region for submit result, not both by default
NameDescriptive heading such as “There are 3 problems”
Statesaria-busy false before announcing final result
RelationshipsLinks target invalid controls
KeyboardFocus summary after submit when it is the fastest recovery path
Focusprogrammatic focus with tabindex=-1 where appropriate
ProhibitedRepeated assertive announcements · Focus movement for every inline validation event
Select and comboboxChoose one or more values from a known or searchable set.

Anatomy

  • Persistent label
  • Current value
  • Option list
  • Search or filtering only when needed
  • Clear and selected state
  • No-results and loading state

Use

  • Use native select for straightforward choice sets
  • Use radio groups when comparison matters and choices fit
  • Use combobox for search or large dynamic sets
  • Expose selected state without color alone

Avoid

  • Dropdown solely to save space
  • Application menu for selecting a value
  • Custom keyboard behavior without testing
  • Hidden selected values
  • Unlabeled clear icon
Native baseline
select | input + listbox pattern
Task
selection
Modality
nonmodal
Interruption
low
Persistence
until-selection
Focus
entry: control-or-first-option · contain: False · restore: control
Dismissal
explicit: True · Escape: True · light dismiss: True · timeout: False
Responsive transforms
full-width-listbox · sheet-selector
Support tier
baseline

ARIA semantic contract

Native preferenceselect, input+datalist, or native input before custom combobox
Rolecombobox on focusable input/button; popup listbox/grid/tree/dialog according to content
NameVisible label on combobox
Statesaria-expanded · aria-autocomplete where applicable · aria-activedescendant for virtual focus when used
Relationshipsaria-controls points to popup · aria-haspopup only when popup is not listbox default or when useful
KeyboardAPG combobox model matched to editable/select-only and popup type
FocusDOM focus remains on combobox when using aria-activedescendant
Prohibitedrole=menu for ordinary option selection · Two simultaneous focus indicators
Disclosure and accordionReveal optional related content without changing task context.

Anatomy

  • Summary button
  • Expanded/collapsed state
  • One controlled content region
  • Optional concise preview

Use

  • Prefer details/summary when behavior fits
  • Use meaningful summary labels
  • Permit multiple open sections when comparison is useful
  • Keep primary findings visible

Avoid

  • Using disclosure as tabs
  • Using details as an action menu
  • Hiding current errors
  • Mutually exclusive accordion without task justification
Native baseline
details + summary
Task
information
Modality
nonmodal
Interruption
low
Persistence
user-controlled
Focus
entry: summary · contain: False · restore: summary
Dismissal
explicit: True · Escape: False · light dismiss: False · timeout: False
Responsive transforms
same-disclosure
Support tier
baseline

ARIA semantic contract

Native preferencedetails/summary or button
Roleimplicit button; no disclosure role exists
NameButton/summary text names the disclosed content
Statesaria-expanded on custom disclosure button
Relationshipsaria-controls optional and truthful
KeyboardNative button activation
Focusfocus remains on trigger unless task requires movement
ProhibitedUsing menu, tab, or tree role for simple disclosure
TabsSwitch among peer views that share one local region and remain mutually exclusive.

Anatomy

  • Tab list
  • Tab controls
  • Active state
  • Associated tab panels
  • Optional overflow handling

Use

  • Use only for peer categories
  • Keep labels short and predictive
  • Preserve active tab in deep link when valuable
  • Use responsive overflow without hiding active state

Avoid

  • Tabs for sequential steps
  • Tabs for unrelated pages
  • More tabs than can be understood
  • Color-only active state
  • Nested tab systems
Native baseline
buttons + tab pattern
Task
local-navigation
Modality
nonmodal
Interruption
low
Persistence
until-changed
Focus
entry: active-tab · contain: False · restore: active-tab
Dismissal
explicit: False · Escape: False · light dismiss: False · timeout: False
Responsive transforms
horizontal-scroll-tabs · select-navigation · stacked-sections
Support tier
baseline

ARIA semantic contract

Native preferencebuttons with authored tab semantics; no complete native tabs primitive
Roletablist > tab; associated tabpanel
Nametablist labelled when necessary; tab names from visible text; panels labelled by tabs
Statesaria-selected exactly one in single-select set · aria-orientation when vertical · tabindex 0 only on active/roving tab
Relationshipsaria-controls from tab to panel · aria-labelledby from panel to tab
KeyboardArrow navigation; Home/End optional; automatic or manual activation chosen by latency
Focusroving tabindex
ProhibitedUsing tabs for sequential navigation · Changing focus and loading slow panels automatically
Action menuPresent a short group of commands affecting the current object or selection.

Anatomy

  • Menu button
  • Predictive label or icon plus label
  • Menu items
  • Selected/checked state when applicable
  • Separated destructive group

Use

  • Use menu roles only for application-style commands
  • Move focus into the menu
  • Support arrow keys and typeahead when implemented
  • Close after action unless the command requires continued menu state

Avoid

  • Using menu role for normal site links
  • Long lists of configuration options
  • Nested submenus beyond one level
  • Unfamiliar icon-only trigger
  • Menu as the only place for primary action
Native baseline
button + menu pattern
Task
action
Modality
nonmodal
Interruption
low
Persistence
until-action-or-dismissal
Focus
entry: first-or-last-menuitem · contain: True · restore: menu-button
Dismissal
explicit: True · Escape: True · light dismiss: True · timeout: False
Responsive transforms
overflow-menu · action-sheet
Support tier
baseline

ARIA semantic contract

Native preferencebutton plus popup with authored menu semantics only for commands
Rolemenu button + menu > menuitem/menuitemcheckbox/menuitemradio
NameButton and menu have concise names; each item names an action
Statesaria-expanded on trigger · aria-haspopup=menu · aria-checked for checkable menu items
Relationshipsaria-controls optional for popup
KeyboardMenu/menubar arrow, Home/End, typeahead, Enter/Space, Escape model
Focusfocus moves into menu; roving tabindex or aria-activedescendant
ProhibitedUsing menu roles for site navigation or ordinary link lists
Context menuAccelerate a small set of commands specific to an object or selected content.

Anatomy

  • Invocation target
  • Context-aware commands
  • Optional concise title for multi-selection
  • Destructive action at end
  • Visible alternative command path

Use

  • Keep commands relevant and short
  • Support platform invocation modes
  • Make important commands visible elsewhere
  • Preserve standard browser context behavior where applicable

Avoid

  • Only path to important action
  • Rare advanced command dump
  • Multiple submenu levels
  • Replacing browser link/image context menus without need
  • Keyboard shortcuts displayed redundantly
Native baseline
platform/browser context behavior or custom menu
Task
action-accelerator
Modality
nonmodal
Interruption
low
Persistence
until-action-or-dismissal
Focus
entry: first-relevant-command · contain: True · restore: invocation-target
Dismissal
explicit: True · Escape: True · light dismiss: True · timeout: False
Responsive transforms
long-press-context-menu · visible-overflow-menu
Support tier
baseline

ARIA semantic contract

Native preferencevisible action path plus optional custom menu
Rolemenu and menuitem roles if custom context commands are implemented
NameContext-specific menu label when helpful; items name actions
Statesaria-disabled for discoverable unavailable commands only with blocked behavior
RelationshipsNone
KeyboardContext Menu key or Shift+F10; standard menu keyboard; Escape restores trigger/context
Focusfocus enters menu and returns to invocation context
ProhibitedOnly path to important functionality · Suppressing browser menu for ordinary content without need
PopoverExpose a small amount of contextual information or a few related nonblocking actions.

Anatomy

  • Trigger
  • Anchored top-layer surface
  • Short content or related actions
  • Optional arrow or spatial relationship
  • Explicit close only when needed

Use

  • Use native popover modes
  • Keep content near trigger in DOM order
  • Keep task small
  • Use auto/hint for light-dismiss content
  • Transform to sheet or full-screen task on compact layouts

Avoid

  • Warnings
  • Long forms
  • Popover cascades
  • Unsaved editable work with silent light dismiss
  • Multiple unrelated tasks
Native baseline
popover
Task
contextual-information-or-action
Modality
nonmodal
Interruption
low
Persistence
transient
Focus
entry: autofocus-only-when-task-needs-it · contain: False · restore: trigger-when-focus-was-inside
Dismissal
explicit: conditional · Escape: True · light dismiss: True · timeout: False
Responsive transforms
sheet · full-screen-contextual-task
Support tier
baseline

ARIA semantic contract

Native preferencepopover attribute for presentation plus semantic element matching content
RoleNo role is implied by popover; content may be dialog, menu, listbox, tooltip-like description, or ordinary region
NameName required only by the selected semantic role
Statesaria-expanded on trigger when state needs exposure · aria-haspopup value matches popup type where applicable
Relationshipspopover target relationship; aria-controls only when useful
KeyboardDetermined by contained semantic pattern, not by popover itself
FocusDetermined by task; light-dismiss informational surfaces often retain trigger focus
ProhibitedAssuming popover automatically supplies menu/dialog semantics
Dialog and alert dialogBlock background interaction for a scoped task or critical response-required decision.

Anatomy

  • Descriptive title
  • Scoped content
  • Primary and secondary actions
  • Explicit close or cancel
  • Optional warning and consequence
  • Backdrop and inert background

Use

  • Use native dialog
  • Move focus to a logical location
  • Contain focus while modal
  • Restore focus after close
  • Use alertdialog only for brief critical response-required messages
  • Preserve or warn about unsaved work

Avoid

  • Routine information
  • Nested modal dialogs
  • Generic title such as Error
  • Outside click destroying work
  • No visible close path
  • Long page-like content
Native baseline
dialog
Task
scoped-task-or-confirmation
Modality
modal
Interruption
high
Persistence
until-dismissed
Focus
entry: first-logical-control-or-static-heading · contain: True · restore: trigger-or-logical-successor
Dismissal
explicit: True · Escape: True · light dismiss: False · timeout: False
Responsive transforms
full-screen-dialog · sheet
Support tier
baseline

ARIA semantic contract

Native preferencedialog element with showModal for modal tasks
Roleimplicit dialog; alertdialog only for critical response-required interruption
NameVisible title via aria-labelledby preferred
Statesaria-modal=true only when background is actually inert and focus is contained
Relationshipsaria-describedby only for concise flat description; avoid flattening complex content
KeyboardTab/Shift+Tab contained; Escape according to loss risk; explicit close
Focusmove inside, contain while modal, restore to trigger/logical successor
Prohibitedaria-modal on a visually nonmodal surface · Nested modal dialogs
Drawer, sheet, and panelPresent navigation, supporting inspection, or a scoped task in a space-adaptive panel.

Anatomy

  • Purpose-specific heading
  • Semantic region or dialog
  • Close control when transient
  • Parent context indicator
  • Resize or detent behavior when applicable

Use

  • Choose nav/aside/section/dialog semantics from behavior
  • Avoid trapping focus in nonmodal panels
  • Use modal focus rules for blocking sheets
  • Preserve context and entered state across transformations

Avoid

  • Treating drawer as a semantic role
  • Sliding navigation with dialog semantics
  • Background interaction during modal sheet
  • Full-screen drawer with no location context
  • Gesture-only dismissal
Native baseline
nav | aside | section | dialog
Task
navigation-inspection-or-scoped-task
Modality
conditional
Interruption
medium
Persistence
transient-or-persistent
Focus
entry: purpose-dependent · contain: only-when-modal · restore: trigger-or-current-context
Dismissal
explicit: True · Escape: True · light dismiss: conditional · timeout: False
Responsive transforms
persistent-sidebar · modal-drawer · bottom-sheet · full-screen-task
Support tier
baseline

ARIA semantic contract

Native preferencenav, aside, section, or dialog based on behavior
RolePresentation shape does not determine role
NameLabel named navigation, complementary regions, and dialogs
Statesaria-expanded on trigger for collapsible drawer
Relationshipsaria-controls optional for controlled panel
KeyboardNonmodal drawer stays in document order; modal sheet follows dialog model
Focusnone for persistent panel; dialog contract for modal sheet
Prohibitedrole=dialog on every side panel · Focus trap in nonmodal inspector
Toast, status, banner, and notification centerCommunicate system change at an interruption level proportional to urgency and persistence.

Anatomy

  • State label or icon plus text
  • Concise outcome
  • Optional recovery action
  • Persistence appropriate to consequence
  • Durable history when needed

Use

  • Use status/toast for noncritical confirmation
  • Use banners for persistent conditions
  • Keep focus where the user is working
  • Deduplicate and queue messages
  • Provide durable recovery for consequential events

Avoid

  • Critical failure only in toast
  • Automatic disappearance of required action
  • Unlimited stacks
  • Focus movement for routine status
  • Color-only severity
  • Toast containing complex form
Native baseline
output | role=status | role=alert | persistent region
Task
feedback
Modality
nonmodal
Interruption
low-to-high
Persistence
consequence-matched
Focus
entry: none-unless-dialog · contain: False · restore: unchanged
Dismissal
explicit: conditional · Escape: False · light dismiss: False · timeout: only-noncritical
Responsive transforms
inline-message · toast · banner · notification-center · alert-dialog
Support tier
baseline

ARIA semantic contract

Native preferenceordinary visible region plus status semantics selected by urgency
Rolestatus for polite advisory updates; alert for important time-sensitive updates; log for ordered history
NameUsually announced from contents; avoid redundant labelled prefixes
Statesaria-live/atomic/relevant only when default role semantics are insufficient · aria-busy for grouped updates
RelationshipsNone
KeyboardNo focus movement for status/alert; actions require persistent reachable controls
Focusnone
ProhibitedCritical error only in auto-dismiss toast · role=alert for routine success on every action
Settings pageExpose persistent configuration through stable, searchable, understandable state navigation.

Anatomy

  • Settings search
  • Stable category navigation
  • Current values
  • Description and consequence
  • Dependencies and permission state
  • Reset or defaults
  • Immediate or explicit save status

Use

  • Use meaningful defaults
  • Support deep links
  • Index synonyms and affected features
  • Explain dependencies and conflicts
  • Show whether changes apply immediately
  • Restore recent pane when useful

Avoid

  • Modal settings mega-form
  • Internal flags at equal priority
  • Hidden dependencies
  • Ambiguous save behavior
  • Settings used to repair broken defaults
  • No search in large settings systems
Native baseline
main + nav + form sections
Task
persistent-configuration
Modality
nonmodal
Interruption
low
Persistence
persistent
Focus
entry: page-heading-or-search · contain: False · restore: route-history-or-invoking-feature
Dismissal
explicit: False · Escape: False · light dismiss: False · timeout: False
Responsive transforms
split-view-settings · stacked-settings-navigation · search-first-settings
Support tier
baseline

ARIA semantic contract

Native preferenceheadings, nav, search, forms, fieldsets, native controls
RoleNative landmarks and form semantics; switch only for immediate binary state
NameVisible category and setting labels
Statesaria-current for current settings route · aria-checked for custom switch only · aria-busy during coherent save/reload
Relationshipsdescriptions for consequences and dependencies
KeyboardDocument navigation plus native controls; avoid application role
Focusnative; deep link moves focus/scroll to named setting
ProhibitedARIA application role around settings page · Every settings card as region landmark
Attribution and provenance disclosureExpose credit, ownership, AI assistance, and review status without overwhelming the content hierarchy.

Anatomy

  • Source creator and publisher
  • Research owner and accountable editor
  • Software-agent contributor and bounded roles
  • Review status and contribution activity
  • Canonical source and generated distributions

Use

  • Keep the concise ownership strip visible near the artifact identity
  • Place detailed source attribution inside expandable reference records
  • Use specific contribution verbs such as researched, synthesized, drafted, implemented, and validated
  • Preserve source authors independently

Avoid

  • Generic “AI-generated” labels without human ownership
  • Calling AI the accountable author
  • Replacing a paper author with the synthesis owner
  • Hiding review status
  • Mixing publisher, host, and creator

ARIA semantic contract

Native preferencesection with heading plus dl, list, or table for creator, publisher, owner, and contribution roles
RoleNamed region only when attribution is a major navigable section
NameVisible attribution/provenance heading
StatesNone
RelationshipsSource entities and contribution records linked through ordinary anchors; machine graph remains supplemental
KeyboardNative document navigation
FocusDocument order
ProhibitedAI attribution replacing source authorship · Hidden ownership details · Every metadata row exposed as a landmark
Typed knowledge objectGive each reusable research concept a stable human-readable and machine-readable identity.

Anatomy

  • Stable ID and concept type
  • Title and concise description
  • Status, owner, and timestamp
  • Body structured for the task
  • Links to related concepts
  • Citations and provenance extensions

Use

  • Keep one bounded concept per file
  • Use descriptive self-explanatory types
  • Generate deep links and backlinks
  • Preserve unknown producer fields
  • Compile the same IDs into JSON and JSON-LD

Avoid

  • One monolithic Markdown file as the only source
  • Unstable generated IDs
  • Hidden relationships encoded only in prose
  • Rejecting unknown concept types
  • Treating the SPA DOM as the database

ARIA semantic contract

Native preferencearticle or section with heading, typed metadata, relationships, and stable anchor
RoleNo generic knowledge-object role; use native structure and links
NameVisible concept title; type remains supplementary metadata
Statesaria-current when the object is the current graph/navigation target
RelationshipsOutgoing links and backlinks are ordinary links; disclosure for optional machine metadata
KeyboardNative document and link navigation
FocusDeep link may focus the concept heading without adding it to normal tab order
ProhibitedCustom application role for a document explorer · ARIA relationships replacing visible navigable links · Region landmark for every atomic concept
ARIA semantic contractDocument the role, name, description, states, relationships, keyboard model, focus strategy, and prohibited combinations for a custom component.

Anatomy

  • Native semantic baseline
  • Role and required context
  • Name and description source
  • States and properties
  • Relationships
  • Keyboard model
  • Focus strategy
  • Accessibility-tree expectation
  • Support evidence

Use

  • Begin with native HTML
  • Use the smallest correct ARIA delta
  • Treat states as synchronized data
  • Link to normative sources and tested APG pattern
  • Document fallback and support matrix

Avoid

  • Role selected from visual resemblance
  • ARIA without keyboard behavior
  • Redundant native roles
  • Unsupported global attributes
  • Undocumented accessibility-tree reparenting

ARIA contract

Native preferencesemantic HTML before ARIA
RoleComponent-specific
NameRequired according to role and task
KeyboardComponent-specific complete model
FocusDocumented and tested
Landmark architectureExpose the high-level visual layout as a concise, navigable page structure.

Anatomy

  • Banner
  • Primary and secondary navigation
  • Search
  • Main
  • Complementary regions
  • Named form regions
  • Contentinfo
  • Skip links

Use

  • Use native header/nav/search/main/aside/footer
  • Label repeated landmarks uniquely
  • Use heading-based labels
  • Keep all meaningful content within logical regions

Avoid

  • Region around every card
  • Duplicate unlabeled navigation landmarks
  • Role name repeated in label
  • Landmarks inside modal content without value

ARIA contract

Native preferenceheader, nav, search, main, aside, form, section, footer
RoleImplicit landmarks; region only when named
NameUnique labels for repeated landmark types
KeyboardAssistive-technology landmark navigation; skip links for keyboard users
Focusdocument
Live region and status messageAnnounce dynamic outcomes without unnecessarily moving focus or interrupting work.

Anatomy

  • Message content
  • Urgency
  • Live role or aria-live
  • Atomicity
  • Relevant changes
  • Busy state
  • Persistent recovery path

Use

  • Use status for polite advisory updates
  • Reserve alert for important time-sensitive updates
  • Inject or update content after the live region exists as required by tested behavior
  • Persist consequential failures
  • Deduplicate announcements

Avoid

  • Focus plus live announcement for the same routine event
  • Routine success as assertive alert
  • Auto-dismiss critical error
  • Multiple nested live regions
  • Announcing every keystroke result

ARIA contract

Native preferencevisible message region
Rolestatus, alert, log, timer, or custom aria-live based on urgency
NameUsually from content; optional label only when it improves context
KeyboardNo focus movement unless user action is required
Focusnone
TooltipProvide a short, noninteractive description for an already operable element.

Anatomy

  • Trigger
  • Brief description
  • Tooltip surface
  • aria-describedby relationship
  • Hover and focus opening
  • Escape dismissal

Use

  • Keep text concise
  • Open for keyboard focus and pointer hover
  • Keep visible while pointer moves over tooltip
  • Use persistent labels for important or unfamiliar actions
  • Respect reduced motion

Avoid

  • Buttons or links inside tooltip
  • Tooltip as the only label
  • Critical instruction available only on hover
  • Long paragraphs
  • Auto-moving focus

ARIA contract

Native preferencevisible label first; tooltip for supplementary description
Roletooltip
NameTooltip contents form the description of trigger
KeyboardFocus opens; Escape closes; focus stays on trigger
Focustrigger
ToolbarGroup three or more closely related controls into one labelled composite and reduce repetitive tab stops.

Anatomy

  • Label
  • Orientation
  • Controls
  • Roving focus
  • Disabled-item policy
  • Shortcut back to context

Use

  • Use for a coherent command group
  • Keep one toolbar item in page tab sequence
  • Use arrow keys according to orientation
  • Remember last focused item when useful
  • Avoid controls that consume navigation arrows

Avoid

  • Toolbar for decorative grouping
  • Two unrelated buttons in a toolbar
  • Nested arrow-key conflicts
  • No visible focus
  • Undocumented disabled focus behavior

ARIA contract

Native preferenceordinary grouped controls unless tab-stop reduction is valuable
Roletoolbar
NameVisible label or aria-label
KeyboardOne tab stop; arrow movement; Home/End optional
Focusroving tabindex
Interactive data gridSupport spreadsheet-like navigation and editing for dense interactive tabular data.

Anatomy

  • Grid label and description
  • Rows and cells
  • Headers
  • Selection
  • Sort
  • Editing mode
  • Virtualization metadata
  • Keyboard help

Use

  • Use only for truly interactive cell navigation
  • Keep one cell in page tab sequence
  • Expose total and visible row/column positions for virtualization
  • Separate navigation and edit modes
  • Provide non-grid alternative when feasible

Avoid

  • Grid role on static table
  • Every cell separately tabbable inside grid
  • Missing headers
  • Virtualized position not exposed
  • Unannounced mode changes

ARIA contract

Native preferencenative table unless composite interaction is necessary
Rolegrid > row > gridcell/rowheader/columnheader
NameCaption-like label plus optional description
KeyboardArrow, Home/End, Page movement, edit mode, selection model
Focusroving tabindex or aria-activedescendant
Tree and treegridNavigate and optionally select or edit a compact hierarchy using a desktop-style composite model.

Anatomy

  • Tree label
  • Treeitems or rows
  • Level
  • Position in set
  • Expanded state
  • Selection state
  • Typeahead
  • Context actions

Use

  • Use only when hierarchical compression and keyboard efficiency matter
  • Expose expanded state and hierarchy
  • Define focus versus selection
  • Support typeahead for larger trees
  • Provide visible action alternatives

Avoid

  • Tree semantics for ordinary nested links
  • Treegrid without complete grid behavior
  • Invisible hierarchy levels
  • Selection tied unpredictably to focus
  • Context menu as only action path

ARIA contract

Native preferencenested disclosure/list navigation unless application-style tree is justified
Roletree/treeitem or treegrid/row/cell
NameLabel the composite; item names from visible content
KeyboardArrow navigation, Home/End, typeahead, expansion, selection
Focusroving tabindex or aria-activedescendant
Composite focus managerDefine and test one internal focus model for widgets with many related interactive descendants.

Anatomy

  • Entry target
  • One page tab stop
  • Roving tabindex or aria-activedescendant
  • Directional navigation
  • Activation
  • Disabled-item policy
  • Exit path
  • Focus memory

Use

  • Choose one strategy per composite
  • Maintain one active item
  • Keep visual and programmatic focus aligned
  • Preserve native scrolling keys where possible
  • Document orientation and wrap behavior

Avoid

  • Multiple tabindex=0 items
  • DOM focus and active descendant disagree
  • Focus disappears after filtering
  • Arrow keys captured unnecessarily
  • No escape or exit path

ARIA contract

Native preferencenative controls before custom composite
RolePattern-specific composite role
NameComposite labelled; active item individually named
KeyboardPattern-specific directional model
Focusroving tabindex or aria-activedescendant

Forms and interactive surfaces

Native-first behavior, focus, interruption, dismissal, responsive transformation, and settings architecture.

Forms, menus, popovers, dialogs, drawers, toasts, and settings share one lifecycle. Select the surface by task and behavioral cost—not by whether the desired shape is a floating card or sliding panel.

Governing rule

Use the least interruptive native or semantically equivalent surface that preserves discoverability, context, focus, state, and recovery.

Shared interaction lifecycle

1
Trigger
2
Reveal
3
Orient
4
Move or retain focus
5
Collect input or action
6
Validate and communicate
7
Dismiss or persist
8
Restore context

Form blueprint

1

Purpose and scope

Explain the transaction, completion expectation, privacy implications, and only the data required.

2

Persistent identity

Give every field a visible label. Add examples, units, formats, and required state without replacing the label.

3

Semantic groups

Use fieldset/legend, headings, optgroup, and spacing so relationships exist both visually and programmatically.

4

Constraint and validation

State constraints before errors. Parse forgivingly, validate client and server, and distinguish advice from blocking failure.

5

Recovery

Preserve valid work, present an error summary, link to fields, use matching corrective language, and expose retry.

6

Commit and confirmation

Make save semantics explicit, prevent duplicate operations, confirm completion, and explain the next state.

Interaction-surface selection matrix

SurfacePrimary intentFocusDismissalPersistenceUse whenAvoid when
InlineInput or persistent informationDocument flowNot applicablePersistentUsers need comparison or repeated accessThe content is genuinely secondary
DisclosureOptional related contentStays on triggerExplicit toggleUser-controlledSummary remains useful when collapsedPrimary evidence or errors are hidden
Action menuCommandsMoves into menuAction, Escape, outsideTransientShort command set affects current contextOrdinary navigation or value selection
Context menuExpert acceleratorMoves into menuAction, Escape, outsideTransientCommands are relevant to selected objectIt is the only path to capability
PopoverContextual info or a few actionsConditionalMode-dependent light dismissTransientTask is small and anchoredWarning, long form, or unsaved draft
Drawer / panelNavigation or inspectionDepends on modalityExplicit, Escape, conditional outsideTransient or persistentParent context should remain visibleSemantics are chosen from animation alone
DialogScoped blocking taskContainedExplicit, EscapeUntil dismissedBackground interaction must stopRoutine information or page-like content
Toast / statusNoncritical feedbackDoes not moveTimeout or explicitTransientConfirmation can safely be missed laterCritical, durable, or response-required information
BannerPersistent conditionDoes not moveUntil resolved or acknowledgedPersistentState affects ongoing page or application workOne-time routine confirmation
Alert dialogCritical responseContainedExplicit responseUntil answeredConsequence is high and action is required nowCommon undoable actions

Notification escalation ladder

1
Inline hintTyping guidance and format expectations.
2
Inline validationLocal correction while the control remains in context.
3
Field errorBlocking correction associated with one control.
4
Section messageA condition affecting one grouped region.
5
Page messageResult or condition affecting the current page.
6
Toast / statusNoncritical transient confirmation with no focus movement.
7
Notification centerDurable history for background or consequential events.
8
BannerPersistent condition affecting ongoing work.
9
DialogScoped task requiring completion or cancellation.
10
Alert dialogCritical response-required interruption.

Progressive-enhancement tiers

Baseline

Native production primitives

Form controls, fieldset/legend, output, progress, meter, details/summary, dialog, and broadly supported popover behavior.

Enhanced

Feature-detected improvements

Declarative commands, advanced popover modes, form-associated custom elements, and richer anchor behavior with semantic fallbacks.

Experimental

Opt-in evaluation

Newer or unevenly supported interaction features that require explicit browser matrices, known-gap documentation, and no silent dependency.

Behavioral contract for future systems

Intent and scope

Information, navigation, selection, action, configuration, or confirmation; local, region, page, or application scope.

Semantic baseline

The native primitive, why it fits or fails, and the exact ARIA or custom behavior delta.

Focus lifecycle

Trigger, initial focus, containment, keyboard model, completion, dismissal, and restoration.

State and save

Persistence, commit model, draft retention, validation, retry, cancellation, and data-loss risk.

Responsive transformation

How the surface changes on compact screens without changing semantics or losing state.

Support and validation

Browser tier, fallback, keyboard, touch, screen reader, zoom, forced colors, reduced motion, and telemetry.

Red-team conclusions

Native-first can become dogmatic

Custom components remain legitimate when the domain task requires them, but they inherit the complete interaction lifecycle and validation burden.

APG can be copied too literally

APG examples demonstrate patterns, not universal production support. Mobile, touch, browser, and assistive-technology testing remain mandatory.

Modality is often implementation convenience

A dialog guarantees attention but disrupts focus, comparison, and mobile input. Use it only when background interaction must stop.

Transient visibility is not communication

A toast that appeared can still have failed. Critical and durable outcomes need persistent or recoverable representation.

Settings become internal flag dumps

Expose meaningful user choices, not every implementation switch. Good defaults and primary workflows should work without settings repair.

LLM schemas can optimize locally

Require user goal, page context, alternatives considered, and interruption justification so a model cannot choose a technically valid but task-inappropriate widget.

Fold-in roadmap

v1.2

Documentation foundation

Research domains, decision matrix, findings, behavioral component contracts, recommendations, validation methods, references, JSON-LD, and OKF concepts.

v1.6.2

Implementation patterns

Native HTML examples, focus state diagrams, form error patterns, browser-support badges, and responsive surface examples.

v1.4

Interactive validation lab

Live components, keyboard traces, forced-color previews, mobile simulation, automated audits, and exportable implementation contracts.

ARIA semantics & accessibility trees

Native HTML, computed names, semantic roles, state, relationships, keyboard behavior, and interoperability.

ARIA is an interface contract between authored DOM, browser accessibility trees, platform accessibility APIs, and assistive technologies. It supplements semantics; it does not create behavior.

The semantic pipeline

1
User task

What is the person reading, choosing, editing, navigating, or operating?

2
Native HTML

Use the element that already carries correct semantics and behavior.

3
ARIA delta

Add only missing role, name, state, property, or relationship information.

4
Accessibility tree

Inspect the browser-computed role, name, description, state, and hierarchy.

5
Platform API

Browsers map the tree into operating-system accessibility APIs.

6
Assistive technology

Screen readers, speech input, switches, and other tools interpret the API.

7
Interaction

Authored keyboard, focus, pointer, touch, and state logic complete the component.

8
Verification

Test real combinations and preserve evidence of support and known gaps.

Five governing rules

Native first

Use HTML semantics and behavior before introducing custom roles.

No role without behavior

A role commits the component to the associated keyboard and state model.

Names are API

Visible and computed labels must be concise, aligned, and testable.

State is synchronized data

Visual, DOM, and ARIA state change together or the interface forks.

Inspect output, not intent

The accessibility tree—not source markup alone—is what assistive technology receives.

Semantic state taxonomy

StateMeaningTypical useDo not substitute
aria-currentThe current item within a related setCurrent page, step, date, locationSelection inside a tab, option, or grid
aria-selectedSelection in roles that support selectionTab, option, row, gridcell, treeitemGeneric active styling or current route
aria-checkedChecked choice or binary valueCheckbox, radio, switch, menuitemcheckboxToggle command state on a button
aria-pressedToggle-button pressed stateMute, pin, bold, favorite toggle buttonCheckbox or selection state
aria-expandedWhether a controlled/owned region is expandedDisclosure, menu button, combobox, treeitemVisibility unrelated to the control
aria-disabledPerceivable but unavailable operationDiscoverable disabled composite itemNative disabled when native behavior is desired
aria-invalidValue has failed validationForm field or group after validationRequired-but-empty before validation policy says invalid
aria-busyRegion is undergoing a coherent updateResults, feed, form, or live region updateGeneric visual spinner without update semantics

Role decision boundaries

NeedPreferred baselineARIA pattern only whenCommon failure
Site navigationnav, links, disclosure buttonsA true desktop-style application command menu is requiredUsing menubar for ordinary navigation
Choose one valueselect, radio groupAutocomplete, virtualized choices, or complex option content are essentialUsing menu for value selection
Layer peer contentLinks or disclosure when possibleOne panel at a time with tab-style arrow navigation is the taskTabs for sequential workflow or navigation
Static tabular informationtableCells need composite navigation, editing, or dense interactionGrid role only to shorten tab order
HierarchyNested headings, lists, and disclosuresDesktop-style hierarchy navigation materially improves the taskTree role for nested site links
Supplemental textPersistent visible helper textA short noninteractive description is genuinely secondaryInteractive tooltip or tooltip-only label

ARIA red-team questions

Could native HTML do this?

Document the rejected native element and the unmet task requirement.

What behavior does this role promise?

List keyboard, focus, selection, and update obligations.

What does the browser compute?

Inspect role, name, description, hierarchy, and state in the accessibility tree.

Can visible and programmatic state diverge?

Exercise every open, close, select, check, disable, invalidate, and loading transition.

Does the pattern work across support targets?

Use ARIA-AT as evidence and test the actual product combinations.

Is the semantic complexity worth it?

Prefer simpler document interaction when a composite widget adds more failure modes than value.

Deceptive design & ethical choice architecture

Patterns to recognize, prohibit, measure, and replace with autonomy-preserving alternatives.

Dark or deceptive patterns are not merely annoying interfaces. They are design mechanisms that materially interfere with informed preference through deception, asymmetric friction, hidden consequences, repeated pressure, or exploitation of vulnerability.

Boundary: persuasion versus impairment

Not every recommendation, default, or simplified flow is deceptive.A technique is safer when information is truthful, alternatives remain meaningful, the recommendation aligns with a documented user benefit, material consequences are visible, and the choice can be inspected and reversed.Escalate when the design works by reducing comprehension, hiding a meaningful alternative, exploiting inertia or vulnerability, or increasing the cost of expressing an existing preference.

Mechanism taxonomy

Obstruction

Adds unnecessary friction to an action the user already intends to take.

Examples: Cancellation mazes, channel switching, repeated deflection.

Preferred alternative: Keep the intended action on the shortest safe path.

Sneaking

Introduces cost, data use, or commitment without clear affirmative selection.

Examples: Preselected add-ons, hidden recurring terms, basket additions.

Preferred alternative: Require explicit selection and visible total consequences.

Interface interference

Uses prominence, wording, layout, or conventions to bias interpretation.

Examples: Faint decline, reversed hierarchy, confirmshaming, trick questions.

Preferred alternative: Use comparable salience and parallel language.

Forced action

Makes an unrelated disclosure or action a condition of task completion.

Examples: Mandatory registration, bundled consent, contact upload.

Preferred alternative: Separate purposes and ask at the point of need.

Social engineering

Applies urgency, scarcity, social proof, guilt, or fear to overcome reflection.

Examples: Resetting timers, fabricated demand, shaming.

Preferred alternative: Use truthful evidence and neutral decision language.

Temporal manipulation

Hides consequences that occur later or makes later reversal disproportionate.

Examples: Silent renewal, difficult withdrawal, changed terms.

Preferred alternative: Show future effects and durable reversal controls.

Choice and lifecycle parity

DimensionCompareFailure signal
SalienceSize, contrast, placement, iconographyThe provider-preferred option dominates without user benefit
LanguageGrammar, specificity, tone, consequencesDecline is vague, shaming, or double-negative
LayerSame screen versus deeper settingsAccept is immediate; reject requires exploration
EffortSteps, time, channel, authenticationExit is materially harder than entry
InformationPrice, recurrence, data, limitationsMaterial terms appear after commitment or sunk effort
ReversalInspect, modify, withdraw, cancelThe original preference cannot be changed proportionately

Research findings

Dark patterns are autonomy failures, not a synonym for bad usability.

The central concern is not visual ugliness or accidental friction alone, but interface choices that steer, deceive, coerce, obstruct, or materially impair informed preference expression.

Design implication: Classify deceptive design by impact on understanding, choice, effort, and reversibility—not by aesthetics.

Intent is ethically relevant, but effect is often the operational review threshold.

Manipulative intent can be difficult to observe. Regulatory and policy frameworks increasingly evaluate whether the design materially distorts or impairs free and informed decisions.

Design implication: Red-team effects and incentive structures even when no team explicitly intended harm.

Persuasion, defaults, and reduced friction are not inherently deceptive.

Choice architecture can help users understand complexity or complete intended tasks. Harm depends on truthfulness, user alignment, proportionality, alternatives, and context.

Design implication: Do not ban all nudges; require a documented user-benefit hypothesis and autonomy safeguards.

Equivalent choices should receive equivalent visual salience.

A bright accept button paired with a faint, hidden, or semantically shaming decline option creates non-neutral choice architecture.

Design implication: Audit color, size, wording, placement, and navigation depth across meaningful alternatives.

Friction asymmetry is a measurable design risk.

Easy enrollment paired with cancellation mazes, repeated retention prompts, or channel switching can block users from executing an already-formed preference.

Design implication: Compare steps, time, cognitive load, channel, and error rates for opposite lifecycle actions.

Material information must arrive before commitment.

Fees, recurring terms, data use, limitations, and consequences disclosed only after an action cannot support an informed decision.

Design implication: Place material terms in the decision field and repeat them at confirmation when consequences persist.

Defaults can convert inertia into unwanted agreement.

Preselected add-ons, privacy-invasive defaults, and silent renewal exploit inaction rather than affirmative preference.

Design implication: Use protective defaults and require affirmative action for optional costs, unrelated purposes, or recurring commitments.

Repeated prompting can override a decision without adding information.

Nagging after a clear rejection increases interruption and can wear down resistance rather than improve understanding.

Design implication: Respect durable choices and re-prompt only when context, purpose, or consequences materially change.

Confirmshaming replaces information with social pressure.

Decline labels framed as foolish, selfish, unsafe, or anti-social bias the decision and can exploit identity or emotion.

Design implication: Use neutral verb-led labels that describe outcomes without judging the person.

False urgency and scarcity manufacture a decision deadline.

Countdown timers, stock claims, activity messages, and limited-time language become deceptive when the underlying condition is false, unverifiable, or repeatedly resets.

Design implication: Require a verifiable source, expiry, scope, and fallback for every urgency or scarcity claim.

Disguised advertising breaks provenance and information scent.

Sponsored placements that imitate editorial content prevent users from understanding who is speaking and why the item is prominent.

Design implication: Label sponsorship before interaction and maintain a persistent visual distinction without making the disclosure obscure.

Hidden costs transform a comparison into a bait-and-switch journey.

Late mandatory fees make earlier price comparisons invalid and exploit sunk time or effort.

Design implication: Show the attainable total price early and keep optional add-ons unselected and separately explained.

Forced action bundles unrelated objectives.

Requiring registration, contact access, marketing consent, or broad data sharing to complete an unrelated task converts access into coerced disclosure.

Design implication: Separate purposes and ask at the moment a capability is genuinely needed.

A deceptive pattern can emerge across several individually plausible screens.

A journey may hide consequences through progressive fragmentation, repeated deflection, or cumulative friction even when no single screen appears egregious.

Design implication: Review end-to-end paths and temporal state, not only isolated screenshots.

Personalization can amplify manipulation and vulnerability.

Digital systems can target pressure, ranking, scarcity, or pricing based on inferred susceptibility at scale.

Design implication: Prohibit vulnerability-based optimization and audit segment-level outcome disparities.

Children, older adults, and cognitively burdened users can face disproportionate harm.

Limited literacy, digital skill, attention, financial resilience, or developmental capacity can make biased framing and obstructive journeys more consequential.

Design implication: Include vulnerability-centered personas and stricter defaults in ethical review.

Conversion experiments can industrialize harmful design.

Rapid A/B testing can discover which wording, color, timing, or friction most effectively overcomes user resistance—even without an explicit deceptive-design requirement.

Design implication: Place ethical guardrails before experimentation and reject variants that improve metrics through reduced comprehension or autonomy.

Consent rates do not measure consent quality.

A higher acceptance rate can result from hidden opt-out choices, default settings, habituation, or obstructive flows rather than informed preference.

Design implication: Measure comprehension, preference consistency, revocation success, and confidence—not acceptance alone.

Bright patterns can still manipulate.

Steering users toward a socially preferred or privacy-protective choice may still substitute the designer’s objective for reflective user choice.

Design implication: Prefer clarity, good defaults, and reversible decisions over emotional or obstructive pro-social manipulation.

Agent-mediated interaction creates a second autonomy boundary.

GUI agents can miss deceptive patterns or prioritize task completion over the user’s broader interests; human oversight can also create attention and workload costs.

Design implication: Expose total cost, recurring terms, permissions, and irreversible consequences in machine-readable confirmation boundaries.

Aggressive manipulation can create backlash as well as compliance.

Experimental evidence indicates stronger dark patterns can increase action rates while also increasing anger and perceptions of manipulation.

Design implication: Treat trust, complaint, regret, and long-term retention as first-class outcome measures.

Reversal is part of the original decision contract.

Consent, subscription, privacy, and notification choices remain valid only when users can later inspect and change them without disproportionate effort.

Design implication: Design withdrawal, cancellation, refund, and reset paths alongside acquisition—not afterward.

Metrics can conceal displaced harm.

A local increase in conversion may shift costs into support calls, refunds, chargebacks, complaints, privacy risk, or user distrust.

Design implication: Use a balanced outcome scorecard across business value, user value, reversals, and harm indicators.

Deceptive-design detection must preserve context.

Taxonomies and automated tools are useful, but identical visual techniques can be benign or harmful depending on truthfulness, task, timing, alternatives, and consequences.

Design implication: Combine pattern detection with a structured autonomy and evidence review.

Implementation recommendations

P0Governance

Adopt an autonomy impact assessment for consequential flows.

Require teams to document the user goal, business goal, material consequences, alternatives, vulnerabilities, and reversal path before launch.

Implementation guidance
  • Define the user’s likely underlying preference
  • List business incentives and conflicts
  • Identify decision-critical information
  • Assess coercion, deception, obstruction, and pressure
  • Record mitigations and approval
P0Choice architecture

Create a choice-symmetry contract.

Equivalent choices should be comparable in wording, salience, layer, and effort.

Implementation guidance
  • Inventory meaningful alternatives
  • Compare visual weight and placement
  • Compare number of screens and interactions
  • Compare consequences and confirmation
  • Document justified asymmetry
P0Lifecycle

Establish enrollment–exit friction parity.

Subscription, account, consent, and notification lifecycles must not trap users after acquisition.

Implementation guidance
  • Measure steps and completion time in both directions
  • Allow the same channel where feasible
  • Remove retention detours from the critical path
  • Preserve a clear final confirmation
  • Test cancellation and withdrawal quarterly
P0Commerce

Require attainable total-price disclosure before commitment.

Mandatory fees and recurring costs must be visible while users can still compare alternatives.

Implementation guidance
  • Define total-price computation
  • Separate optional from mandatory charges
  • Keep optional add-ons unselected
  • Repeat recurring terms at confirmation
  • Log price changes across the journey
P0Consent

Use affirmative, purpose-specific consent.

Consent must not be inferred from inactivity, bundled with unrelated purposes, or obtained through unequal first-layer choices.

Implementation guidance
  • Separate purposes
  • Use neutral labels
  • Provide reject/decline on the same layer
  • Avoid preselection
  • Make withdrawal continuously reachable
P0Experimentation

Add an ethics gate before A/B testing.

Variants should not enter experimentation when their mechanism depends on confusion, obstruction, false urgency, or hidden consequences.

Implementation guidance
  • State user-benefit hypothesis
  • List predicted harms and vulnerable segments
  • Define prohibited mechanisms
  • Add comprehension and regret metrics
  • Require review before scaling
P0Content

Ban confirmshaming and trick questions.

Labels must describe the result of a choice without guilt, double negatives, or identity pressure.

Implementation guidance
  • Use verb-led labels
  • Remove double negatives
  • Test paraphrase comprehension
  • Use the same grammatical structure for alternatives
  • Review localization for changed meaning
P1Evidence

Create a truthful urgency and scarcity registry.

Every scarcity, countdown, demand, and activity claim needs provenance and expiry.

Implementation guidance
  • Record data source
  • Record update frequency
  • Define expiration behavior
  • Prevent reset without a new event
  • Disable the claim when evidence is unavailable
P1Provenance

Separate advertising, sponsorship, recommendation, and editorial content.

Users should understand both the content source and the reason for placement before acting.

Implementation guidance
  • Label before interaction
  • Expose sponsor or ranking basis
  • Avoid editorial mimicry
  • Retain disclosures in compact layouts
  • Audit screen-reader reading order
P1Vulnerability

Run vulnerability-centered journey reviews.

Default usability testing may not reveal disproportionate harm to children, older adults, low-literacy users, or users under stress.

Implementation guidance
  • Define vulnerable personas
  • Test time pressure and comprehension
  • Inspect defaults and irreversible actions
  • Measure support and recovery burden
  • Apply stricter release thresholds
P1Agents

Add machine-readable confirmation boundaries for agents.

Automated agents need explicit total cost, recurrence, data disclosure, and irreversibility signals before commitment.

Implementation guidance
  • Publish structured transaction summaries
  • Require confirmation for recurring or irreversible effects
  • Expose optional versus mandatory items
  • Prevent hidden off-screen consequences
  • Log agent and human approvals
P1Metrics

Use a balanced autonomy scorecard.

Conversion should be interpreted alongside comprehension, preference consistency, reversals, complaints, and trust.

Implementation guidance
  • Track completion and correction
  • Track cancellations and refunds
  • Measure decision confidence
  • Measure choice consistency
  • Review segment-level disparities
P1Recovery

Provide durable receipts and reversal paths.

Consequential choices require an inspectable record and a direct route to change or undo them.

Implementation guidance
  • Show what changed
  • Show when it takes effect
  • Provide a stable receipt
  • Link directly to reversal
  • State deadlines and consequences
P1Review

Maintain a prohibited deceptive-pattern registry.

Teams need explicit examples and aliases so harmful mechanisms are not reintroduced under new names.

Implementation guidance
  • Map multiple taxonomies
  • Store pattern, mechanism, harm, and examples
  • Link to compliant alternatives
  • Add linting prompts
  • Review quarterly
P2Automation

Build deceptive-design journey linting.

Static component linting cannot detect cumulative obstruction, late fees, or repeated pressure across screens.

Implementation guidance
  • Capture full interaction traces
  • Compare opposite journeys
  • Detect preselection and hidden layers
  • Check state after rejection
  • Flag unsupported urgency and cost changes
P2Validation lab

Create scenario-based autonomy tests.

Teams need reusable scenarios for consent, cancellation, pricing, permissions, notifications, and agent-mediated transactions.

Implementation guidance
  • Define scenario and underlying preference
  • Render neutral and candidate variants
  • Measure comprehension and choice consistency
  • Record observed harms
  • Archive accepted and rejected variants
P2Operations

Add deceptive-design incident handling.

Complaints, chargebacks, unexpected data sharing, and cancellation failures can indicate a systemic design defect.

Implementation guidance
  • Define detection signals
  • Create escalation ownership
  • Preserve journey evidence
  • Pause harmful variants
  • Publish remediation and regression tests

Ethical component contracts

Ethical choice setPresent meaningful alternatives without deceptive prominence, wording, or effort asymmetry.

Anatomy

  • Decision question
  • Plain-language consequences
  • Comparable alternatives
  • Optional recommendation rationale
  • Persistent help and reversal path

Use

  • Use parallel grammar
  • Keep equivalent choices on the same layer
  • State consequences before action
  • Provide a neutral default or no default when appropriate

Avoid

  • Confirmshaming
  • Faint or hidden decline controls
  • Double negatives
  • Preselection that creates cost or disclosure

Autonomy and deceptive-design contract

User GoalExpress an informed preference
Business ConflictDocument any outcome the provider prefers
Choice Paritywording · visual weight · layer · effort
Material InformationVisible before choice
ReversalDirect and proportionate
Transparent checkout and price summaryPreserve price comparability and affirmative selection through the final commitment.

Anatomy

  • Itemized subtotal
  • Mandatory fees
  • Optional add-ons
  • Recurring terms
  • Total price
  • Commit action

Use

  • Show attainable total early
  • Keep optional items unselected
  • Repeat recurrence and cancellation terms
  • Provide editable review

Avoid

  • Drip pricing
  • Sneak into basket
  • Hidden tips
  • False no-fee claims

Autonomy and deceptive-design contract

Material Informationmandatory fees · recurrence · renewal date · cancellation terms
Optional ItemsUnselected and separately explained
Price IntegrityNo late mandatory increase
ConfirmationExplicit total and commitment
Subscription lifecycle controlMake enrollment, renewal, plan changes, and cancellation understandable and reversible.

Anatomy

  • Current plan and price
  • Renewal schedule
  • Change plan
  • Cancel
  • Consequences and effective date
  • Receipt

Use

  • Keep cancel near plan controls
  • Use the same authentication and channel where feasible
  • Allow direct cancellation
  • Confirm effective date

Avoid

  • Retention mazes
  • Mandatory phone-only cancellation after online signup
  • Ambiguous pause versus cancel
  • Repeated deflection

Autonomy and deceptive-design contract

Friction ParityEnrollment and cancellation measured together
Retention OffersOptional and outside critical path
Effective DateExplicit
ReceiptDurable
RejoinSeparate from cancellation
Truthful urgency and scarcity indicatorCommunicate a real time or quantity constraint without manufacturing pressure.

Anatomy

  • Claim
  • Source or basis
  • Scope
  • Expiry or refresh
  • Fallback when unknown

Use

  • Use exact quantities when available
  • Stop or change state at expiry
  • Expose whether demand is estimated
  • Remove stale claims

Avoid

  • Resetting timers
  • Fabricated activity
  • Unverifiable low-stock language
  • Urgency unrelated to the actual offer

Autonomy and deceptive-design contract

EvidenceRequired
ExpiryRequired
ResetOnly on a new verified event
Unknown StateDo not display the claim
PersonalizationMust not target vulnerability
Ethical experiment guardrailPrevent optimization systems from discovering and scaling manipulative variants.

Anatomy

  • User-benefit hypothesis
  • Autonomy risks
  • Prohibited mechanisms
  • Balanced metrics
  • Stop conditions
  • Review record

Use

  • Measure comprehension and regret
  • Review segment disparities
  • Log variant mechanisms
  • Stop on harm thresholds

Avoid

  • Conversion-only success
  • Hidden choice removal
  • Experimenting with false information
  • Scaling before ethical review

Autonomy and deceptive-design contract

Success Metricsbusiness outcome · user outcome · comprehension · reversal · complaints
Prohibiteddeception · obstruction · false urgency · hidden cost
ApprovalRequired before launch and scale
Audit TrailPersistent
Agent-safe transaction boundaryExpose material consequences to both humans and GUI agents before a consequential action.

Anatomy

  • Structured action summary
  • Total and recurring cost
  • Permissions and data sharing
  • Optional items
  • Irreversibility
  • Human confirmation

Use

  • Use machine-readable labels
  • Require explicit confirmation for recurrence
  • Expose alternatives and cancellation
  • Log agent decisions

Avoid

  • Visual-only disclosures
  • Preselected add-ons
  • Off-screen terms
  • Agent completion without consequence check

Autonomy and deceptive-design contract

Machine Readablecost · recurrence · permissions · optional items · reversal
Human OversightRisk-adjusted
ConfirmationRequired for consequential action
Audit TrailAgent and human actions

Red-team cautions

Do not classify by screenshot alone

Many harms emerge from timing, defaults, prior decisions, cumulative screens, or what happens after commitment.

Do not substitute bright manipulation

A privacy-friendly or socially desirable outcome does not justify deception, guilt, obstruction, or hiding alternatives.

Do not treat legal minimums as the ethical ceiling

Jurisdictional rules vary. The system standard remains truthful information, meaningful alternatives, proportional effort, and reversal.

Do not assume agents are resistant

Automation can follow the most procedurally obvious path and miss optional costs, recurrence, or manipulative wording.

Interactive validation lab · v1.4 foundation

Scenario-based red-team checks for autonomy, choice symmetry, lifecycle friction, price integrity, and pressure.

This lab is a review aid, not a legal classifier. Check the conditions present in a candidate flow. The weighted score highlights where a deeper human review is required.

0risk points

No conditions selected.

Choice symmetry

Consent, subscription, permissions, recommendations, or settings decisions.

Ethical alternative

Present equivalent choices with parallel wording, comparable salience, and explicit consequences.

Lifecycle friction

Enrollment, cancellation, account deletion, notification control, and consent withdrawal.

Ethical alternative

Measure entry and exit together and keep the stated intent on the critical path.

Price and transaction integrity

Checkout, travel, subscriptions, marketplace fees, add-ons, and tips.

Ethical alternative

Show an attainable total, leave optional items unselected, and expose recurrence in the confirmation field.

Pressure and social engineering

Scarcity, countdowns, activity messages, streaks, social proof, and repeated prompts.

Ethical alternative

Use verifiable facts, respect decisions, and remove emotional pressure unrelated to the task.

Implementation examples

Avoid · unequal consent

One visually dominant action and a vague, de-emphasized alternative.

Accept allContinue without extras

Prefer · explicit alternatives

Parallel labels and consequences on the same layer.

Use necessary onlyAllow optional analytics

Avoid · late total

Headline price: $80

Mandatory service and processing fees appear after checkout details.

Final: $112

Prefer · attainable total

Base $80 · mandatory fees $32

Optional add-ons remain unselected.

Total: $112

Roadmap status

v1.3ARIA semantics, accessible-name contracts, landmarks, live regions, composite focus, and accessibility-tree validation completed.
v1.4Deceptive-design domain, autonomy contracts, implementation examples, and scenario-based validation-lab foundation completed.
NextExecutable native component fixtures, browser and assistive-technology result capture, journey recording, and automated parity analysis.

Executable component laboratory · v1.6.2

Runnable semantic fixtures, runtime capabilities, interaction traces, support evidence, and exportable validation reports.

Use the lab to reproduce component behavior and record evidence. Automated results identify structural defects; they do not replace real assistive-technology or disabled-user testing.

Certification boundary

Executable evidence available · production certification pending

The laboratory can generate reproducible structural evidence. Production certification still requires observed representative browser, assistive-technology, and disabled-user results.

Fixtures
10
Capabilities
7
Evidence records
0

Runtime capability detection

Native dialogbaseline

Not checked

Inline scoped region or explicitly implemented accessible dialog
Popover APIbaseline

Not checked

Inline disclosure or nonmodal panel
inert attributebaseline

Not checked

Native modal dialog or carefully managed focus and pointer suppression
CSS anchor positioningprogressive

Not checked

Normal-flow panel, centered popover, or measured positioning
Customizable native selectexperimental

Not checked

Standard select or separately justified combobox
baseline

Form validation and recovery

Submit a compact profile without losing valid input after a validation failure.

Used only for this local fixture.

Automated result

  • Not run

Interaction trace

  1. No events recorded.

Support evidence recorder

No support evidence recorded in this browser.

Evidence records remain in local browser storage until exported or cleared. Do not enter personal or sensitive test data.

Validation methods

49 repeatable reviews for hierarchy, semantics, accessibility, interactive behavior, ethical design, provenance, and executable evidence.

Release status

v1.6.2 · deterministic compiler enabled, not production-certified

Canonical inputs, deterministic compilation, integrity manifests, source freshness, and governed review are implemented. Real-device visual and assistive-technology evidence remains required.

Completed
26 compiler and laboratory controls
Pending
5 certification workstreams
01

Task-to-visual contract

Are we representing the right user task and data relationship?

  1. State audience and decision
  2. List primary questions
  3. Identify required comparisons
  4. Classify data types and uncertainty
  5. Choose visual and interaction idioms
  6. Define success metrics
02

Five-second orientation test

Does the first viewport communicate identity, scope, priority, and action?

  1. Show the screen briefly
  2. Ask what it was about
  3. Ask what appeared most important
  4. Ask what action was available
  5. Compare answers with intended hierarchy
03

Blur and squint test

Does macro hierarchy remain visible without reading details?

  1. Blur or defocus the screen
  2. Identify dominant region
  3. Identify secondary anchors
  4. Check whether metadata competes
  5. Reduce strong treatments that do not represent priority
04

Grayscale and color-removal test

Can the interface still communicate state and distinction without hue?

  1. Render in grayscale
  2. Locate selected and error states
  3. Compare chart categories
  4. Verify links and controls remain identifiable
  5. Add redundant labels, shapes, patterns, or position
05

Erasure test

Does each prominent visual element earn its perceptual cost?

  1. Remove border, shadow, tint, icon container, or badge
  2. Re-evaluate grouping and meaning
  3. Keep the element removed if comprehension does not decline
  4. Add context back only where it supports decoding
06

Scan-path test

Does the likely eye path follow the intended communication sequence?

  1. Mark first fixation candidate
  2. Trace headings and leading words
  3. Identify interruptions by metadata
  4. Check that primary action follows understanding
  5. Verify critical content is not peripheral
07

Interaction-signifier test

Does every visual treatment accurately predict behavior?

  1. Inspect every pill, underline, icon, and colored region
  2. Ask whether it looks interactive
  3. Verify selected, disabled, loading, and error states
  4. Check visible and accessible labels
  5. Remove false affordances
08

Contrast-pair matrix

Do all permitted token pairings pass in every state and mode?

  1. Enumerate semantic foreground/background combinations
  2. Test text and non-text thresholds
  3. Test hover, pressed, selected, focus, and disabled
  4. Test light, dark, and forced colors
  5. Validate rendered alpha composition
09

Keyboard and focus audit

Can the full workflow be completed with visible, unobscured focus?

  1. Tab through in DOM order
  2. Open and close dialogs
  3. Operate filters and details
  4. Verify sticky layers do not obscure focus
  5. Test forced-colors focus visibility
10

Mobile reflow and semantic zoom audit

Does the experience preserve meaning at narrow widths and enlarged text?

  1. Test 320 CSS-pixel equivalent width
  2. Increase text and spacing
  3. Check table transformations
  4. Verify sticky offsets and safe areas
  5. Confirm no evidence is silently removed
11

Evidence integrity audit

Can the reader reconstruct the conclusion?

  1. Separate observed fact, interpretation, forecast, and recommendation
  2. Show baseline and units
  3. Expose source and time window
  4. Show uncertainty and exclusions
  5. Verify visual magnitude matches data magnitude
12

Task-success validation

Does the interface improve understanding and decisions?

  1. Measure time to locate
  2. Measure comparison accuracy
  3. Test comprehension of key finding
  4. Record error and recovery
  5. Assess decision confidence
  6. Segment by device and user needs
13

Provenance and attribution audit

Can a reader or agent identify who created each source, who owns the synthesis, what AI did, and who approved the result?

  1. Inspect creator, publisher, host, and attribution status for every source
  2. Verify human research owner and accountable editor
  3. Verify software-agent type, provider, model, and roles
  4. Trace each generated artifact to its contribution activity
  5. Confirm review status and accepted/rejected changes are explicit
14

OKF conformance and derivative-drift audit

Can the knowledge bundle be consumed independently, and do all generated views preserve the same IDs and relationships?

  1. Parse every non-reserved Markdown frontmatter block
  2. Require a non-empty type field
  3. Validate index.md and log.md conventions
  4. Resolve internal concept links and citation keys
  5. Compare entity counts and IDs across OKF, JSON, JSON-LD, and SPA
  6. Record the validation result
15

Form completion and recovery test

Can users complete, diagnose, correct, and confirm the form without losing valid work?

  1. Measure first-pass completion
  2. Trigger representative field and server errors
  3. Verify error-summary discovery
  4. Measure correction time
  5. Verify valid input preservation
  6. Verify retry and success confirmation
16

Keyboard focus trace

Does every revealed surface have a deterministic focus path?

  1. Record the trigger
  2. Record the initial focus target
  3. Trace Tab, Shift+Tab, arrows, and Escape
  4. Record action completion behavior
  5. Close through every supported path
  6. Verify the return target
17

Dismissal and data-loss matrix

Does every closing path preserve, commit, cancel, or explicitly warn about state?

  1. List explicit close and cancel
  2. Test Escape
  3. Test outside click or light dismiss
  4. Test route and back navigation
  5. Test replacement by another surface
  6. Record data outcome for each path
18

Interruption audit

Is the communication surface proportionate to urgency, action requirement, and persistence?

  1. Ask whether the user must know now
  2. Ask whether the user must act now
  3. Ask whether the condition remains true later
  4. Test a quieter surface
  5. Verify no unnecessary focus movement
  6. Check notification frequency and deduplication
19

Settings reachability test

Can users find and change a setting from the language and context in which they encounter the need?

  1. Start from the home screen
  2. Use settings search and synonyms
  3. Navigate through categories
  4. Follow a deep link from the affected feature
  5. Follow a notification or error reference
  6. Verify current value and save result
20

Overlay-stack audit

Is focus, Escape order, and restoration unambiguous when surfaces interact?

  1. Open a popover from a drawer
  2. Open a menu inside a dialog
  3. Trigger a toast during modal work
  4. Request a nested dialog
  5. Replace one surface with another
  6. Verify Escape order and final focus
21

Mobile surface-transformation test

Does the compact-screen surface preserve the desktop task contract?

  1. Transform popover or panel to sheet
  2. Compare available context
  3. Verify entered state survives
  4. Verify save and cancel semantics
  5. Verify focus and back navigation
  6. Test virtual keyboard and zoom
22

Native-semantic audit

Has a custom component justified and reproduced the native interaction contract it replaces?

  1. Identify the rejected native element
  2. Document the unmet task need
  3. List native behaviors to reproduce
  4. Test keyboard, touch, labels, validation, reset, and submission
  5. Test assistive technologies
  6. Document fallback and known support gaps
23

Computed accessible-name and description audit

Do computed names and descriptions match visible intent without duplication, omission, or hidden overrides?

  1. Inspect each focusable control in the accessibility tree
  2. Compare visible label with computed accessible name
  3. Verify name source and precedence
  4. Check empty or whitespace aria-labelledby targets
  5. Separate instructions and errors into descriptions
  6. Test speech activation using visible wording
24

Role, state, and property conformance audit

Are roles valid for their HTML hosts and are every state and relationship supported, truthful, and synchronized?

  1. Record implicit native role
  2. Compare explicit role against ARIA in HTML
  3. Check required context and owned elements
  4. Check required and prohibited attributes
  5. Exercise every state transition
  6. Inspect computed accessibility tree
25

Accessibility-tree inspection

What role, name, description, state, hierarchy, and relationships does the browser actually expose?

  1. Inspect supported browsers
  2. Capture initial computed tree
  3. Open, select, disable, invalidate, and close states
  4. Compare DOM order with accessibility order
  5. Check presentational descendants and hidden subtrees
  6. Store snapshots for regression review
26

Composite-widget keyboard conformance test

Can a keyboard user enter, navigate, operate, and leave the composite using the documented pattern?

  1. Verify one intended page tab stop
  2. Test directional keys and orientation
  3. Test Home, End, typeahead, and activation where specified
  4. Test disabled items
  5. Test dynamic filtering or virtualization
  6. Verify focus after removal and close
27

Landmark and structural navigation audit

Does semantic navigation reflect the visible page hierarchy without excessive or ambiguous regions?

  1. List landmarks with a screen reader or browser tool
  2. Verify one primary main region
  3. Label repeated navigation/search/complementary regions
  4. Check heading and landmark order
  5. Remove low-value generic regions
  6. Test skip links and deep links
28

Live-region announcement audit

Are dynamic messages announced once, at the correct urgency, without stealing focus or losing critical information?

  1. Trigger routine success and advisory status
  2. Trigger validation and critical alerts
  3. Check duplicate announcements
  4. Test rapid consecutive updates
  5. Verify aria-busy and atomicity behavior
  6. Confirm durable recovery path for consequential messages
29

Hidden-content and focus-exposure audit

Can any element be keyboard-focusable while removed from the accessibility tree or visually unavailable?

  1. Search focusable descendants under aria-hidden
  2. Test closed popovers, dialogs, drawers, and disclosures
  3. Compare hidden, display:none, inert, and aria-hidden behavior
  4. Verify focus restoration after hide
  5. Check role none/presentation descendants
  6. Test browser find and virtual cursor behavior where relevant
30

ARIA-AT interoperability review

Does the chosen implementation have known must-have or should-have gaps in supported browser and assistive-technology combinations?

  1. Locate relevant APG example support table
  2. Review detailed failed assertions
  3. Compare alternate implementations
  4. Test actual product markup
  5. Record browser, AT, OS, and versions
  6. Define mitigation without coding permanently to a transient bug
31

Choice symmetry audit

Are equivalent options presented with equivalent clarity and effort?

  1. List meaningful alternatives
  2. Compare wording and grammar
  3. Compare visual salience
  4. Compare navigation depth and target size
  5. Document justified differences
32

Friction parity test

Can users enter and exit a lifecycle with proportionate effort?

  1. Complete enrollment or enablement
  2. Complete cancellation or withdrawal
  3. Measure steps, time, errors, and channels
  4. Identify retention detours
  5. Set and enforce a parity budget
33

Material-information timing audit

Does the user receive decision-critical information before commitment?

  1. List price, recurrence, permissions, limitations, and consequences
  2. Mark the first screen each fact appears
  3. Identify facts disclosed after sunk effort
  4. Move material facts into the decision field
  5. Retest comprehension
34

Autonomy impact assessment

Could the interface cause a user to act against a reasonably inferred preference?

  1. State the underlying user goal
  2. Identify business conflicts
  3. Identify cognitive or situational vulnerabilities
  4. Assess deception, coercion, obstruction, and pressure
  5. Record mitigation and approval
35

Cancellation journey replay

Does cancellation execute the intent rather than attempt to defeat it?

  1. Record the complete path
  2. Count retention interruptions
  3. Check labels and effective date
  4. Verify service and billing state
  5. Confirm receipt and re-entry path
36

Truthful urgency verification

Can every urgency or scarcity cue be proven and allowed to expire correctly?

  1. Inspect the source of truth
  2. Verify scope and update interval
  3. Wait through expiration
  4. Test unavailable-data behavior
  5. Check personalization and segment differences
37

Vulnerability-centered walkthrough

Does the design disproportionately burden users with lower literacy, attention, digital skill, or resilience?

  1. Select vulnerability-centered personas
  2. Run under time and attention pressure
  3. Test comprehension and recovery
  4. Inspect defaults and irreversible actions
  5. Apply stricter acceptance thresholds
38

Experiment ethics gate

Could an experiment improve the target metric by reducing autonomy or comprehension?

  1. Document the causal mechanism
  2. Define prohibited mechanisms
  3. Add comprehension and reversal metrics
  4. Review vulnerable segments
  5. Approve, revise, or reject before traffic
39

Agent susceptibility test

Can a GUI agent identify optional costs, recurrence, permissions, and deceptive pressure?

  1. Run the task with a representative agent
  2. Inspect which information the agent reads
  3. Verify confirmation boundaries
  4. Test preselection and hidden terms
  5. Compare agent, human, and combined outcomes
40

Composite journey dark-pattern audit

Does harm emerge across several screens or over time?

  1. Capture a complete interaction trace
  2. Annotate prompts, defaults, costs, and state changes
  3. Compare initial and final understanding
  4. Test rejection persistence
  5. Review cumulative friction and displaced harm
41

Balanced outcome audit

Are business metrics masking regret, correction, support, or trust costs?

  1. List target business metrics
  2. Add comprehension and preference-consistency metrics
  3. Add cancellation, refund, and complaint metrics
  4. Segment by vulnerability and channel
  5. Review short- and long-term outcomes
42

Fixture contract test

Does the executable example implement the declared native primitive, name, role, state, keyboard, focus, and dismissal contract?

  1. Load the named fixture
  2. Run structural checks
  3. Exercise required keys
  4. Exercise dismissal paths
  5. Compare observed state with contract
  6. Record discrepancies
43

Focus trace replay

Can a reviewer reproduce entry, internal navigation, action, dismissal, and restoration?

  1. Reset fixture
  2. Start trace recording
  3. Activate the trigger
  4. Navigate and act with keyboard
  5. Dismiss through each supported route
  6. Compare focus trace with expectation
44

Runtime capability audit

Which native and CSS capabilities are present in the current execution environment?

  1. Run feature detection
  2. Record user agent and viewport
  3. Compare against component support tier
  4. Exercise fallback path
  5. Record unexpected partial support
45

Assistive-technology evidence record

What did a named browser, AT, OS, and input combination actually expose and announce?

  1. Identify complete environment tuple
  2. State expected output
  3. Perform the fixture task
  4. Record observed role, name, state, order, and announcement
  5. Classify pass, partial, fail, or blocked
  6. Date and sign the record
46

Responsive variant equivalence

Does the mobile or compact variant preserve task, information, state, save model, and recovery?

  1. Run desktop variant
  2. Run compact variant
  3. Compare task and material information
  4. Compare focus and dismissal behavior
  5. Compare state persistence
  6. Record intentional differences
47

Choice parity computation

Do equivalent choices have comparable measurable presentation and interaction cost?

  1. Measure target area
  2. Compare text size, weight, opacity, and contrast
  3. Compare DOM and visual order
  4. Count interaction steps
  5. Record defaults
  6. Escalate contextual questions
48

Validation report completeness audit

Does the exported result contain enough context to reproduce and interpret the result later?

  1. Verify schema version
  2. Verify fixture and component IDs
  3. Verify environment tuple
  4. Verify expected and observed results
  5. Verify evidence mode and date
  6. Verify limitations and reviewer
49

Production certification gate

Has the declared support matrix been observed without unresolved blocking defects?

  1. List baseline fixtures and environments
  2. Review automated results
  3. Review manual and AT evidence
  4. Review disabled-user findings where required
  5. Review approved exceptions
  6. Set explicit certification status

Anti-pattern register

Common visual, interaction, accessibility, and evidence failures.

Hierarchy

  • Equal visual weight for every card
  • Multiple saturated accent colors in one viewport
  • Pills for passive dates, sources, counts, and metadata
  • Large colored icon containers for minor attributes
  • Borders and shadows around every nested region
  • Oversized utility-page hero sections
  • Centered alignment for dense analytical content

Interaction

  • Important controls visible only on hover
  • Unfamiliar icon-only primary actions
  • Filters with no visible reset
  • State changes without feedback
  • Disabled controls without explanation
  • Irreversible deletion
  • Dragging as the only operation
  • Auto-advancing carousels
  • Accordions hiding primary evidence

Color

  • Rainbow scales for ordered data
  • Red and green as the sole distinction
  • Low-contrast metadata
  • Yellow text on white
  • One brand color used for links, focus, selection, information, and chart series
  • Mechanical light-to-dark inversion
  • Transparent essential foregrounds
  • Arbitrary emotional color claims

Visualization

  • Choosing a chart before defining the question
  • Pie charts for small precise differences
  • Bubble size for critical quantitative values
  • 3D effects
  • Dual axes without compelling justification
  • Inconsistent scales across small multiples
  • Remote legends when direct labels are possible
  • Signal scores without methodology

Responsive

  • Fixed sticky offsets that assume one header height
  • Silent removal of comparison fields on mobile
  • Desktop card spacing stretched from mobile
  • Tiny icon targets
  • Focus clipped by overflow
  • Critical actions only at screen edges

Evidence & ethics

  • Mixing observed facts with inference
  • Hiding source or uncertainty
  • Sponsored material styled as editorial
  • Preselected consent
  • Artificial urgency or scarcity
  • Making enrollment easy and cancellation difficult
  • Optimizing clicks instead of task success

Provenance & knowledge governance

  • Generic AI-generated labels without accountable ownership
  • Replacing source creators with the synthesis author
  • Treating the SPA as the only canonical artifact
  • Silent agent rewriting of accepted conclusions
  • Unvalidated frontmatter, links, or citation keys
  • Publishing public structured data that overstates invisible content
  • Conflating publisher, hosting site, and creator
  • Losing rejected changes or superseded states

Forms

  • Placeholder-only field identification
  • Multiple unrelated questions in one row
  • Validation rules revealed only after submission
  • Clearing valid input after an error
  • Color-only required or invalid state
  • Custom controls without form reset, submission, and labeling behavior
  • Generic errors without correction guidance
  • Silent save or ambiguous commit semantics
  • Disabling submit without visible busy and retry state

Interactive surfaces

  • Choosing a component by visual shape rather than behavior
  • Using ARIA menu roles for ordinary site navigation
  • Context menus as the only access to important actions
  • Critical failures shown only in transient toasts
  • Light dismiss that silently discards work
  • Nested modal dialogs
  • Popover cascades
  • Nonmodal drawers that trap focus
  • Modal sheets that allow background interaction
  • Settings placed in a one-time modal mega-form
  • Unbounded notification stacks
  • No browser-support tier for emerging HTML primitives

ARIA semantics & accessibility trees

  • Adding ARIA when native semantics already express the correct contract
  • Using a role without implementing its keyboard and focus expectations
  • Redundant role attributes that can drift from the HTML element
  • aria-label that replaces or contradicts visible text
  • Empty aria-labelledby or aria-describedby references
  • Using aria-selected for generic active styling
  • Stale aria-expanded, aria-checked, aria-pressed, or aria-busy state
  • aria-disabled without blocking activation
  • aria-hidden on focusable elements or their ancestors
  • role none/presentation used to hide content
  • aria-owns used to repair avoidable DOM structure
  • Application, menu, grid, tree, or treegrid roles used for ordinary document content
  • Every section exposed as a region landmark
  • Assertive live regions for routine success and keystroke feedback
  • APG example code copied without browser and assistive-technology testing
  • Accessibility review based only on source markup rather than computed tree output

Deceptive design & autonomy

  • Unequal visual prominence for equivalent choices
  • Hidden or second-layer decline and reject controls
  • Confirmshaming, trick questions, and double negatives
  • Preselected optional charges, data sharing, or recurring commitments
  • Late mandatory fees and drip pricing
  • False or resetting urgency and scarcity claims
  • Disguised advertising or sponsored content
  • Repeated prompting after a clear decision
  • Enrollment–cancellation friction asymmetry
  • Retention mazes and channel switching
  • Bundling unrelated permissions with task completion
  • Default settings that are difficult to inspect or reverse
  • Personalizing pressure toward vulnerable users
  • Conversion-only A/B testing
  • Transient disclosure of durable consequences
  • Agent transactions without machine-readable consequences
  • Using bright patterns to manipulate toward a preferred social outcome
  • Treating legal compliance as the only ethical threshold

Validation and certification failures

  • Calling automated output production certification
  • Publishing support without a complete environment tuple
  • Testing only the resting visual state
  • Ignoring compact and transformed variants
  • Allowing handbook examples and shipped components to diverge
  • Using parity calculations as a substitute for contextual ethical review

Research reference library

176 sources with evidence class, creator/publisher attribution, citation wording, application, and boundaries.

Showing 176 of 176

Tufte & visual evidence9 sources

TUFTE-VDQIThe Visual Display of Quantitative InformationGraphical integrity, data-ink ratio, lie factor, small multiples, data density, and high-resolution displays. Framework
Use for
Graphical integrity, data-ink ratio, lie factor, small multiples, data density, and high-resolution displays.
Reference as
Tufte argues that visual displays should maximize meaningful data communication while reducing graphical elements that do not support interpretation.
Do not overstate
Do not claim controlled UX research proves that maximizing data-ink always produces the best interface.
Creator / author
Edward R. Tufte
Publisher
Graphics Press
Host
Edward Tufte / Graphics Press
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
TUFTE-EIEnvisioning InformationLayering and separation, micro/macro readings, visual complexity, color and information, escaping flatland, and multidimensional data. Framework
Use for
Layering and separation, micro/macro readings, visual complexity, color and information, escaping flatland, and multidimensional data.
Reference as
Tufte proposes layering and separation as mechanisms for presenting complex information without fragmenting it.
Best future application
Dense dashboards, card alternatives, multivariate displays, maps, comparative matrices, and semantic hierarchy.
Creator / author
Edward R. Tufte
Publisher
Graphics Press
Host
Edward Tufte / Graphics Press
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
TUFTE-VEVisual Explanations: Images and Quantities, Evidence and NarrativeCause and effect, processes, motion, before-and-after evidence, decision-making, and Challenger analysis. Framework
Use for
Cause and effect, processes, motion, before-and-after evidence, decision-making, and Challenger analysis.
Reference as
Tufte emphasizes that explanations should show mechanisms, comparisons, sequence, and causes rather than presenting isolated outcomes.
Best future application
Incident timelines, deployment analysis, before-and-after views, causal hypotheses, and process visualization.
Creator / author
Edward R. Tufte
Publisher
Graphics Press
Host
Edward Tufte / Graphics Press
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
TUFTE-BEBeautiful EvidenceIntegrating prose, numbers, diagrams, images, annotations, and provenance into one evidential structure. Framework
Use for
Integrating prose, numbers, diagrams, images, annotations, and provenance into one evidential structure.
Reference as
Tufte treats words, numbers, images, diagrams, and motion as complementary forms of evidence that should be evaluated for quality, relevance, and integrity.
Best future application
Claim–evidence structures, source attribution, annotated charts, sparklines, and multimodal reports.
Creator / author
Edward R. Tufte
Publisher
Graphics Press
Host
Edward Tufte / Graphics Press
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
TUFTE-SFESeeing with Fresh Eyes: Meaning, Space, Data, TruthObservation, analytical seeing, typography, meaning, spatial reasoning, and truth in presentation. Framework
Use for
Observation, analytical seeing, typography, meaning, spatial reasoning, and truth in presentation.
Reference as
Tufte frames visual reasoning as a discipline of sustained observation rather than merely choosing an attractive representation.
Best future application
Reframing UI problems before choosing cards, charts, or interaction patterns.
Creator / author
Edward R. Tufte
Publisher
Graphics Press
Host
Edward Tufte / Graphics Press
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
TUFTE-VSTVisual and Statistical Thinking: Displays of Evidence for Making DecisionsDecision evidence, multivariate reasoning, causal analysis, comparison, and the Challenger case. Framework
Use for
Decision evidence, multivariate reasoning, causal analysis, comparison, and the Challenger case.
Reference as
Tufte argues that decision displays should arrange relevant variables together so the reader can test relationships and alternative explanations.
Best future application
Executive decision support, incident review, risk analysis, and evidence-based recommendations.
Creator / author
Edward R. Tufte
Publisher
Graphics Press
Host
Edward Tufte / Graphics Press
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
TUFTE-POWERPOINTThe Cognitive Style of PowerPointEvidence fragmentation, low-resolution presentation, bullet hierarchies, and slide-driven reasoning. Framework
Use for
Evidence fragmentation, low-resolution presentation, bullet hierarchies, and slide-driven reasoning.
Reference as
Tufte criticizes presentation formats that fragment related evidence and prevent direct comparison.
Best future application
Avoiding “one metric per card,” excessive tab segmentation, wizard-only inspection, and sparse layouts that increase memory burden.
Creator / author
Edward R. Tufte
Publisher
Graphics Press
Host
Edward Tufte / Graphics Press
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
TUFTE-SLOPEGRAPHSlopegraphs for Comparing GradientsTwo-point change, rank movement, before-and-after values, direction, and magnitude. FrameworkPractice
Use for
Two-point change, rank movement, before-and-after values, direction, and magnitude.
Reference as
Tufte recommends slopegraphs when the analytical task is to compare changes between two meaningful states.
Boundary
They become difficult to read when too many series overlap or labels cannot be placed clearly.
Creator / author
Edward R. Tufte
Host
Edward Tufte / Graphics Press
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
TUFTE-CHARTJUNKChartjunkVisual elements that consume attention without supporting the data or interpretation. FrameworkPractice
Use for
Visual elements that consume attention without supporting the data or interpretation.
Reference as
Tufte uses “chartjunk” to criticize visual treatments that compete with, obscure, or distort the evidence.
Boundary
Do not use the term as a blanket objection to all illustration, branding, or visual personality.
Creator / author
Edward R. Tufte
Host
Edward Tufte / Graphics Press
Origin
human-authored-framework-or-book
Attribution status
verified
Open source

Visual grammar & perception10 sources

BERTIN-1967Semiology of Graphics: Diagrams, Networks, MapsPosition, size, shape, orientation, value, texture, and hue as distinct visual variables. Framework
Use for
Position, size, shape, orientation, value, texture, and hue as distinct visual variables.
Reference as
Bertin established a systematic visual grammar in which graphical variables have different capacities for expressing categories, order, and quantity.
Best future application
Choosing whether a distinction should be encoded by position, lightness, hue, size, or shape.
Boundary
Bertin’s taxonomy is foundational theory, not a current accessibility specification.
Creator / author
Jacques Bertin
Publisher
Esri Press
Host
Esri
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
CM-1984Graphical Perception: Theory, Experimentation, and Application to the Development of Graphical MethodsRelative accuracy of position, length, angle, slope, area, volume, and color-based encodings. Primary
Use for
Relative accuracy of position, length, angle, slope, area, volume, and color-based encodings.
Reference as
Cleveland and McGill found that judgments based on aligned position and length were generally more accurate than judgments based on area or volume.
Best future application
Justifying bars, dots, aligned values, and tables over bubbles, radial gauges, or 3D forms.
Boundary
Treat the ordering as a population-level empirical pattern, not an immutable rule for every task or individual.
Creator / author
William S. Cleveland, Robert McGill
Host
York University
Origin
human-authored-primary-research
Attribution status
verified
Open source
CM-1985Graphical Perception and Graphical Methods for Analyzing Scientific DataExtending graphical-perception findings to scientific data analysis. Primary
Use for
Extending graphical-perception findings to scientific data analysis.
Reference as
Cleveland and McGill used perceptual evidence to motivate graphical methods that support more accurate quantitative comparison.
Best future application
Technical dashboards, scientific reporting, and analytical interfaces.
Creator / author
William S. Cleveland, Robert McGill
Host
Dalhousie University
Origin
human-authored-primary-research
Attribution status
verified
Open source
CM-1986An Experiment in Graphical PerceptionAdditional controlled evidence on graphical decoding tasks. Primary
Use for
Additional controlled evidence on graphical decoding tasks.
Reference as
Subsequent Cleveland and McGill experiments further evaluated how accurately viewers decode different graphical forms.
Use when
A design review needs stronger support than a general visualization guideline.
Creator / author
William S. Cleveland, Robert McGill
Host
ScienceDirect
Origin
human-authored-primary-research
Attribution status
verified
Open source
GRAPHICAL-PERCEPTION-REVIEWA Review of Graphical Perception ResearchContemporary synthesis and qualification of classic encoding hierarchies. Review
Use for
Contemporary synthesis and qualification of classic encoding hierarchies.
Reference as
Later graphical-perception research broadly supports the importance of encoding choice while showing that outcomes vary by task, chart construction, and population.
Best future application
Avoiding overly rigid references to a single universal encoding hierarchy.
Host
arXiv
Origin
human-authored-research-review
Attribution status
pending-author-verification
Open source
VIS-INDIVIDUAL-DIFFERENCESIndividual Differences in Visualization PerceptionVariability among users in chart decoding and visualization performance. Primary
Use for
Variability among users in chart decoding and visualization performance.
Reference as
Visualization performance can vary meaningfully across individuals, so population-level design rankings should not replace testing with the intended audience.
Best future application
Accessibility, expert-versus-novice interfaces, and configurable visualization modes.
Host
arXiv
Origin
human-authored-primary-research
Attribution status
pending-author-verification
Open source
MACKINLAY-1986Automating the Design of Graphical Presentations of Relational InformationExpressiveness and effectiveness criteria. Framework
Use for
Expressiveness and effectiveness criteria.
Reference as
Mackinlay formalized the distinction between representing the data truthfully and selecting an effective perceptual encoding.
Best future application
Explaining why a truthful chart can still be a poor chart.
Creator / author
Jock D. Mackinlay
Host
OSTI.GOV
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
MUNZNER-NESTEDA Nested Model for Visualization Design and ValidationSeparating domain problems, data/task abstraction, visual encoding and interaction, and implementation algorithms. Framework
Use for
Separating domain problems, data/task abstraction, visual encoding and interaction, and implementation algorithms.
Reference as
Munzner’s nested model identifies distinct failure modes at the domain, abstraction, encoding and interaction, and algorithmic layers.
Best future application
Task-first design reviews and diagnosing whether a UI failure is conceptual or merely presentational.
Creator / author
Tamara Munzner
Host
University of British Columbia
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
MUNZNER-BOOKVisualization Analysis and DesignVisualization task abstraction, idiom selection, data types, validation, interaction, and scalability. Framework
Use for
Visualization task abstraction, idiom selection, data types, validation, interaction, and scalability.
Reference as
Munzner provides a systematic methodology for moving from domain questions to data abstractions and appropriate visual idioms.
Best future application
Formal visualization design standards and generated chart-selection logic.
Creator / author
Tamara Munzner
Publisher
CRC Press / Taylor & Francis
Host
Taylor & Francis
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
WARE-PERCEPTIONInformation Visualization: Perception for DesignVisual attention, pattern recognition, color perception, motion, spatial cognition, and preattentive processing. FrameworkReview
Use for
Visual attention, pattern recognition, color perception, motion, spatial cognition, and preattentive processing.
Reference as
Ware synthesizes vision science into practical principles for designing perceptually effective information displays.
Best future application
Salience, chart readability, visual search, color, and motion decisions.
Creator / author
Colin Ware
Publisher
Elsevier
Host
Elsevier
Origin
human-authored-research-review
Attribution status
verified
Open source

Attention, hierarchy & scanning8 sources

TREISMAN-1980A Feature-Integration Theory of AttentionFeature search, conjunction search, preattentive attributes, and selective attention. PrimaryFramework
Use for
Feature search, conjunction search, preattentive attributes, and selective attention.
Reference as
Treisman and Gelade distinguished rapid search for a unique visual feature from slower search requiring combinations of features.
Best future application
Exception highlighting, selected states, and limiting the number of visual properties required to find an item.
Boundary
Do not summarize this as “any brightly colored element is processed instantly.”
Creator / author
Anne Treisman, Garry Gelade
Host
Université Grenoble Alpes
Origin
human-authored-primary-research
Attribution status
verified
Open source
FIT-40-YEAR-REVIEWForty Years After Feature Integration TheoryCurrent interpretation and qualification of feature-integration theory. Review
Use for
Current interpretation and qualification of feature-integration theory.
Reference as
Later research has revised and expanded feature-integration theory while retaining the importance of feature-based attention and search.
Best future application
When a design decision needs a contemporary source rather than the 1980 paper alone.
Host
U.S. National Library of Medicine
Origin
human-authored-research-review
Attribution status
pending-author-verification
Open source
LINDGAARD-2006Attention Web Designers: You Have 50 Milliseconds to Make a Good First ImpressionRapid judgments of visual appeal. Primary
Use for
Rapid judgments of visual appeal.
Reference as
Lindgaard and colleagues found that visual-appeal judgments formed after very brief exposure could remain consistent with judgments formed after longer exposure.
Do not say
“Users understand the interface in 50 milliseconds” or “usability is determined in 50 milliseconds.”
Creator / author
Gitte Lindgaard, Gary Fernandes, Cathy Dudek, J. Brown
Host
Taylor & Francis Online
Origin
human-authored-primary-research
Attribution status
verified
Open source
TUCH-2012The Role of Visual Complexity and Prototypicality Regarding First Impression of WebsitesVisual complexity, familiar structural patterns, and first impressions. Primary
Use for
Visual complexity, familiar structural patterns, and first impressions.
Reference as
Tuch and colleagues found that visual complexity and prototypicality influence immediate aesthetic evaluations of websites.
Best future application
Supporting recognizable information architecture and controlling first-viewport complexity.
Host
Google Research
Origin
human-authored-primary-research
Attribution status
pending-author-verification
Open source
NNG-SCANNINGF-Shaped Pattern of Reading on the WebScanning behavior, front-loaded wording, headings, and line structure. Practice
Use for
Scanning behavior, front-loaded wording, headings, and line structure.
Reference as
NN/g’s eye-tracking work observed recurring scanning patterns, including the F-pattern, particularly in poorly formatted or text-heavy content.
Do not say
“All users always read in an F pattern.” NN/g explicitly treats it as one of several possible patterns.
Publisher
Nielsen Norman Group
Host
Nielsen Norman Group
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
NNG-PROXIMITYThe Law of ProximityGrouping related elements through spacing. PracticeFramework
Use for
Grouping related elements through spacing.
Reference as
Proximity communicates relationships, making spacing a semantic design variable rather than mere decoration.
Best future application
Card internals, metadata rows, headings, filters, and section separation.
Publisher
Nielsen Norman Group
Host
Nielsen Norman Group
Origin
human-authored-framework-or-book
Attribution status
publisher-only
Open source
OLDER-ADULT-EYETRACKING-REVIEWEye-Tracking Research on Older Adults: Systematic ReviewAge-related visual search, fixation, attention, and interface evaluation. Review
Use for
Age-related visual search, fixation, attention, and interface evaluation.
Reference as
Research on older adults indicates that clutter, peripheral placement, and complex visual search can create disproportionate difficulty for aging users.
Best future application
Designing for older adults, accessible travel tools, dense dashboards, and critical workflows.
Host
White Rose Research Online
Origin
human-authored-research-review
Attribution status
pending-author-verification
Open source
OLDER-ADULT-PERIPHERYOlder Adults Fail to See Peripheral InformationPeripheral placement, attention distribution, and age-related discoverability. Primary
Use for
Peripheral placement, attention distribution, and age-related discoverability.
Reference as
Eye-tracking evidence suggests that older adults can be less likely to notice information placed outside their primary scan path.
Best future application
Avoiding critical actions or alerts only at viewport edges.
Creator / author
Jennifer Romano Bergstrom et al.
Host
Vassar College
Origin
human-authored-primary-research
Attribution status
verified
Open source

Interaction & discoverability12 sources

NORMAN-DOETThe Design of Everyday ThingsSignifiers, mappings, feedback, conceptual models, affordances, and execution/evaluation gaps. Framework
Use for
Signifiers, mappings, feedback, conceptual models, affordances, and execution/evaluation gaps.
Reference as
Norman argues that interfaces should make possible actions discoverable and should provide visible feedback about system state and outcomes.
Best future application
Buttons, filters, controls, loading states, errors, and state transitions.
Creator / author
Donald A. Norman
Publisher
Basic Books
Host
JND.org
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
NORMAN-SIGNIFIERSSignifiers, Not AffordancesDistinguishing what an object permits from what communicates how to use it. FrameworkPractice
Use for
Distinguishing what an object permits from what communicates how to use it.
Reference as
Norman distinguishes affordances from signifiers: the interface must visibly communicate where and how an action can be performed.
Best future application
Avoiding false affordances, passive pills that resemble buttons, and hidden controls.
Creator / author
Donald A. Norman
Host
JND.org
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
SHNEIDERMAN-EYESThe Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations“Overview first, zoom and filter, then details on demand.” Framework
Use for
“Overview first, zoom and filter, then details on demand.”
Reference as
Shneiderman proposes an information-seeking sequence that begins with orientation, supports narrowing, and then exposes detail.
Boundary
Treat it as a design mantra, not a universal experimental law.
Creator / author
Ben Shneiderman
Host
University of Maryland
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
SHNEIDERMAN-DIRECTDirect Manipulation: A Step Beyond Programming LanguagesVisible objects, incremental actions, reversibility, and immediate feedback. Framework
Use for
Visible objects, incremental actions, reversibility, and immediate feedback.
Reference as
Shneiderman characterizes direct manipulation through visible objects, rapid incremental operations, and reversible actions.
Best future application
In-place filters, drag-and-drop, previews, editable classifications, and undo.
Creator / author
Ben Shneiderman
Host
SciSpace
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
NIELSEN-HEURISTICS10 Usability Heuristics for User Interface DesignSystem visibility, control, consistency, error prevention, recognition, recovery, and minimalism. FrameworkPractice
Use for
System visibility, control, consistency, error prevention, recognition, recovery, and minimalism.
Reference as
Nielsen’s heuristics provide a broad inspection framework for identifying common interaction and comprehension failures.
Do not say
“These ten rules have been experimentally proven to cover every usability failure.”
Creator / author
Jakob Nielsen
Publisher
Nielsen Norman Group
Host
Nielsen Norman Group
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
NIELSEN-RECOGNITIONRecognition Rather Than RecallVisible options, labels, histories, defaults, and applied filter state. Practice
Use for
Visible options, labels, histories, defaults, and applied filter state.
Reference as
Interfaces should reduce memory burden by making relevant options, state, and prior information visible or readily retrievable.
Best future application
Persistent filters, labeled icons, recent items, and visible current scope.
Publisher
Nielsen Norman Group
Host
Nielsen Norman Group
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
NNG-STATUSVisibility of System StatusLoading, saving, filtering, refresh time, completion, and system feedback. Practice
Use for
Loading, saving, filtering, refresh time, completion, and system feedback.
Reference as
NN/g recommends timely, understandable feedback that communicates the current state of the system.
Best future application
AI generation, data refreshes, filter result counts, and long-running operations.
Publisher
Nielsen Norman Group
Host
Nielsen Norman Group
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
NNG-PROGRESSIVE-DISCLOSUREProgressive DisclosureShowing essential functions first while retaining access to advanced or secondary detail. Practice
Use for
Showing essential functions first while retaining access to advanced or secondary detail.
Reference as
Progressive disclosure can reduce initial complexity when hidden content is secondary and its availability remains discoverable.
Boundary
It should not hide primary findings, required controls, or evidence necessary for comparison.
Publisher
Nielsen Norman Group
Host
Nielsen Norman Group
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
NNG-CARD-LISTCard View Versus List ViewChoosing among cards, compact lists, and comparison structures. Practice
Use for
Choosing among cards, compact lists, and comparison structures.
Reference as
Cards support browsing distinct objects, while lists and tables generally support denser scanning and comparison.
Best future application
Avoiding card-only interfaces for repeated, comparable data.
Publisher
Nielsen Norman Group
Host
Nielsen Norman Group
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
NNG-CONTENT-DISPERSIONContent DispersionExcessive whitespace, mobile layouts stretched onto desktop, and information fragmentation. Practice
Use for
Excessive whitespace, mobile layouts stretched onto desktop, and information fragmentation.
Reference as
NN/g uses content dispersion to describe layouts in which related information is spread so widely that understanding and comparison require unnecessary navigation or memory.
Publisher
Nielsen Norman Group
Host
Nielsen Norman Group
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
WIEDENBECK-1999The Use of Icons and Labels in an End User Application ProgramIcons alone versus labels and icon-plus-label interfaces. Primary
Use for
Icons alone versus labels and icon-plus-label interfaces.
Reference as
Wiedenbeck found performance and learning differences among icon-only, label-only, and icon-plus-label conditions, with text labels materially supporting initial use.
Boundary
Do not generalize the result into a claim that every conventional icon always requires visible text in every context.
Creator / author
Susan Wiedenbeck
Host
Taylor & Francis Online
Origin
human-authored-primary-research
Attribution status
verified
Open source
FITTS-1954The Information Capacity of the Human Motor System in Controlling the Amplitude of MovementPointer-target size, distance, acquisition time, and placement. Primary
Use for
Pointer-target size, distance, acquisition time, and placement.
Reference as
Fitts’s work models target-acquisition difficulty as a relationship between distance and target width.
Best future application
Mobile controls, icon buttons, frequent actions, and avoiding small targets.
Boundary
Do not reduce Fitts’s law to “make every element as large as possible.”
Creator / author
Paul M. Fitts
Host
lri.fr
Origin
human-authored-primary-research
Attribution status
verified
Open source

Narrative & memorability6 sources

SEGEL-HEER-2010Narrative Visualization: Telling Stories with DataAuthor-driven versus reader-driven presentation, narrative genres, annotations, and guided exploration. PrimaryFramework
Use for
Author-driven versus reader-driven presentation, narrative genres, annotations, and guided exploration.
Reference as
Segel and Heer describe narrative visualization as a balance between guided communication and reader-controlled exploration.
Best future application
Briefings that state a finding first and then permit evidence inspection.
Creator / author
Edward Segel, Jeffrey Heer
Host
University of Washington
Origin
human-authored-primary-research
Attribution status
verified
Open source
HEER-ROBERTSON-2007Animated Transitions in Statistical Data GraphicsAnimated state transitions, object constancy, filtering, reordering, and changes in graphical representation. Primary
Use for
Animated state transitions, object constancy, filtering, reordering, and changes in graphical representation.
Reference as
Heer and Robertson found that carefully designed animated transitions can help viewers track changes between visualization states.
Boundary
Do not say animation is always better. It can impede exact comparison and accessibility.
Creator / author
Jeffrey Heer, George Robertson
Host
University of Washington
Origin
human-authored-primary-research
Attribution status
verified
Open source
BORKIN-2013What Makes a Visualization Memorable?Recognition, memorability, titles, visual distinctiveness, and imagery. Primary
Use for
Recognition, memorability, titles, visual distinctiveness, and imagery.
Reference as
Borkin and colleagues found systematic differences in visualization memorability and identified characteristics associated with stronger recognition.
Best future application
Qualifying extreme interpretations of minimalist design.
Creator / author
Michelle A. Borkin et al.
Host
MIT
Origin
human-authored-primary-research
Attribution status
verified
Open source
BORKIN-2015Beyond Memorability: Visualization Recognition and RecallWhat viewers remember from visualizations, not merely whether they recognize having seen them. Primary
Use for
What viewers remember from visualizations, not merely whether they recognize having seen them.
Reference as
Later Borkin research investigated which visualization elements viewers recognize and recall over time.
Best future application
Editorial explainers, executive communication, and durable visual storytelling.
Creator / author
Michelle A. Borkin et al.
Host
Harvard University
Origin
human-authored-primary-research
Attribution status
verified
Open source
BORGO-2012An Empirical Study on Using Visual Embellishments in VisualizationEffects of meaningful embellishment on comprehension and memory. Primary
Use for
Effects of meaningful embellishment on comprehension and memory.
Reference as
Borgo and colleagues found that some forms of meaningful visual embellishment can support memory without necessarily reducing comprehension.
Boundary
This does not justify arbitrary decoration or data distortion.
Creator / author
Rita Borgo et al.
Host
U.S. National Library of Medicine
Origin
human-authored-primary-research
Attribution status
verified
Open source
ELLIPSIS-ANNOTATIONAuthoring Narrative Visualizations with EllipsisAnnotations as first-class parts of narrative visualization. PrimaryPractice
Use for
Annotations as first-class parts of narrative visualization.
Reference as
Narrative visualization systems can treat text, arrows, highlights, and graphical annotations as explicit evidence-guidance elements.
Best future application
Directly annotating deployments, threshold crossings, and major findings.
Creator / author
Jessica Hullman et al.
Host
University of Washington
Origin
human-authored-primary-research
Attribution status
verified
Open source

Color theory & palettes10 sources

COLORBREWERColorBrewer 2Choosing palette families that match data structure. FrameworkPractice
Use for
Choosing palette families that match data structure.
Reference as
ColorBrewer distinguishes sequential palettes for ordered magnitude, diverging palettes for deviations around a midpoint, and qualitative palettes for unordered categories.
Best future application
Maps, heatmaps, risk scales, variance displays, and category colors.
Detailed guidance
Sequential, Diverging, and Qualitative Schemes
Creator / author
Cynthia A. Brewer, Mark Harrower
Publisher
ColorBrewer / The Pennsylvania State University
Host
ColorBrewer
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
SCHLOSS-2018Color Inference in Visual CommunicationHow users infer mappings between colors and concepts. PrimaryFramework
Use for
How users infer mappings between colors and concepts.
Reference as
Schloss and colleagues show that color meanings are shaped by learned concept associations and contextual expectations.
Best future application
Status semantics, category assignments, legends, and culturally sensitive color choices.
Boundary
Do not treat associations such as “blue means trust” as universal psychological laws.
Creator / author
Karen B. Schloss et al.
Host
U.S. National Library of Medicine
Origin
human-authored-primary-research
Attribution status
verified
Open source
SCHLOSS-2024Color Semantics in Human CognitionCurrent synthesis of color-concept associations, semantic inference, and lightness–magnitude expectations. Review
Use for
Current synthesis of color-concept associations, semantic inference, and lightness–magnitude expectations.
Reference as
Current color-semantics research indicates that color mappings can support interpretation when they align with learned and contextually relevant expectations.
Best future application
Semantic-token design and data-color mapping.
Creator / author
Karen B. Schloss
Host
U.S. National Science Foundation
Origin
human-authored-research-review
Attribution status
verified
Open source
SEMANTIC-COLOR-2013Selecting Semantically Resonant Colors for Data VisualizationCategory-color mappings such as blue for oceans or yellow for bananas. Primary
Use for
Category-color mappings such as blue for oceans or yellow for bananas.
Reference as
Lin and colleagues found that semantically resonant category-color assignments improved speed in chart-reading tasks compared with a standard palette.
Best future application
Category palettes where concepts have recognizable color associations.
Boundary
Semantic resonance must still be balanced with contrast and category discriminability.
Creator / author
Sharon Lin et al.
Host
University of Washington
Origin
human-authored-primary-research
Attribution status
verified
Open source
ELLIOT-MAIER-2014Color Psychology: Effects of Perceiving Color on Psychological FunctioningQualifying claims about color affecting behavior and cognition. Review
Use for
Qualifying claims about color affecting behavior and cognition.
Reference as
Reviews of color psychology report contextual effects but also substantial boundary conditions and unresolved questions.
Best future application
Rejecting simplistic statements such as “blue always creates trust” or “orange always improves conversion.”
Related open-access review
Color and Psychological Functioning
Creator / author
Andrew J. Elliot, Markus A. Maier
Host
U.S. National Library of Medicine
Origin
human-authored-research-review
Attribution status
verified
Open source
KOVESI-2015Good Colour Maps: How to Design ThemPerceptual uniformity, lightness progression, and problems with rainbow color scales. FrameworkPractice
Use for
Perceptual uniformity, lightness progression, and problems with rainbow color scales.
Reference as
Kovesi argues for color maps whose perceived progression more consistently follows the underlying numeric progression.
Best future application
Sequential heatmaps, scientific data, risk intensity, and avoiding rainbow scales.
Creator / author
Peter Kovesi
Host
arXiv
Origin
human-authored-framework-or-book
Attribution status
verified
Open source
VIRIDISIntroduction to the Viridis Color MapsAn implementation precedent for perceptually ordered, color-vision-aware scales. Practice
Use for
An implementation precedent for perceptually ordered, color-vision-aware scales.
Reference as
Viridis provides a practical family of continuous palettes designed to remain perceptually ordered and usable under grayscale and common color-vision deficiencies.
Boundary
Cite Kovesi or primary color-map research for theory; cite Viridis for implementation precedent.
Publisher
CRAN
Host
CRAN
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
CIVIDISOptimizing Colormaps with Consideration for Color-Vision DeficiencyThe Cividis palette and color-vision-aware continuous scale construction. PrimaryPractice
Use for
The Cividis palette and color-vision-aware continuous scale construction.
Reference as
Cividis was developed to provide a perceptually appropriate continuous scale with improved accessibility for common color-vision deficiencies.
Best future application
Scientific or operational heatmaps requiring continuous quantitative color.
Creator / author
Jamie R. Nuñez et al.
Host
arXiv
Origin
human-authored-primary-research
Attribution status
verified
Open source
QUANT-COLORMAPS-2018An Empirical Assessment of Quantitative ColormapsEmpirical comparison of quantitative color scales. Primary
Use for
Empirical comparison of quantitative color scales.
Reference as
Empirical color-map research shows that quantitative interpretation depends on perceptual ordering, discrimination, and task characteristics.
Best future application
Selecting continuous palettes based on performance rather than appearance alone.
Creator / author
Yang Liu, Jeffrey Heer
Host
University of Washington
Origin
human-authored-primary-research
Attribution status
verified
Open source
CATEGORICAL-COLOR-2023The Effects of Color Palette and Category Count on Multiclass ScatterplotsCategory count, palette discriminability, and interpretation accuracy. Primary
Use for
Category count, palette discriminability, and interpretation accuracy.
Reference as
Categorical palette effectiveness declines as category count and discrimination demands increase.
Best future application
Limiting simultaneous series, using direct labels, filtering, shapes, or small multiples.
Host
arXiv
Origin
human-authored-primary-research
Attribution status
pending-author-verification
Open source

Accessibility & contrast16 sources

WCAG22How to Meet WCAG 2.2: Quick ReferenceCurrent WCAG 2.2 success criteria, levels, techniques, and failures. Standard
Use for
Current WCAG 2.2 success criteria, levels, techniques, and failures.
Reference as
“WCAG 2.2 Level AA requires…”
Best future application
Accessibility acceptance criteria, automated testing, and design-system gates.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG22-UNDERSTANDINGUnderstanding WCAG 2.2Intent, examples, benefits, techniques, and failure conditions. StandardPractice
Use for
Intent, examples, benefits, techniques, and failure conditions.
Reference as
“W3C’s Understanding document explains that…”
Boundary
For contractual or legal language, cite the underlying success criterion as the requirement.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-1.4.1Understanding 1.4.1: Use of ColorProhibiting color as the only means of communicating information, actions, responses, or distinctions. Standard
Use for
Prohibiting color as the only means of communicating information, actions, responses, or distinctions.
Reference as
WCAG 2.2 SC 1.4.1 requires that color not be the only visual means used to communicate meaningful information.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-1.4.3Understanding 1.4.3: Contrast MinimumMinimum text contrast. Standard
Use for
Minimum text contrast.
Reference as
WCAG 2.2 Level AA requires at least 4.5:1 for normal text and 3:1 for large text, subject to defined exceptions.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-1.4.6Contrast EnhancedAAA text contrast. Standard
Use for
AAA text contrast.
Reference as
WCAG 2.2 Level AAA requires 7:1 for normal text and 4.5:1 for large text, subject to defined exceptions.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-1.4.11Understanding 1.4.11: Non-Text ContrastMeaningful icons, control boundaries, graphical objects, and interactive states. Standard
Use for
Meaningful icons, control boundaries, graphical objects, and interactive states.
Reference as
WCAG 2.2 Level AA requires visual information needed to identify UI components and states to have at least 3:1 contrast against adjacent colors.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-2.4.6Understanding Headings and LabelsDescriptive headings and labels. Standard
Use for
Descriptive headings and labels.
Reference as
WCAG requires headings and labels to describe their topic or purpose.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
W3C-HEADINGSHeadings That Reflect Page OrganizationSemantic heading hierarchy. Practice
Use for
Semantic heading hierarchy.
Reference as
W3C recommends nested headings that reflect the content hierarchy rather than headings chosen only for appearance.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
WCAG-1.4.10Understanding ReflowResponsive presentation at an equivalent width of 320 CSS pixels. Standard
Use for
Responsive presentation at an equivalent width of 320 CSS pixels.
Reference as
WCAG requires content to reflow without loss of information or functionality, except where two-dimensional layout is essential.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-1.4.12Understanding Text SpacingSurviving user-adjusted line, paragraph, word, and character spacing. Standard
Use for
Surviving user-adjusted line, paragraph, word, and character spacing.
Reference as
WCAG requires content to remain usable when users override specified text-spacing properties.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-2.4.11Focus Not Obscured: MinimumSticky headers, overlays, scroll containers, and keyboard focus. Standard
Use for
Sticky headers, overlays, scroll containers, and keyboard focus.
Reference as
WCAG 2.2 Level AA requires that a focused component not be entirely hidden by author-created content.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-2.4.13Focus AppearanceEnhanced focus size and contrast. Standard
Use for
Enhanced focus size and contrast.
Reference as
WCAG 2.2 SC 2.4.13 defines enhanced focus-appearance requirements at Level AAA.
Important
Do not identify SC 2.4.13 as an AA requirement.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-2.5.8Target Size: MinimumMinimum pointer-target sizing or sufficient target spacing. Standard
Use for
Minimum pointer-target sizing or sufficient target spacing.
Reference as
WCAG 2.2 Level AA generally requires pointer targets to be at least 24×24 CSS pixels or satisfy a defined spacing or exception condition.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG-1.4.13Content on Hover or FocusTooltips, popovers, and supplemental hover/focus content. Standard
Use for
Tooltips, popovers, and supplemental hover/focus content.
Reference as
WCAG requires qualifying hover or focus content to be dismissible, hoverable, and persistent under specified conditions.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
W3C-BUTTON-NAMEButton Has an Accessible NameIcon buttons and programmatic labeling. Standard
Use for
Icon buttons and programmatic labeling.
Reference as
Interactive buttons require a meaningful accessible name that describes their function.
Best future application
aria-label , visible labels, icon buttons, and automated accessibility tests.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
WCAG3-DRAFTWCAG 3.0 Working DraftMonitoring future accessibility models, outcome-based requirements, and evolving contrast methods. Draft
Use for
Monitoring future accessibility models, outcome-based requirements, and evolving contrast methods.
Reference as
“The March 3, 2026 WCAG 3 working draft explores…”
Never write
“WCAG 3 currently requires…”
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
unknown
Attribution status
publisher-only
Open source

Color vision & polarity5 sources

CVD-PREVALENCEWorldwide Prevalence of Red-Green Color DeficiencyPrevalence estimates and population variation. PrimaryReview
Use for
Prevalence estimates and population variation.
Reference as
Congenital red-green color-vision deficiency is considerably more prevalent among males, though prevalence varies by ancestry and population.
Boundary
Do not present a single percentage as universally applicable.
Host
U.S. National Library of Medicine
Origin
human-authored-primary-research
Attribution status
pending-author-verification
Open source
CVD-GLOBAL-REVIEWColor-Vision Deficiency: A Global PerspectiveBroader contemporary context, acquired deficiencies, prevalence, and practical implications. Review
Use for
Broader contemporary context, acquired deficiencies, prevalence, and practical implications.
Reference as
Color accessibility must consider both congenital and acquired color-vision limitations.
Best future application
Moving beyond the phrase “colorblind safe.”
Host
U.S. National Library of Medicine
Origin
human-authored-research-review
Attribution status
pending-author-verification
Open source
POLARITY-2009Text–Background Polarity Affects PerformancePositive-polarity versus negative-polarity reading performance. Primary
Use for
Positive-polarity versus negative-polarity reading performance.
Reference as
Controlled studies have found performance advantages for dark text on light backgrounds in some reading and proofreading tasks.
Boundary
Do not conclude that light mode is universally more accessible for every user and condition.
Creator / author
Axel Buchner, Nina Baumgartner
Host
U.S. National Library of Medicine
Origin
human-authored-primary-research
Attribution status
verified
Open source
POLARITY-2014Positive Display Polarity Is Particularly Advantageous for Small Character SizesCharacter size and polarity interaction. Primary
Use for
Character size and polarity interaction.
Reference as
Positive-polarity advantages can be especially relevant when text is small.
Best future application
Dense tables, metadata, mobile interfaces, and long-form reading.
Creator / author
Cornelia Piepenbrock, Susanne Mayr, Axel Buchner
Host
SAGE Journals
Origin
human-authored-primary-research
Attribution status
verified
Open source
DARKMODE-2024Dark Mode in Data Visualization: Individual DifferencesMeasured performance, individual preference, and variation across users. Primary
Use for
Measured performance, individual preference, and variation across users.
Reference as
Recent visualization research found that polarity effects differ among users and that stated preference does not always match measured performance.
Best future application
Supporting both light and dark appearances rather than declaring one universally superior.
Host
arXiv
Origin
human-authored-primary-research
Attribution status
pending-author-verification
Open source

CSS color & preference specifications4 sources

CSS-COLOR-4CSS Color Module Level 4Lab, LCH, Oklab, OkLCh, alpha composition, wide-gamut spaces, and color interpolation. Standard
Use for
Lab, LCH, Oklab, OkLCh, alpha composition, wide-gamut spaces, and color interpolation.
Reference as
CSS Color 4 defines modern perceptual color-space functions including lab() , lch() , oklab() , and oklch() .
Best future application
Building perceptually controlled color ramps and theme tokens.
Boundary
A perceptual color space does not itself guarantee WCAG contrast or color-vision accessibility.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
CSS-COLOR-5CSS Color Module Level 5color-mix() , relative color syntax, light-dark() , and evolving contrast functions. DraftStandard
Use for
color-mix() , relative color syntax, light-dark() , and evolving contrast functions.
Reference as
CSS Color 5 defines emerging color-modification and adaptation functions.
Boundary
Check browser support and specification status before treating a feature as a production baseline.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-draft-specification
Attribution status
publisher-only
Open source
MEDIA-QUERIES-5Media Queries Level 5prefers-color-scheme , prefers-contrast , forced-colors , and prefers-reduced-transparency . Standard
Use for
prefers-color-scheme , prefers-contrast , forced-colors , and prefers-reduced-transparency .
Reference as
Media Queries Level 5 exposes user and device preferences that allow interfaces to adapt color and presentation.
Important
Do not use an unqualified prefers-contrast query when the distinction between more and less matters.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source
CSS-COLOR-ADJUSTCSS Color Adjustment Module Level 1color-scheme , forced-color adaptation, and user-agent color adjustment. Standard
Use for
color-scheme , forced-color adaptation, and user-agent color adjustment.
Reference as
CSS Color Adjustment defines how authored colors interact with user-preferred schemes and forced-color environments.
Best future application
High-contrast themes and Windows forced-colors support.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source

Design-system precedents10 sources

FLUENT-TOKENSFluent 2 Design TokensPrimitive, alias, and component-token architecture. Practice
Use for
Primitive, alias, and component-token architecture.
Reference as
Fluent separates raw palette values from semantic and component-specific roles.
Best future application
Theme remapping, interaction states, and eliminating hardcoded colors.
Publisher
Microsoft
Host
Microsoft Fluent
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
FLUENT-COLORFluent 2 ColorNeutral, brand, status, and shared color roles. Practice
Use for
Neutral, brand, status, and shared color roles.
Reference as
Fluent uses neutral, brand, status, and generic color families rather than relying only on primary and secondary colors.
Publisher
Microsoft
Host
Microsoft Fluent
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
FLUENT-ACCESSIBILITYFluent 2 AccessibilityApplied contrast, keyboard, focus, touch, and accessibility guidance. Practice
Use for
Applied contrast, keyboard, focus, touch, and accessibility guidance.
Reference as
Fluent applies WCAG-oriented contrast expectations to text, essential icons, and UI components.
Publisher
Microsoft
Host
Microsoft Fluent
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
FLUENT-ICONSFluent 2 IconographyIcon geometry, sizing, consistency, and filled versus regular states. Practice
Use for
Icon geometry, sizing, consistency, and filled versus regular states.
Reference as
Fluent uses a consistent icon grammar and provides state-compatible icon variants.
Best future application
Standardizing icon weight, bounding boxes, and selected states.
Publisher
Microsoft
Host
Microsoft Fluent
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
ATLASSIAN-COLORAtlassian Design System: ColorSemantic color roles, emphasis levels, interaction states, and warning foregrounds. Practice
Use for
Semantic color roles, emphasis levels, interaction states, and warning foregrounds.
Reference as
Atlassian separates semantic colors from interchangeable accent colors and defines role-specific foregrounds for bold status surfaces.
Best future application
Warning contrast, semantic tokens, and avoiding arbitrary category color meanings.
Publisher
Atlassian
Host
Atlassian
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
USWDS-COLORUSWDS Color TokensAccessible token grades and predictable contrast relationships. Practice
Use for
Accessible token grades and predictable contrast relationships.
Reference as
USWDS organizes colors into graded token families designed to support repeatable contrast selection.
Best future application
Enterprise contrast matrices and government-grade accessibility.
Publisher
U.S. Web Design System
Host
U.S. Web Design System
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
USWDS-ACCESSIBILITYUSWDS AccessibilityApplied accessibility governance and component expectations. Practice
Use for
Applied accessibility governance and component expectations.
Reference as
USWDS treats accessibility as a system-level design and implementation responsibility rather than a final audit step.
Publisher
U.S. Web Design System
Host
U.S. Web Design System
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
APPLE-COLORApple HIG: ColorAdaptive color, hierarchy, semantic color, light/dark appearance, and system colors. Practice
Use for
Adaptive color, hierarchy, semantic color, light/dark appearance, and system colors.
Reference as
Apple recommends adaptive semantic colors and cautions against using color as the sole means of communication.
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
APPLE-ACCESSIBILITYApple HIG: AccessibilityRedundant encoding, text, contrast, motion, touch, and assistive technology. Practice
Use for
Redundant encoding, text, contrast, motion, touch, and assistive technology.
Reference as
Apple recommends reinforcing color with labels, icons, shapes, or other distinguishable cues.
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source
APPLE-BUTTONSApple HIG: ButtonsButton hierarchy, labeling, and practical touch-target sizing. Practice
Use for
Button hierarchy, labeling, and practical touch-target sizing.
Reference as
Apple recommends comfortably sized, clearly labeled controls and commonly uses a 44-point interaction target as a platform guideline.
Boundary
Distinguish Apple’s platform guidance from WCAG’s normative 24-CSS-pixel minimum.
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
publisher-only
Open source

Ethical interaction design1 sources

DARK-PATTERNS-2019Dark Patterns at Scale: Findings from a Crawl of 11K Shopping WebsitesDark-pattern taxonomy, manipulation, coercion, hidden costs, obstruction, urgency, and deceptive defaults. Primary
Use for
Dark-pattern taxonomy, manipulation, coercion, hidden costs, obstruction, urgency, and deceptive defaults.
Reference as
Mathur and colleagues identified 1,818 dark-pattern instances across approximately 11,000 shopping websites and classified them into 15 types and seven broader categories.
Best future application
Consent, cancellation, sponsored content, destructive actions, subscription flows, and equivalent-choice presentation.
Boundary
This paper documents a large sample of shopping sites; do not treat its prevalence estimate as universal across all digital products.
Creator / author
Arunesh Mathur et al.
Host
University of Maryland
Origin
human-authored-primary-research
Attribution status
verified
Open source

Knowledge architecture & provenance8 sources

OKF-SPECOpen Knowledge Format (OKF) Version 0.1 — DraftPortable knowledge bundles, concept files, frontmatter, links, indexes, logs, citations, conformance, and versioning.DraftStandard
Use for
Portable knowledge bundles, concept files, frontmatter, links, indexes, logs, citations, conformance, and versioning.
Reference as
The OKF draft defines a minimal human- and agent-readable Markdown/YAML exchange envelope with one concept per file and permissive producer-defined extensions.
Best future application
Canonical authoring layer and portable knowledge exchange.
Boundary
OKF is intentionally minimal and does not define a complete research ontology, schema registry, query system, or validation implementation.
Creator / author
Google Cloud Data Cloud team
Publisher
Google Cloud / GoogleCloudPlatform
Host
GitHub
Origin
organization-authored-draft-specification
Attribution status
verified
Open source ↗
OKF-SKILLSokf-skills: OKF authoring, maintenance, validation, and visualization toolkitAgent-assisted OKF authoring, deterministic validation, graph visualization, deep links, portable skill distribution, and knowledge-as-code workflows.Practice
Use for
Agent-assisted OKF authoring, deterministic validation, graph visualization, deep links, portable skill distribution, and knowledge-as-code workflows.
Reference as
The community implementation demonstrates how OKF bundles can be authored by agents, checked deterministically, visualized as graphs, and maintained as versioned knowledge.
Best future application
Operationalizing OKF with agent skills and CI validation.
Boundary
Community implementation behavior is a production precedent rather than part of the normative OKF draft.
Creator / author
Marco Boffo (scaccogatto)
Publisher
scaccogatto
Host
GitHub
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
OKF-SKILLS-SAMPLEokf-skills sample bundleA linked OKF example with services, datasets, decisions, runbooks, metrics, index navigation, and graph visualization.Practice
Use for
A linked OKF example with services, datasets, decisions, runbooks, metrics, index navigation, and graph visualization.
Reference as
Different concept types can coexist in one linked bundle and be rendered into a shareable self-contained explorer.
Best future application
Bundle organization and concept-type examples.
Creator / author
Marco Boffo (scaccogatto)
Publisher
scaccogatto
Host
GitHub
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
OKF-SKILLS-SELFokf-skills documented in its own OKF bundleSelf-documenting repository with skills, components, reference specifications, and architecture decisions.Practice
Use for
Self-documenting repository with skills, components, reference specifications, and architecture decisions.
Reference as
Dogfooding creates a feedback loop in which the knowledge system documents and validates its own design.
Best future application
Self-documentation and architecture lineage.
Creator / author
Marco Boffo (scaccogatto)
Publisher
scaccogatto
Host
GitHub
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
W3C-PROVPROV-O: The PROV OntologyRepresenting entities, activities, people, organizations, and software agents involved in derivation and attribution.Standard
Use for
Representing entities, activities, people, organizations, and software agents involved in derivation and attribution.
Reference as
PROV-O provides a vocabulary for distinguishing accountable agents, software-agent activities, source entities, and generated derivatives.
Best future application
Internal provenance graph and contribution records.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source ↗
JSON-LD-11JSON-LD 1.1Representing linked data in JSON while preserving machine-readable identifiers and relationships.Standard
Use for
Representing linked data in JSON while preserving machine-readable identifiers and relationships.
Reference as
JSON-LD 1.1 defines a JSON-based serialization for linked data and is suitable for compiling typed research relationships into a portable graph.
Best future application
Internal research graph and interoperable exports.
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium
Origin
organization-authored-standard-or-specification
Attribution status
publisher-only
Open source ↗
SCHEMA-CREATIVEWORKSchema.org CreativeWorkPublic structured-data fields for creator, contributor, citation, version, dates, and distributions.StandardPractice
Use for
Public structured-data fields for creator, contributor, citation, version, dates, and distributions.
Reference as
Schema.org CreativeWork and Dataset types provide a constrained public vocabulary for describing the visible research artifact and its distributions.
Best future application
Public/AEO structured data that accurately reflects visible content.
Boundary
Schema.org should describe the public artifact, not replace the richer internal provenance and research graph.
Publisher
Schema.org Community Group
Host
Schema.org
Origin
organization-authored-vocabulary
Attribution status
publisher-only
Open source ↗
JESSE-OKF-VIDEOOKF usage example and AI-assisted research workflow (video)First-party example supplied by the research owner demonstrating how OKF can be applied and communicated.Practice
Use for
First-party example supplied by the research owner demonstrating how OKF can be applied and communicated.
Reference as
Track the originating human creator and disclose AI assistance as separate provenance fields.
Best future application
Authorship, ownership, and AI-assistance example.
Creator / author
Jesse Graupmann
Publisher
Jesse Graupmann
Host
YouTube
Origin
human-directed-ai-assisted
Attribution status
verified
Open source ↗

Native HTML & forms12 sources

HTML-POPOVERHTML Standard — The popover attributePopover modes, top-layer presentation, light dismissal, focus restoration, declarative targets, and popover lifecycle events.Standard
Use for
Popover modes, top-layer presentation, light dismissal, focus restoration, declarative targets, and popover lifecycle events.
Reference as
The HTML Living Standard defines auto, manual, and hint popover modes with distinct dismissal and stacking behavior.
Best application
Native contextual surfaces and progressive enhancement.
Boundary
Popover provides presentation lifecycle behavior; complex menu keyboard behavior and accessible semantics may still require author implementation.
Creator / author
Not individually asserted
Publisher
WHATWG
Host
WHATWG
Origin
organization-authored-living-standard
Attribution status
verified
Open source ↗
HTML-DIALOGHTML Standard — The dialog elementNative dialogs, modal presentation, top-layer behavior, close requests, return values, and declarative dismissal.Standard
Use for
Native dialogs, modal presentation, top-layer behavior, close requests, return values, and declarative dismissal.
Reference as
The HTML Living Standard defines dialog as the native primitive for modal and nonmodal dialog surfaces.
Best application
Scoped tasks, confirmations, and modal focus behavior.
Boundary
Native dialog does not determine whether modality is appropriate or supply complete product-level focus and data-loss policy.
Creator / author
Not individually asserted
Publisher
WHATWG
Host
WHATWG
Origin
organization-authored-living-standard
Attribution status
verified
Open source ↗
HTML-DETAILSHTML Standard — The details and summary elementsNative disclosure behavior, summary labeling, open state, and named mutually exclusive details groups.Standard
Use for
Native disclosure behavior, summary labeling, open state, and named mutually exclusive details groups.
Reference as
The HTML Living Standard defines details/summary as a native disclosure primitive rather than a general replacement for menus or tabs.
Best application
Optional explanations, advanced detail, and secondary evidence.
Boundary
Exclusive accordion behavior can obstruct comparison when users need several sections open.
Creator / author
Not individually asserted
Publisher
WHATWG
Host
WHATWG
Origin
organization-authored-living-standard
Attribution status
verified
Open source ↗
HTML-FORM-INFRAHTML Standard — Form control infrastructureForm ownership, submission, validation, labels, disabled state, reset, autofill, and the form control lifecycle.Standard
Use for
Form ownership, submission, validation, labels, disabled state, reset, autofill, and the form control lifecycle.
Reference as
The HTML Living Standard defines a broad form lifecycle that custom controls must deliberately reproduce or inherit.
Best application
Native-first form architecture and custom-control acceptance criteria.
Creator / author
Not individually asserted
Publisher
WHATWG
Host
WHATWG
Origin
organization-authored-living-standard
Attribution status
verified
Open source ↗
HTML-COMMANDSHTML Standard — button commands and command targetsDeclarative button commands, command targets, dialog actions, popover invocation, and reduced JavaScript dependency.Standard
Use for
Declarative button commands, command targets, dialog actions, popover invocation, and reduced JavaScript dependency.
Reference as
The HTML Living Standard defines command and commandfor relationships that can declaratively invoke supported UI actions.
Best application
Progressively enhanced dialog and popover controls.
Boundary
Support and behavior must be tested against the product browser matrix before becoming a baseline dependency.
Creator / author
Not individually asserted
Publisher
WHATWG
Host
WHATWG
Origin
organization-authored-living-standard
Attribution status
verified
Open source ↗
WEBDEV-FORM-ASSOCIATEDMore capable form controlsForm-associated custom elements, ElementInternals, formdata, custom validation, reset, label association, and feature detection.Practice
Use for
Form-associated custom elements, ElementInternals, formdata, custom validation, reset, label association, and feature detection.
Reference as
Google Chrome Developers explains that custom controls inherit substantial lifecycle obligations and can use form-associated custom elements to recover some native behavior.
Best application
Advanced custom-control governance and progressive enhancement.
Boundary
Form-associated custom elements are an advanced mechanism and do not eliminate accessibility and cross-browser testing requirements.
Creator / author
Arthur Evans
Publisher
Google Chrome Developers
Host
Google Chrome Developers
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
W3C-FORMSWAI Forms TutorialAccessible form architecture, labels, grouping, instructions, validation, notifications, and multi-step flows.Practice
Use for
Accessible form architecture, labels, grouping, instructions, validation, notifications, and multi-step flows.
Reference as
W3C recommends simple, short forms that request only necessary information and use native relationships wherever possible.
Best application
Form doctrine and accessibility review.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
W3C-FORM-LABELSWAI Forms — Labeling controlsPersistent visible labels, explicit label association, control naming, enlarged activation areas, and mobile labeling.Practice
Use for
Persistent visible labels, explicit label association, control naming, enlarged activation areas, and mobile labeling.
Reference as
W3C recommends descriptive labels associated with form controls, ordinarily through the native label element.
Best application
Field anatomy and accessible-name validation.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
W3C-FORM-GROUPINGWAI Forms — Grouping controlsFieldset/legend, optgroup, visual and programmatic grouping, and manageable form scope.Practice
Use for
Fieldset/legend, optgroup, visual and programmatic grouping, and manageable form scope.
Reference as
W3C recommends grouping related controls visually and programmatically so users can process smaller meaningful units.
Best application
Field groups, radio groups, checkbox groups, and related data sections.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
W3C-FORM-INSTRUCTIONSWAI Forms — Form instructionsRequired/optional state, formats, units, overall instructions, aria-describedby, and placeholder limitations.Practice
Use for
Required/optional state, formats, units, overall instructions, aria-describedby, and placeholder limitations.
Reference as
W3C recommends stating constraints and instructions in forms in a way that remains available to assistive technologies.
Best application
Constraint communication before validation.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
W3C-FORM-VALIDATIONWAI Forms — Validating inputNative constraint validation, forgiving input formats, client/server validation, confirmation, and undo.Practice
Use for
Native constraint validation, forgiving input formats, client/server validation, confirmation, and undo.
Reference as
W3C recommends accessible client-side guidance while retaining server-side validation and recovery controls.
Best application
Validation policy, error prevention, and consequential transactions.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
W3C-FORM-NOTIFICATIONSWAI Forms — User notificationForm-level feedback, inline errors, success confirmation, error lists, and timing.Practice
Use for
Form-level feedback, inline errors, success confirmation, error lists, and timing.
Reference as
W3C recommends concise overall and field-level notifications that explain task results and correction paths.
Best application
Error summaries, save confirmation, and form completion feedback.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗

Interactive surfaces & ARIA8 sources

APG-INTROARIA Authoring Practices Guide — IntroductionScope and limitations of APG patterns, semantic HTML preference, assistive-technology testing, and production caveats.Practice
Use for
Scope and limitations of APG patterns, semantic HTML preference, assistive-technology testing, and production caveats.
Reference as
W3C describes APG examples as illustrative patterns that require real browser and assistive-technology testing before production use.
Best application
Governance for ARIA pattern adoption.
Boundary
APG is not a production component library or a replacement for testing.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APG-DISCLOSUREARIA APG — Disclosure patternShow/hide controls, aria-expanded, keyboard activation, and optional aria-controls.Practice
Use for
Show/hide controls, aria-expanded, keyboard activation, and optional aria-controls.
Reference as
The APG disclosure pattern describes a button that controls the visibility of one related content region.
Best application
Custom disclosure behavior when native details/summary is unsuitable.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APG-DIALOGARIA APG — Dialog modal patternModal focus containment, entry, labeling, Escape behavior, inert background, and focus restoration.Practice
Use for
Modal focus containment, entry, labeling, Escape behavior, inert background, and focus restoration.
Reference as
The APG modal-dialog pattern requires focus to enter and remain within the modal surface until it closes.
Best application
Dialog focus policy and keyboard testing.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APG-ALERTDIALOGARIA APG — Alert and message dialogsInterruptive modal messages that require an explicit user response.Practice
Use for
Interruptive modal messages that require an explicit user response.
Reference as
The APG alertdialog pattern distinguishes response-required critical interruption from nonmodal alert announcements.
Best application
Irreversible or high-consequence confirmation.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APG-ALERTARIA APG — Alert patternBrief important announcements that do not move focus, auto-dismiss cautions, and interruption frequency.Practice
Use for
Brief important announcements that do not move focus, auto-dismiss cautions, and interruption frequency.
Reference as
The APG alert pattern communicates important information without shifting keyboard focus or requiring a response.
Best application
Time-sensitive inline or global alerts.
Boundary
Frequent alerts and automatic disappearance can create accessibility and comprehension failures.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APG-MENU-BUTTONARIA APG — Menu button patternButtons that open action menus, aria-haspopup, aria-expanded, initial focus, and menu keyboard behavior.Practice
Use for
Buttons that open action menus, aria-haspopup, aria-expanded, initial focus, and menu keyboard behavior.
Reference as
The APG menu-button pattern is intended for a button that opens a menu of commands or choices with an application-style keyboard model.
Best application
Action menus and command overflow.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APG-MENUBARARIA APG — Menu and menubar patternApplication menu roles, roving focus, arrow-key navigation, menuitem roles, and submenus.Practice
Use for
Application menu roles, roving focus, arrow-key navigation, menuitem roles, and submenus.
Reference as
The APG menu/menubar pattern defines a specialized application-menu interaction model rather than a generic dropdown.
Best application
Desktop-style application commands and editors.
Boundary
The keyboard model is usually unnecessary for ordinary site navigation.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APG-DISCLOSURE-NAVARIA APG — Disclosure navigation menuWebsite navigation with links and disclosure buttons without applying application-menu roles.Practice
Use for
Website navigation with links and disclosure buttons without applying application-menu roles.
Reference as
W3C recommends disclosure-based navigation for most sites because ARIA menubar semantics introduce unnecessary complexity.
Best application
Expandable website and SPA navigation.
Creator / author
Not individually asserted
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗

Settings, notifications & platform guidance7 sources

APPLE-MENUSApple HIG — MenusFamiliar menu behavior, command organization, labeling, icons, separators, state, and platform expectations.Practice
Use for
Familiar menu behavior, command organization, labeling, icons, separators, state, and platform expectations.
Reference as
Apple recommends concise, familiar command menus that reflect current context and expected platform behavior.
Best application
Menu content hierarchy and labels.
Creator / author
Not individually asserted
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APPLE-POPOVERSApple HIG — PopoversSmall transient contextual tasks, warning avoidance, wide versus compact presentation, and detachable panels.Practice
Use for
Small transient contextual tasks, warning avoidance, wide versus compact presentation, and detachable panels.
Reference as
Apple recommends popovers for a small amount of related information or functionality and sheets/full-screen surfaces in compact layouts.
Best application
Responsive popover-to-sheet transformation.
Creator / author
Not individually asserted
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APPLE-CONTEXT-MENUSApple HIG — Context menusContext-relevant hidden commands, discoverability limits, item count, destructive placement, and visible-interface redundancy.Practice
Use for
Context-relevant hidden commands, discoverability limits, item count, destructive placement, and visible-interface redundancy.
Reference as
Apple recommends keeping context menus short and making important context-menu actions available in the main interface as well.
Best application
Expert accelerators and object-specific command surfaces.
Creator / author
Not individually asserted
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APPLE-SHEETSApple HIG — SheetsScoped contextual tasks, modal and nonmodal sheet behavior, compact presentation, and context retention.Practice
Use for
Scoped contextual tasks, modal and nonmodal sheet behavior, compact presentation, and context retention.
Reference as
Apple describes sheets as temporary surfaces for scoped tasks closely related to the parent context.
Best application
Mobile drawers, sheets, and responsive modal tasks.
Creator / author
Not individually asserted
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APPLE-ALERTSApple HIG — AlertsCritical actionable interruption, destructive confirmation, labels, button hierarchy, and avoidance of routine alerts.Practice
Use for
Critical actionable interruption, destructive confirmation, labels, button hierarchy, and avoidance of routine alerts.
Reference as
Apple recommends using alerts sparingly for essential actionable information, not routine or easily undoable actions.
Best application
Alert-dialog escalation and destructive workflows.
Creator / author
Not individually asserted
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APPLE-SETTINGSApple HIG — SettingsStable settings navigation, meaningful customization, defaults, active panes, and last-view restoration.Practice
Use for
Stable settings navigation, meaningful customization, defaults, active panes, and last-view restoration.
Reference as
Apple recommends settings experiences that remain stable, understandable, and focused on meaningful customization rather than repairing poor defaults.
Best application
Settings-page information architecture.
Creator / author
Not individually asserted
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
APPLE-NOTIFICATIONSApple HIG — Managing notificationsNotification interruption levels, permission context, user control, in-app management, and promotional boundaries.Practice
Use for
Notification interruption levels, permission context, user control, in-app management, and promotional boundaries.
Reference as
Apple organizes notifications by interruption level and recommends giving users explicit context and settings control.
Best application
Notification escalation, permission, and preference design.
Creator / author
Not individually asserted
Publisher
Apple
Host
Apple Developer
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗

Empirical forms & interruption research4 sources

FORM-USABILITY-2014Designing Usable Web Forms — Empirical Evaluation of Web Form Improvement GuidelinesControlled eye-tracking evaluation of combined web-form design guidelines on real company forms.Primary
Use for
Controlled eye-tracking evaluation of combined web-form design guidelines on real company forms.
Reference as
Seckler and colleagues found that optimized forms produced faster completion, fewer submission trials, fewer eye movements, and higher satisfaction.
Best application
Evidence-backed form layout and interaction guidance.
Boundary
The study evaluates a combined guideline package; individual rules should not be treated as universal thresholds.
Creator / author
Mirjam Seckler, Silvia Heinz, Javier A. Bargas-Avila, Klaus Opwis, Alexandre N. Tuch
Publisher
ACM
Host
Google Research
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
PRISEC-2021PriSEC: A Privacy Settings Enforcement ControllerSettings reachability, searchable centralized privacy controls, fine-grained option discovery, and enforcement.Primary
Use for
Settings reachability, searchable centralized privacy controls, fine-grained option discovery, and enforcement.
Reference as
Khandelwal and colleagues identify usability and reachability problems in privacy settings and demonstrate a searchable centralized controller.
Best application
Settings search, deep links, and contextual routing.
Creator / author
Rishabh Khandelwal, Thomas Linden, Hamza Harkous, Kassem Fawaz
Publisher
USENIX Association
Host
USENIX Association
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
CHROME-QUIET-PROMPTS-2021“Shhh…be Quiet!” Reducing Unwanted Notification Permission InterruptionsLarge-scale field experiments on quieter notification permission prompts and interruption reduction.Primary
Use for
Large-scale field experiments on quieter notification permission prompts and interruption reduction.
Reference as
Bilogrevic and colleagues found that a quieter permission UI reduced unnecessary prompt actions by up to 30% with less than a 5% effect on grant rates in their A/B test.
Best application
Interruption proportionality and contextual permission requests.
Creator / author
Igor Bilogrevic, Balazs Engedy, Judson L. Porter III, Nina Taft, Kamila Hasanbega, Andrew Paseltiner, Hwi Kyoung Lee, Edward Jung, Meggyn Watkins, PJ McLachlan, Jason James
Publisher
USENIX Association
Host
Google Research
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗
CHROME-QUIETING-2024Don’t Interrupt Me — On-Device Permission Prompt Quieting in ChromeContext-aware prompt quieting, on-device activation, large-scale telemetry, and user sentiment.Primary
Use for
Context-aware prompt quieting, on-device activation, large-scale telemetry, and user sentiment.
Reference as
Harbach and colleagues report that context-aware quieting was often perceived as helpful and achieved high precision and coverage in the studied deployment.
Best application
Adaptive interruption and permission-request governance.
Creator / author
Marian Harbach, Igor Bilogrevic, Enrico Bacis, Serena Chen, Ravjit Uppal, Andy Paicu, Elias Klim, Meggyn Watkins, Balazs Engedy
Publisher
NDSS Symposium
Host
Google Research
Origin
human-or-organization-authored-practice-guidance
Attribution status
verified
Open source ↗

ARIA specifications & accessibility mappings7 sources

WAI-ARIA-1.2Accessible Rich Internet Applications (WAI-ARIA) 1.2The normative ontology of ARIA roles, states, properties, required context, supported attributes, prohibited attributes, and author conformance.Standard
Use for
The normative ontology of ARIA roles, states, properties, required context, supported attributes, prohibited attributes, and author conformance.
Reference as
WAI-ARIA 1.2 defines the semantic contracts authors expose to accessibility APIs when native host-language semantics are insufficient.
Best application
Role/state/property validation and semantic component contracts.
Boundary
ARIA changes accessibility semantics; it does not automatically implement keyboard, focus, pointer, or visual behavior.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
WAI-ARIA-1.3Accessible Rich Internet Applications (WAI-ARIA) 1.3 Working DraftEmerging ARIA role and relationship requirements, including explicit accessibility-parent constraints and evolving states and properties.Draft
Use for
Emerging ARIA role and relationship requirements, including explicit accessibility-parent constraints and evolving states and properties.
Reference as
The current WAI-ARIA 1.3 working draft explores changes that may affect future authoring and validation rules.
Best application
Standards monitoring and forward-compatible schema design.
Boundary
This is a working draft, not the current conformance baseline.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
ARIA-IN-HTMLARIA in HTMLAllowed and prohibited ARIA roles and attributes on HTML elements, implicit semantics, and conformance rules.Standard
Use for
Allowed and prohibited ARIA roles and attributes on HTML elements, implicit semantics, and conformance rules.
Reference as
ARIA in HTML defines where authors may, should, or must not override native HTML semantics with ARIA.
Best application
Native-versus-ARIA decision tables and automated linting.
Boundary
A technically valid role override can still be a poor interaction design.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
ACCNAME-1.1Accessible Name and Description Computation 1.1The current Recommendation defining how browsers compute accessible names and descriptions exposed to assistive technologies.Standard
Use for
The current Recommendation defining how browsers compute accessible names and descriptions exposed to assistive technologies.
Reference as
AccName 1.1 defines the ordered computation that turns HTML and ARIA labeling relationships into flat accessible-name and description strings.
Best application
Accessible-name testing and debugging.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
ACCNAME-1.2Accessible Name and Description Computation 1.2 Working DraftThe evolving accessible-name and description algorithm, including aria-description and updated name-from rules.Draft
Use for
The evolving accessible-name and description algorithm, including aria-description and updated name-from rules.
Reference as
The AccName 1.2 working draft documents emerging computation behavior that may supersede AccName 1.1.
Best application
Standards monitoring and forward-compatible accessible-name tooling.
Boundary
Use AccName 1.1 and current browser behavior for conformance until 1.2 reaches Recommendation.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
HTML-AAM-1.0HTML Accessibility API Mappings 1.0 Working DraftHow browsers map HTML elements and attributes into platform accessibility APIs and derive accessible names and descriptions.Draft
Use for
How browsers map HTML elements and attributes into platform accessibility APIs and derive accessible names and descriptions.
Reference as
HTML-AAM documents the accessibility-tree semantics browsers expose for native HTML.
Best application
Accessibility-tree inspection and native-semantics debugging.
Boundary
This is an implementation-facing working draft and can change.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
CORE-AAM-1.2Core Accessibility API Mappings 1.2 Candidate Recommendation DraftHow user agents map ARIA semantics, states, properties, events, and focus into platform accessibility APIs.Draft
Use for
How user agents map ARIA semantics, states, properties, events, and focus into platform accessibility APIs.
Reference as
Core-AAM defines the cross-platform mapping layer between web semantics and operating-system accessibility APIs.
Best application
Interoperability analysis and browser/assistive-technology debugging.
Boundary
Candidate Recommendation Draft status is not equivalent to a final Recommendation.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗

ARIA authoring practices & patterns16 sources

APG-NAMESAPG — Providing Accessible Names and DescriptionsAccessible-name requirements, naming techniques by role, description precedence, visible-label preference, and naming anti-patterns.Practice
Use for
Accessible-name requirements, naming techniques by role, description precedence, visible-label preference, and naming anti-patterns.
Reference as
APG recommends concise, distinctive names and native HTML labeling techniques whenever they fit.
Best application
Buttons, fields, regions, dialogs, tables, figures, icons, and composite widgets.
Boundary
APG guidance is not a replacement for the normative AccName algorithm or actual browser testing.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-KEYBOARDAPG — Developing a Keyboard InterfaceTab sequence design, composite-widget navigation, roving tabindex, aria-activedescendant, disabled-control focusability, and shortcut conflicts.Practice
Use for
Tab sequence design, composite-widget navigation, roving tabindex, aria-activedescendant, disabled-control focusability, and shortcut conflicts.
Reference as
APG describes conventional keyboard models authors must implement when ARIA widgets replace native behavior.
Best application
Composite widgets, toolbars, menus, tabs, listboxes, grids, and trees.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-LANDMARKSAPG — Landmark RegionsPage regions, HTML landmark mappings, unique labels, region naming, landmark scope, and structural navigation.Practice
Use for
Page regions, HTML landmark mappings, unique labels, region naming, landmark scope, and structural navigation.
Reference as
APG recommends expressing the visual page structure with a small, meaningful set of HTML landmarks and uniquely labelling repeated landmark types.
Best application
SPA shells, sticky navigation, search, complementary panels, and content structure.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-PRESENTATIONAPG — Hiding Semantics with the presentation RoleThe difference between removing semantics and hiding content, inherited presentational effects, and cases where presentation is ignored.Practice
Use for
The difference between removing semantics and hiding content, inherited presentational effects, and cases where presentation is ignored.
Reference as
role="presentation" and role="none" suppress element semantics while ordinarily retaining descendant text and semantics.
Best application
Layout-only wrappers and composite-widget structure normalization.
Boundary
Do not use presentation or none as a general-purpose method for hiding content.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-AT-SUPPORTAPG — Assistive Technology Support TablesARIA-AT must-have and should-have interoperability results, limitations, and recommendations for product testing.Practice
Use for
ARIA-AT must-have and should-have interoperability results, limitations, and recommendations for product testing.
Reference as
ARIA-AT support tables help prioritize testing but are not a final verdict for a specific product implementation.
Best application
Browser/screen-reader test matrices and implementation-risk review.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-COMBOBOXAPG — Combobox PatternEditable and select-only combobox semantics, popup relationships, autocomplete modes, active descendants, and keyboard behavior.Practice
Use for
Editable and select-only combobox semantics, popup relationships, autocomplete modes, active descendants, and keyboard behavior.
Reference as
The APG combobox pattern defines a composite input-selection contract rather than a generic styled dropdown.
Best application
Autocomplete, command palettes, search suggestions, and advanced selectors.
Boundary
Prefer native select or input+datalist when they satisfy the task.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-TABSAPG — Tabs Patterntablist/tab/tabpanel roles, aria-selected, aria-controls, orientation, roving focus, and automatic-versus-manual activation.Practice
Use for
tablist/tab/tabpanel roles, aria-selected, aria-controls, orientation, roving focus, and automatic-versus-manual activation.
Reference as
The APG tabs pattern defines a single-tab-stop composite with arrow-key navigation and explicit panel relationships.
Best application
Layered peer content when one panel is visible at a time.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-GRIDAPG — Grid PatternInteractive data and layout grids, single-tab-stop composite navigation, editing, selection, and virtualized row/column metadata.Practice
Use for
Interactive data and layout grids, single-tab-stop composite navigation, editing, selection, and virtualized row/column metadata.
Reference as
The APG grid pattern is an application-style composite widget and requires authored focus management for every cell or contained control.
Best application
Spreadsheet-like or high-volume interactive tabular interfaces.
Boundary
Use a native table when the content is primarily static and ordinary tab order remains acceptable.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-TABLEAPG — Table PatternStatic tabular semantics and the distinction between table and interactive grid.Practice
Use for
Static tabular semantics and the distinction between table and interactive grid.
Reference as
APG strongly encourages native HTML table semantics for static tabular information.
Best application
Comparison tables and dense analytical data.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-TOOLBARAPG — Toolbar PatternGrouped controls, one tab stop, arrow-key movement, orientation, focus memory, and conflicts with nested widgets.Practice
Use for
Grouped controls, one tab stop, arrow-key movement, orientation, focus memory, and conflicts with nested widgets.
Reference as
The APG toolbar pattern can reduce tab stops when a meaningful group contains multiple related controls.
Best application
Editors, map controls, chart controls, and dense command clusters.
Boundary
Do not apply toolbar semantics to small or unrelated groups merely for visual styling.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-TOOLTIPAPG — Tooltip PatternNoninteractive descriptive popups associated with focus or hover, escape dismissal, and aria-describedby relationships.Practice
Use for
Noninteractive descriptive popups associated with focus or hover, escape dismissal, and aria-describedby relationships.
Reference as
The APG tooltip pattern supplements an already operable trigger with a brief description; it is not a container for actions.
Best application
Abbreviations, unfamiliar icon explanations, and concise supplementary descriptions.
Boundary
Interactive content belongs in a popover or dialog, not a tooltip.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-LISTBOXAPG — Listbox PatternSingle and multiselect option lists, selection-versus-focus behavior, typeahead, active descendants, and keyboard interaction.Practice
Use for
Single and multiselect option lists, selection-versus-focus behavior, typeahead, active descendants, and keyboard interaction.
Reference as
The APG listbox pattern defines selection semantics that differ from menus and navigation lists.
Best application
Custom selection lists only when native select is inadequate.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-TREEAPG — Tree View PatternHierarchical disclosure, selection, level, set position, and keyboard navigation.Practice
Use for
Hierarchical disclosure, selection, level, set position, and keyboard navigation.
Reference as
The APG tree pattern models a desktop-style hierarchical composite with authored arrow-key navigation.
Best application
File explorers, nested object browsers, and compact hierarchy editors.
Boundary
Ordinary nested site navigation typically needs links and disclosures, not tree semantics.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-TREEGRIDAPG — Treegrid PatternHierarchical interactive tabular data, row expansion, cell focus, headers, selection, and application reading mode.Practice
Use for
Hierarchical interactive tabular data, row expansion, cell focus, headers, selection, and application reading mode.
Reference as
The APG treegrid pattern combines tree and grid contracts and is among the highest-complexity ARIA widgets.
Best application
Enterprise hierarchy tables only when the interaction value justifies the testing burden.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-BUTTONAPG — Button PatternPush buttons, toggle buttons, aria-pressed, activation behavior, and stable toggle labels.Practice
Use for
Push buttons, toggle buttons, aria-pressed, activation behavior, and stable toggle labels.
Reference as
APG distinguishes a toggle button state from a changing command label and recommends native button elements when possible.
Best application
Icon actions, command buttons, and toggle controls.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
APG-SWITCHAPG — Switch PatternBinary on/off state, checked semantics, labels, and keyboard activation.Practice
Use for
Binary on/off state, checked semantics, labels, and keyboard activation.
Reference as
The switch pattern represents an immediate binary state rather than a generic button or a multi-option selection.
Best application
Settings with immediate on/off effects.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗

ARIA-related WCAG requirements5 sources

WCAG-1.3.1WCAG 2.2 — Info and RelationshipsProgrammatic expression of structure and relationships conveyed visually.Standard
Use for
Programmatic expression of structure and relationships conveyed visually.
Reference as
WCAG 2.2 SC 1.3.1 requires information, structure, and relationships conveyed through presentation to be programmatically determinable or available in text.
Best application
Landmarks, headings, form groups, tables, and component relationships.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
WCAG-2.1.1WCAG 2.2 — KeyboardKeyboard operability of all functionality without requiring specific timing for individual keystrokes.Standard
Use for
Keyboard operability of all functionality without requiring specific timing for individual keystrokes.
Reference as
WCAG 2.2 SC 2.1.1 requires all functionality to be operable through a keyboard interface, subject to the path-dependent exception.
Best application
Acceptance criteria for custom ARIA widgets.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
WCAG-2.5.3WCAG 2.2 — Label in NameAlignment between visible labels and programmatic accessible names for speech input and comprehension.Standard
Use for
Alignment between visible labels and programmatic accessible names for speech input and comprehension.
Reference as
WCAG 2.2 SC 2.5.3 requires an accessible name to contain the visible text label for controls whose labels include text or images of text.
Best application
Buttons, fields, links, and icon-plus-text controls.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
WCAG-4.1.2WCAG 2.2 — Name, Role, ValueProgrammatic name and role, user-settable states and values, and notification of changes.Standard
Use for
Programmatic name and role, user-settable states and values, and notification of changes.
Reference as
WCAG 2.2 SC 4.1.2 requires UI components to expose programmatically determinable names and roles and to make state/value changes available to user agents.
Best application
Custom control conformance and automated accessibility testing.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗
WCAG-4.1.3WCAG 2.2 — Status MessagesProgrammatic announcement of status messages without moving focus.Standard
Use for
Programmatic announcement of status messages without moving focus.
Reference as
WCAG 2.2 SC 4.1.3 requires status messages to be programmatically determinable through role or properties so assistive technologies can present them without focus.
Best application
Toasts, inline saves, loading completion, errors, and result counts.
Creator / author
W3C working group or task force; individual authors not asserted here
Publisher
World Wide Web Consortium (W3C)
Host
World Wide Web Consortium (W3C)
Origin
organization-authored-standard-specification-or-practice-guidance
Attribution status
publisher-only
Open source ↗

Deceptive design, autonomy & online choice architecture18 sources

GRAY-2018The Dark (Patterns) Side of UX DesignPractice-led taxonomy and ethical concerns around manipulative or unreasonably persuasive UX work.PrimaryFramework
Use for
Practice-led taxonomy and ethical concerns around manipulative or unreasonably persuasive UX work.
Reference as
Gray and colleagues identify practitioner concerns, design strategies, and forms of designer complicity associated with dark patterns.
Best application
Ethical design review, taxonomy foundations, and organizational accountability.
Creator / author
Colin M. Gray, Yubo Kou, Bryan Battles, Joseph Hoggatt, Austin L. Toombs
Publisher
Association for Computing Machinery
Host
par.nsf.gov
Origin
human-authored-research-or-official-guidance
Attribution status
verified
Open source ↗
DARK-ONTOLOGY-2023Towards a Preliminary Ontology of Dark Patterns KnowledgeHarmonizing academic and regulatory dark-pattern taxonomies into a shared hierarchy.PrimaryFramework
Use for
Harmonizing academic and regulatory dark-pattern taxonomies into a shared hierarchy.
Reference as
Gray, Santos, and Bielova propose a preliminary ontology that connects multiple dark-pattern taxonomies and regulatory vocabularies.
Best application
Machine-readable deceptive-design classification and cross-regulatory mapping.
Creator / author
Colin M. Gray, Cristiana Santos, Nataliia Bielova
Publisher
Association for Computing Machinery
Host
doi.org
Origin
human-authored-research-or-official-guidance
Attribution status
verified
Open source ↗
SHADOWS-2024Shadows in the Interface: A Comprehensive Study on Dark PatternsA comprehensive literature-derived taxonomy and assessment of dark-pattern detection capabilities.ReviewPrimary
Use for
A comprehensive literature-derived taxonomy and assessment of dark-pattern detection capabilities.
Reference as
The study synthesizes 76 publications into a broad taxonomy and identifies gaps in available detection tools and data.
Best application
Coverage audits and automated-review roadmap.
Boundary
Taxonomy breadth does not mean every named pattern is equally harmful in every context.
Creator / author
Organization-authored or not individually asserted
Publisher
Association for Computing Machinery
Host
doi.org
Origin
human-authored-research-or-official-guidance
Attribution status
publisher-only
Open source ↗
LUGURI-2021Shining a Light on Dark PatternsRandomized experiments measuring the effectiveness and user response to mild and aggressive dark patterns.Primary
Use for
Randomized experiments measuring the effectiveness and user response to mild and aggressive dark patterns.
Reference as
Luguri and Strahilevitz provide experimental evidence that dark patterns can materially change consumer choices and can provoke backlash when aggressive.
Best application
Autonomy impact assessment and evidence for rejecting conversion-only optimization.
Creator / author
Jamie Luguri, Lior Jacob Strahilevitz
Publisher
Oxford University Press
Host
academic.oup.com
Origin
human-authored-research-or-official-guidance
Attribution status
verified
Open source ↗
NOUWENS-2020Dark Patterns after the GDPR: Scraping Consent Pop-ups and Demonstrating their InfluenceLarge-scale consent-interface measurement and a field experiment on consent choice architecture.Primary
Use for
Large-scale consent-interface measurement and a field experiment on consent choice architecture.
Reference as
Nouwens and colleagues found widespread noncompliant consent designs and showed that hiding opt-out choices materially increased consent.
Best application
Consent-surface symmetry, first-layer choice parity, and revocation design.
Creator / author
Midas Nouwens, Ilaria Liccardi, Michael Veale, David Karger, Lalana Kagal
Publisher
ACM / arXiv
Host
arxiv.org
Origin
human-authored-research-or-official-guidance
Attribution status
verified
Open source ↗
FTC-DARK-2022Bringing Dark Patterns to LightUS regulator synthesis of deceptive interfaces involving disguised ads, cancellation obstruction, hidden terms and fees, and privacy manipulation.PracticeStandard
Use for
US regulator synthesis of deceptive interfaces involving disguised ads, cancellation obstruction, hidden terms and fees, and privacy manipulation.
Reference as
The FTC documents patterns that trick or trap consumers and connects them to enforcement concerns under existing consumer-protection law.
Best application
US-oriented deceptive-design policy, review checklists, and enforcement examples.
Boundary
Regulatory applicability depends on facts, jurisdiction, and governing law.
Creator / author
Organization-authored or not individually asserted
Publisher
Federal Trade Commission
Host
ftc.gov
Origin
organization-authored-regulatory-report
Attribution status
verified
Open source ↗
OECD-DCP-2022Dark commercial patternsInternational synthesis of definitions, prevalence, effectiveness, harms, and policy responses.ReviewPractice
Use for
International synthesis of definitions, prevalence, effectiveness, harms, and policy responses.
Reference as
The OECD describes dark commercial patterns as practices that steer, deceive, coerce, or manipulate consumers into choices often contrary to their interests.
Best application
Cross-jurisdiction policy framing and harm taxonomy.
Creator / author
Organization-authored or not individually asserted
Publisher
OECD Publishing
Host
oecd.org
Origin
organization-authored-policy-review
Attribution status
verified
Open source ↗
EDPB-DECEPTIVE-2023Guidelines 03/2022 on deceptive design patterns in social media platform interfacesFinal European data-protection guidance for recognizing and avoiding deceptive design in privacy-related social-media interfaces.StandardPractice
Use for
Final European data-protection guidance for recognizing and avoiding deceptive design in privacy-related social-media interfaces.
Reference as
The EDPB categorizes deceptive design practices and relates them to fairness, transparency, data protection by design, and valid consent.
Best application
Privacy flows, registration, settings, rights requests, and account deletion.
Boundary
Guidance must be applied with the GDPR and relevant national enforcement context.
Creator / author
Organization-authored or not individually asserted
Publisher
European Data Protection Board
Host
edpb.europa.eu
Origin
organization-authored-regulatory-guidance
Attribution status
verified
Open source ↗
EU-DSA-ARTICLE25Digital Services Act — Article 25: Online interface design and organisationEU prohibition on interface design that deceives, manipulates, or materially impairs free and informed decisions for covered online platforms.Standard
Use for
EU prohibition on interface design that deceives, manipulates, or materially impairs free and informed decisions for covered online platforms.
Reference as
DSA Article 25 prohibits covered platforms from designing or operating interfaces that materially distort or impair free and informed choice.
Best application
European platform governance, choice prominence, nagging, cancellation, and default-setting reviews.
Boundary
Article 25 scope and interaction with GDPR and unfair-commercial-practice law require legal analysis.
Creator / author
Organization-authored or not individually asserted
Publisher
European Union
Host
eur-lex.europa.eu
Origin
legislation
Attribution status
verified
Open source ↗
CMA-OCA-2022Online Choice Architecture: How digital design can harm competition and consumersTaxonomy and policy discussion of online choice architecture, consumer harm, and competition effects.ReviewPractice
Use for
Taxonomy and policy discussion of online choice architecture, consumer harm, and competition effects.
Reference as
The CMA explains how choice structure, information, and pressure can distort decisions and weaken competition.
Best application
Product review beyond narrow deception, including sludge, ranking, defaults, scarcity, and personalization.
Creator / author
Organization-authored or not individually asserted
Publisher
UK Competition and Markets Authority
Host
gov.uk
Origin
organization-authored-government-research
Attribution status
verified
Open source ↗
CMA-OCA-EVIDENCE-2022Evidence review of Online Choice Architecture and consumer and competition harmDetailed evidence review across 21 online-choice-architecture practices.Review
Use for
Detailed evidence review across 21 online-choice-architecture practices.
Reference as
The CMA evidence review distinguishes practices that are usually harmful from context-dependent techniques and evaluates evidence strength.
Best application
Evidence grading, design-review prioritization, and identifying context-sensitive risks.
Creator / author
Organization-authored or not individually asserted
Publisher
UK Competition and Markets Authority
Host
gov.uk
Origin
organization-authored-government-review
Attribution status
verified
Open source ↗
ICO-PRIVACY-DESIGNICO — Data protection by design and by defaultCurrent UK guidance on neutral choices, strong privacy defaults, understandable information, and avoiding harmful language or color nudges.StandardPractice
Use for
Current UK guidance on neutral choices, strong privacy defaults, understandable information, and avoiding harmful language or color nudges.
Reference as
The ICO expects privacy controls to be findable, balanced, understandable, and available throughout the user journey.
Best application
Privacy defaults, consent, withdrawal, settings, and vulnerable-user reviews.
Boundary
Legal obligations depend on UK data-protection scope and facts.
Creator / author
Organization-authored or not individually asserted
Publisher
UK Information Commissioner's Office
Host
ico.org.uk
Origin
organization-authored-regulatory-guidance
Attribution status
verified
Open source ↗
CONSENT-NUDGES-2023Don’t Accept All and Continue: Exploring Nudges for More Deliberate Interaction with Tracking Consent NoticesExperimental comparison of interventions intended to interrupt habitual consent responses.Primary
Use for
Experimental comparison of interventions intended to interrupt habitual consent responses.
Reference as
Gerber and colleagues show that consent behavior is often habitual and evaluate mechanisms intended to support more deliberate choice.
Best application
Designing consent for reflection rather than maximizing either acceptance or rejection.
Creator / author
Nina Gerber, Alina Stöver, Justin Peschke, Verena Zimmermann
Publisher
Association for Computing Machinery
Host
doi.org
Origin
human-authored-research-or-official-guidance
Attribution status
verified
Open source ↗
BRIGHT-PATTERNS-2025Dark and Bright Patterns in Cookie Consent RequestsPreregistered experiments comparing privacy-unfriendly and privacy-friendly choice nudges.PrimaryDraft
Use for
Preregistered experiments comparing privacy-unfriendly and privacy-friendly choice nudges.
Reference as
The experiments show that reversing a nudge toward a privacy-friendly choice can also influence behavior, raising questions about autonomy even for well-intended bright patterns.
Best application
Avoiding simplistic substitution of manipulative dark patterns with manipulative bright patterns.
Boundary
Preprint status; findings should be interpreted with the final publication and broader evidence.
Creator / author
Paul Graßl, Hanna Schraffenberger, Frederik Zuiderveen Borgesius, Moniek Buijzen
Publisher
arXiv
Host
arxiv.org
Origin
human-authored-research-or-official-guidance
Attribution status
verified
Open source ↗
TRANSACTION-TEST-2026The transaction test: An experimental method for assessing online interfacesExperimental method for measuring whether interface design produces choices inconsistent with underlying preferences.Primary
Use for
Experimental method for measuring whether interface design produces choices inconsistent with underlying preferences.
Reference as
The transaction test compares stated preferences and actual choices to detect autonomy-relevant inconsistency caused by interface design.
Best application
Evaluation of consent and transactional choice architectures.
Creator / author
Organization-authored or not individually asserted
Publisher
Elsevier
Host
sciencedirect.com
Origin
human-authored-research-or-official-guidance
Attribution status
publisher-only
Open source ↗
DARK-AGENTS-2026Dark Patterns Meet GUI Agents: LLM Agent Susceptibility to Manipulative Interfaces and the Role of Human OversightEmpirical comparison of humans, GUI agents, and human-agent teams facing 16 deceptive pattern types.Primary
Use for
Empirical comparison of humans, GUI agents, and human-agent teams facing 16 deceptive pattern types.
Reference as
The study reports that agents often fail to recognize manipulative interfaces and may prioritize task completion over protective action; oversight helps but introduces new costs.
Best application
Agent-safe transactions, confirmation boundaries, and automated dark-pattern auditing.
Creator / author
Jingyu Tang, Chaoran Chen, Jiawen Li, Zhiping Zhang, Bingcan Guo, Ibrahim Khalilov, Simret Araya Gebreegziabher, Bingsheng Yao, Dakuo Wang, Yanfang Ye, Tianshi Li, Ziang Xiao, Yaxing Yao, Toby Jia-Jun Li
Publisher
Association for Computing Machinery
Host
doi.org
Origin
human-authored-research-or-official-guidance
Attribution status
verified
Open source ↗
FTC-AMAZON-PRIMEFTC v. Amazon.com, Inc. — Prime enrollment and cancellation allegationsA current enforcement example concerning alleged nonconsensual enrollment and cancellation obstruction.Practice
Use for
A current enforcement example concerning alleged nonconsensual enrollment and cancellation obstruction.
Reference as
The FTC case illustrates regulatory scrutiny of enrollment flows and cancellation journeys designed to retain users rather than execute their stated intent.
Best application
Subscription lifecycle red-teaming and cancellation parity.
Boundary
The case is pending; allegations are not final adjudicated findings.
Creator / author
Organization-authored or not individually asserted
Publisher
Federal Trade Commission
Host
ftc.gov
Origin
government-enforcement-record
Attribution status
verified
Open source ↗
FTC-HOPPER-2026FTC v. Hopper — hidden and preselected fee settlementA 2026 enforcement example involving allegedly hidden and preselected optional fees and misleading price claims.Practice
Use for
A 2026 enforcement example involving allegedly hidden and preselected optional fees and misleading price claims.
Reference as
The Hopper matter illustrates risks from preselection, hidden fees, inaccurate total-price communication, and confusing optional-service presentation.
Best application
Checkout, travel, fee, and add-on review.
Boundary
Use the filed complaint and order for precise legal facts and obligations.
Creator / author
Organization-authored or not individually asserted
Publisher
Federal Trade Commission
Host
ftc.gov
Origin
government-enforcement-record
Attribution status
verified
Open source ↗
W3C-EVALUATEW3C WAI — Evaluating Web Accessibility OverviewCombining automated checks, manual evaluation, assistive-technology testing, and user involvement.Practice
Use for
Combining automated checks, manual evaluation, assistive-technology testing, and user involvement.
Reference as
W3C WAI recommends a mixed evaluation approach because automated tools cannot determine every accessibility outcome.
Best application
Validation-lab governance and release certification boundaries.
Boundary
Evaluation guidance supports, but does not replace, the normative WCAG success criteria.
Publisher
World Wide Web Consortium (W3C)
Attribution status
publisher-only
Open source ↗
W3C-ACTW3C — Accessibility Conformance Testing (ACT) OverviewMachine-testable and semi-automated accessibility-rule structure, applicability, expectations, and result reporting.Standard
Use for
Machine-testable and semi-automated accessibility-rule structure, applicability, expectations, and result reporting.
Reference as
W3C ACT provides a formal structure for repeatable accessibility test rules while recognizing that some evaluation remains manual.
Best application
Executable fixture checks and machine-readable validation results.
Boundary
Passing a selected set of ACT-style rules is not equivalent to whole-product WCAG conformance.
Publisher
World Wide Web Consortium (W3C)
Attribution status
publisher-only
Open source ↗
APG-READ-FIRSTARIA Authoring Practices Guide — Read Me FirstRole-as-promise governance, native HTML preference, and mandatory interoperability testing before production use.Practice
Use for
Role-as-promise governance, native HTML preference, and mandatory interoperability testing before production use.
Reference as
APG states that a role is a promise and that ARIA semantics do not create the keyboard or interaction behavior associated with the role.
Best application
Custom-widget acceptance criteria and fixture design.
Boundary
APG examples are illustrative patterns, not production-certified components.
Publisher
World Wide Web Consortium (W3C)
Attribution status
publisher-only
Open source ↗
CHROME-COMMAND-2025Chrome for Developers — Introducing command and commandforDeclarative dialog and popover invocation, custom command events, and capability-based progressive enhancement.Practice
Use for
Declarative dialog and popover invocation, custom command events, and capability-based progressive enhancement.
Reference as
Chrome documents command and commandfor as declarative relationships that map buttons to supported dialog and popover actions.
Best application
Feature-detected fixture variants that reduce bespoke JavaScript.
Boundary
A browser implementation announcement is not a cross-browser support guarantee; test the actual product matrix.
Publisher
Google Chrome Developers
Attribution status
publisher-only
Open source ↗
CHROME-WEBUI-2025Chrome for Developers — What’s New in Web UI: I/O 2025 RecapPublished implementation milestones for dialog closedby, command invokers, popovers, and anchor positioning.Practice
Use for
Published implementation milestones for dialog closedby, command invokers, popovers, and anchor positioning.
Reference as
Chrome’s Web UI recap records implementation milestones for declarative interaction primitives and their intended modal or nonmodal behavior.
Best application
Support-tier metadata and progressive-enhancement planning.
Boundary
Milestone tables age quickly and must be reverified against supported browser versions.
Publisher
Google Chrome Developers
Attribution status
publisher-only
Open source ↗

Knowledge architecture, attribution, and provenance

Separate source credit, human accountability, AI contribution, and generated projections.

Version 1.3 extends the canonical OKF and provenance system with ARIA semantic contracts, computed accessibility-tree guidance, accessible-name rules, state taxonomies, keyboard models, and interoperability evidence.

1 · Source attribution

Each reference records its creator or author when verified, publisher when known, hosting organization, origin, retrieval date, and attribution status. Unknown authors remain explicitly pending rather than guessed.

2 · Human ownership

Jesse Graupmann is recorded as research director, author, editor, and accountable owner. Direction, evaluation, acceptance, publication approval, and future material changes remain human responsibilities.

3 · AI contribution

OpenAI ChatGPT · GPT-5.6 Thinking is credited as a software-agent contributor for research discovery, source analysis, synthesis, drafting, schema design, implementation, OKF packaging, and validation.

Canonical projection pipeline

OKF bundle
Human- and agent-readable Markdown/YAML concepts
Deterministic validation
Types, frontmatter, links, citations, IDs, and counts
JSON + JSON-LD
Application data and typed PROV graph
SPA + future outputs
Mobile reference, search, print, and generated artifacts

OKF profile

OKF supplies the portable exchange envelope. Local profile extensions add ownership, status, relationships, contribution records, and review metadata while remaining tolerable to generic OKF consumers.

Research SourceResearch FindingDesign PrincipleImplementation RecommendationComponent PlaybookValidation MethodAnti-pattern GroupCitation Language RuleContribution RecordProvenance ActivityGenerated ArtifactSchema ProfileValidation ResultInteraction Surface ContractForm Experience ContractNotification Escalation ContractARIA Semantic ContractAccessible Name ContractKeyboard Interaction Contract

Projection boundaries

ProjectionPurpose
Schema.org JSON-LDPublic discovery metadata that describes visible content.
Internal JSON-LD / PROVClaims, citations, agents, activities, ownership, and generated artifacts.
Research JSONComplete application contract for future systems and agents.
OKF bundlePortable, diffable, independently readable knowledge source.

Added research findings

Canonical knowledge and presentation outputs should be separate layers.

A self-contained SPA is an effective reading and sharing projection, but it should not be the only canonical representation of the research.

Design implication: Maintain an OKF-compatible concept bundle as the portable authoring layer, then compile JSON, JSON-LD, search indexes, and the SPA from stable object IDs.

Source authorship and synthesis contribution are independent provenance dimensions.

The creator of a paper, book, standard, repository, or video remains the source author even when a human researcher and AI system transform it into a new synthesis.

Design implication: Record source creators and publishers separately from the research owner, software-agent contributor, derivation activity, review status, and generated artifact.

AI contribution should be explicit without displacing human accountability.

A software agent can be credited for research discovery, synthesis, drafting, schema design, implementation, and validation while the accountable human retains direction and publication authority.

Design implication: Use contribution roles and activities rather than assigning AI an ambiguous co-author label; record who directed, reviewed, accepted, or rejected the output.

Public structured data and the internal research graph serve different audiences.

Schema.org JSON-LD should truthfully describe visible public content, while an internal JSON-LD/PROV graph can express richer claims, citations, derivations, ownership, and agent activity.

Design implication: Generate both projections from the same canonical identifiers instead of forcing one vocabulary to serve discovery, governance, and reasoning simultaneously.

One concept per file improves bounded retrieval and review.

Small typed concept documents allow humans and agents to load, link, diff, validate, and review only the knowledge relevant to the task.

Design implication: Represent findings, recommendations, methods, components, anti-patterns, sources, schemas, and contribution records as separately addressable knowledge objects.

Agent-maintained knowledge still requires deterministic validation and human review.

An agent should not be the sole judge of the structure, links, citations, or epistemic status of the artifacts it generates.

Design implication: Use a consume, propose, validate, review, accept-or-reject, and log workflow with conformance checks in CI.

Implementation recommendations

P0Canonical knowledge

Adopt an OKF-compatible bundle as the portable source of truth.

The visual SPA, embedded JSON, JSON-LD graph, print view, and future outputs should remain synchronized derivatives rather than independent documents.

Implementation guidance
  • Use one typed concept per Markdown file
  • Generate directory index.md files for progressive disclosure
  • Maintain a reverse-chronological log.md
  • Compile derivatives from stable IDs
  • Preserve producer-defined provenance fields
P0Attribution

Record source creators, human ownership, and AI contribution separately.

This preserves credit, accountability, derivation, and evidence lineage while showing exactly where AI provided leverage.

Implementation guidance
  • Add creators, publisher, origin, and attribution status to every source
  • Identify Jesse Graupmann as research owner and accountable editor
  • Identify OpenAI ChatGPT as a software-agent contributor
  • Record contribution roles and review status
  • Never replace source authorship with synthesis authorship
P0Validation

Add deterministic OKF, schema, link, and citation checks.

Structural validity and citation integrity should be machine-checkable rather than inferred from model confidence.

Implementation guidance
  • Validate YAML frontmatter and required type
  • Check reserved index.md and log.md usage
  • Check local concept links
  • Check reference keys and source URLs
  • Record validation results with the generated artifact
P1Projection architecture

Publish constrained public JSON-LD and a richer internal provenance graph.

Search engines and public consumers need concise truthful metadata; enterprise agents need typed relationships, contribution activities, and evidence lineage.

Implementation guidance
  • Use Schema.org Dataset/CreativeWork for the visible artifact
  • Use PROV-O for agents, activities, derivation, and attribution
  • Use stable @id values matching SPA anchors and OKF concept IDs
  • Export the graph as a companion JSON-LD file
P1Agent workflow

Use a soft-mode consume, propose, validate, and review loop.

Future systems should leverage the research without silently rewriting accepted conclusions or obscuring rejected changes.

Implementation guidance
  • Read relevant indexes and concepts before work
  • Propose bounded changes
  • Record inputs, outputs, and agent roles
  • Run deterministic validation
  • Require human review for material changes
  • Append accepted and rejected outcomes to the log

Governance validation

Citation language guide

Use the strongest accurate verb for each evidence class.

Evidence classRecommended wordingUsage boundary
StandardWCAG 2.2 requires…Use for normative requirements and final technical specifications.
Primary researchThe experiment found…Describe the population, task, and boundary when material.
ReviewThe review concludes…Use to summarize a body of evidence or qualify classic findings.
FrameworkThe framework proposes…Do not present conceptual models as experimental proof.
Practice guidanceThe practitioner guidance recommends…Use for applied patterns and production precedent.
DraftThe current working draft explores…Never present draft language as a current requirement.

Continuous compiler & release governance

Deterministic generation, source freshness, integrity manifests, and accountable review.

The research system is now compiled as a versioned product. Canonical data, presentation templates, provenance, search indexes, and OKF concepts are validated together; published derivatives receive content hashes and explicit evidence boundaries.

Build identity

8742e6f0154118dae479

Compiler v1.0.0 · System v1.6.2

Canonical inputs
5
Derivative classes
8

Freshness ledger

181 sources tracked

181 date-current · 9 attribution reviews pending

Offline validation does not prove current URL reachability or source supersession.

Certification boundary

Compiler-verified, not production-certified

Structural, integrity, and deterministic gates are automated. Representative visual and assistive-technology evidence remains required.

Deterministic compiler pipeline

1
Load canonical inputs

Read versioned research JSON, graph, template, and OKF concepts.

2
Validate schemas

Reject missing required collections, fields, IDs, types, and invalid report contracts.

3
Validate relationships

Check reference keys, component links, stable IDs, anchors, and OKF internal links.

4
Compile derivatives

Inject script-safe JSON, graph, and pointer search index into the presentation template.

5
Run structural gates

Check HTML IDs, anchors, button names, JavaScript syntax, catalog continuity, and unsafe URL schemes.

6
Evaluate freshness and evidence gaps

Apply review cadences by source class and preserve unresolved attribution and test evidence.

7
Generate integrity manifest

Hash inputs and derivatives and record the compiler, build identity, sizes, and validation status.

8
Require governed review

Material changes move through proposed, validated, reviewed, approved, released, and superseded states.

Release gates

passBlocking

Schema and count parity

Release cannot proceed when this gate fails.

passBlocking

IDs, anchors, references, and OKF links

Release cannot proceed when this gate fails.

passBlocking

HTML data, JSON-LD, and JavaScript syntax

Release cannot proceed when this gate fails.

passBlocking

Two clean rebuilds produce identical bytes

Release cannot proceed when this gate fails.

warningEvidence

Source freshness and attribution review

This evidence gap remains visible and scheduled.

pendingEvidence

Stable visual regression runner

This evidence gap remains visible and scheduled.

pendingBlocking

Representative browser and assistive-technology evidence

Release cannot proceed when this gate fails.

template readyBlocking

Accountable human release approval

Release cannot proceed when this gate fails.

Governed review workflow

01

Proposed

Describe intended change, affected objects, evidence, and risk.

Owner: contributor
02

Machine Validated

Pass deterministic schemas, references, syntax, and integrity gates.

Owner: compiler
03

Human Reviewed

Evaluate meaning, evidence quality, user impact, and rejected alternatives.

Owner: research owner or delegate
04

Approved

Record approval, limitations, and release scope.

Owner: accountable approver
05

Released

Publish manifest, package, changelog, and known limitations.

Owner: release process
06

Superseded

Preserve prior state and link to the replacement.

Owner: maintainer

Source freshness policy

Evidence classReview cadenceReason
Draft30 daysWorking documents can change materially without a stable release boundary.
Standard or specification45 daysNormative status, editions, errata, and implementation support may change.
Practice guidance90 daysBrowser, platform, and design-system behavior evolves quickly.
Primary study or review365 daysThe original evidence is stable, but later replication or synthesis may qualify it.
Framework or book730 daysFoundational concepts are durable; editions and interpretation still require periodic review.

A valid URL is not proof that the content is current, unchanged, authoritative, or not superseded. Network and archival checks remain a separate pipeline stage.

Build artifacts

Rebuild and audit the release

The package includes the canonical compiler inputs, deterministic template, schemas, CI example, review template, freshness ledger, and integrity manifest.

compile.pycompiler-lock.jsonrelease-manifest.jsonsource-freshness.jsonschemas/ci/

LLM-friendly research data

The SPA, embedded JSON, JSON-LD graph, OKF bundle, component behavior contracts, and ARIA semantic contracts share stable IDs, references, attribution, and validation records.

Data contract

The structured payload is embedded in <script type="application/json" id="research-data">. Future systems can extract it without interpreting layout or CSS.

meta

Version, generation date, description, schema version, and entity counts.

principles

Governing rules with summaries, detailed implications, and reference relationships.

domains

Concept taxonomy, key concepts, takeaways, and source keys.

findings

Stable findings with domain, evidence summary, design impact, and citations.

recommendations

Prioritized implementation actions, rationale, steps, and evidence.

components

Component purpose, anatomy, recommended use, anti-patterns, and sources.

methods

Validation questions, test steps, and supporting research.

references

Source key, evidence class, URL, use, citation wording, application, and boundary.

antiPatterns

Grouped failure modes suitable for review agents and automated linting prompts.

authorship

Human research owner, AI contributor, source-attribution policy, and review status.

okfProfile

Target formats, concept types, extensions, and deterministic operational controls.

contributions

Human and software-agent activities with roles, targets, timestamps, and review state.

schemas

JSON Schema contracts for source attribution, contribution records, and OKF concept extensions.

knowledgeObjects

Flattened typed inventory for bounded LLM retrieval and graph projection.

validationResult

Deterministic bundle and derivative validation outcome.

interactiveSurfaceContract

Task, native primitive, focus, dismissal, save, risk, responsive transformation, and support tier.

formContract

Purpose, fields, groups, validation, save semantics, success, and retention.

notificationContract

Urgency, action requirement, persistence, surface, timeout, focus, and durable history.

ariaSemanticContract

Native preference, role, name, state, relationships, keyboard, focus, prohibited combinations, and evidence.

accessibleNameContract

Visible label, name source, description source, label-in-name requirement, and computation tests.

keyboardInteractionContract

Entry, page tab stops, navigation, activation, exit, focus strategy, wrapping, typeahead, and disabled policy.

compilerGovernance

Compiler pipeline, gates, determinism rules, review workflow, and derivative contracts.

sourceFreshness

Review cadence, due dates, attribution status, and explicit offline verification boundaries.

Download OKF

Navigate

Research sections

Display settings

Appearance and density

Theme

Cycle among system, light, and dark appearances.

Density

Switch between comfortable and compact information density.