About this reference

19 UI/UX pattern guides for developers. Each covers when to use a pattern, when to avoid it, implementation details, accessibility, and tradeoffs.

Using the guides

Search by component or problem, or filter by topic. Each guide includes an example and a verification question. Recommendations are defaults to evaluate against your application’s requirements.

For AI agents

The AI agent skill lets your agent use this reference when choosing and implementing UI/UX patterns. Read the SKILL.md file or follow the setup instructions on the skill page. The skill and its linked Markdown guides are generated from the same content as the website.

Sources

We check the sources for each topic and point out material differences. Technical requirements come first within their scope. For design advice that leaves a choice, we use the preference order below.

Requirements and implementation

Web and accessibility standards. Use applicable WCAG, HTML, WAI-ARIA and protocol requirements for conformance, native behavior and interoperability. Distinguish normative requirements from explanatory guidance. WCAG 2.2 · HTML Standard · WAI-ARIA · IETF RFCs
Accessibility and browser implementation guidance. Use W3C WAI tutorials and APG for accessible interaction patterns, and MDN for browser APIs and native HTML. APG examples and tutorials are implementation guidance; test the finished interface with its users and supported technology. WAI tutorials · ARIA Authoring Practices Guide · MDN
Security guidance. Use OWASP for server validation, authorization and other security controls. Interface convenience must preserve those controls. OWASP Cheat Sheet Series

Preferred design sources, in order

GOV.UK Design System — Default for forms, transactions, navigation and service content. Check whether its government-service assumptions fit the task.
IBM Carbon — Next reference, especially for dense application interfaces, workspaces and data-heavy tasks.
U.S. Web Design System — Additional component and service guidance. Preserve component-specific accessibility warnings.
Singapore Government Design System — Additional component guidance, with its particular interaction and modality assumptions.
Scottish Government Design System — Additional public-service guidance, including search and mobile filtering.
GitHub Primer — Additional application guidance, including focus management and dynamic content.

When sources differ

Compare the current sources relevant to the decision. Identify whether they disagree about a requirement, a design default, or the behavior of a particular component.
Use the first applicable design source in the order above as the default. More relevant task evidence or a component-specific limitation can justify another choice; explain and record the reason.
State the material alternatives, the source we prefer for that decision, and why. Preserve scope, qualifications and known accessibility issues. Label our own synthesis as a recommendation.
When a source is unavailable or the evidence is inconclusive, disclose the limitation. Do not describe the decision as source-verified or invent agreement.

Guide-specific source choices

How should a form choose between radios, a select and autocomplete?: prefer GOV.UK · Select. Follow GOV.UK: make manageable choices visible and try narrowing a long list before using a select. Its last-resort advice applies to public-facing services and is not a WCAG prohibition. Do not adopt the USWDS more-than-15-options heuristic as a universal cutoff; preserve its warning about assistive-technology issues with its own combo box and suggestion to consider a select. Test any necessary select or autocomplete with users and supported technology. Alternatives: USWDS · Combo box.
Should filters update results instantly or after Apply?: prefer Carbon · Filtering. Follow Carbon’s task-based approach: instant updates for one category or one expected selection, batch updates for several selections across categories, choices that take time to consider or slow results. Scottish Government requires Apply in its mobile pattern because users may miss automatic changes. Preserve that caveat as a contextual check: use Apply when changes are easy to miss and test whether users understand the feedback, rather than requiring Apply on every mobile layout. Alternatives: Scottish Government · Search filters.
When should content be hidden in an accordion?: prefer GOV.UK · Choosing accordions, details and visible content. Follow GOV.UK for the design decision: keep essential content visible, use accordions only when user research supports them, use separate pages for a series of questions and do not nest accordions. W3C APG demonstrates a form accordion and discusses nesting as implementation cases, not evidence that these designs suit a task. Use APG for accessible keyboard interaction and semantics after the design choice is justified. Alternatives: W3C · Accordion pattern.
Which requirements should govern error messages and their presentation?: prefer WCAG 2.2 · Error identification (3.3.1). Follow WCAG 3.3.1 for textual input-error identification, 3.3.3 for known correction suggestions with its security and purpose exceptions, and 4.1.3 for dynamic status messages. GOV.UK’s always-show-and-focus-an-error-summary and explanatory-page conventions are more prescriptive presentation choices. This guide chooses inline messages, summaries or pages for the task while preserving the applicable WCAG requirements. Alternatives: GOV.UK · Error summaries for validation, GOV.UK · Field errors and service failures.
How should a multi-step form group fields and communicate progress?: prefer W3C · Multi-page forms. Prefer W3C for this guide: keep related fields in logical stages and communicate progress, explaining the number of steps where possible. Titles or headings can provide progress information without a graphical bar. This explicitly chosen guide-specific preference takes precedence over the general GOV.UK design default; GOV.UK’s one-question-per-page and test-without-an-indicator defaults remain documented as a different approach. Alternatives: GOV.UK · Question pages and progress indicators.
When should a form give validation feedback?: prefer W3C · Form notifications and validation timing. Follow W3C guidance on choosing feedback during typing, on focus change or after submission according to the task. The validating-input tutorial is complementary guidance on browser checks and server enforcement. Our former submission-first restriction was an editorial preference, not a W3C requirement; removing it resolves the review without implying a disagreement between these sources. Alternatives: W3C · Validating input.
Should a modal support Escape dismissal?: prefer W3C APG · Modal dialog pattern. Follow W3C APG: Escape closes the modal, with a clear Cancel or Close action and appropriate focus return. We do not adopt the USWDS forced-action variant in this guide. Preserve costly drafts when dismissing as an additional usability safeguard; APG does not prescribe a draft-storage mechanism. Alternatives: USWDS · Modal guidance.

Examples demonstrate individual interactions. They do not replace keyboard, screen reader, zoom, and usability checks in your application.

Browser behavior

Search and examples run locally in your browser. Queries and topic filters are included in the URL. Example data is not sent to a server or saved by this site. No analytics, external fonts, or third-party scripts are loaded.

Maintained by Alexander Claes. Source policy updated 30 October 2026.