UI Patterns: Reusable Recipes for Interfaces
UI patterns are reusable recipes for common interface problems, like tabs or accordions. They create a shared language for building predictable, accessible components. The biggest footgun is creating a component that looks right but lacks accessible behaviors.
Why it exists
Without standard patterns, every website would implement common widgets like tabs, menus, and dialogs differently. This creates a confusing and inaccessible experience for users, especially those relying on assistive technologies who expect predictable behavior. Patterns solve this by providing a consistent blueprint.
The mental model
UI patterns are like a cookbook for interfaces. You don't invent a new way to make bread from scratch every morning; you follow a recipe. Similarly, for a set of layered content, you use the "Tabs" recipe. For a show/hide section, you use the "Accordion" recipe. These recipes define not just the visual look but the interactive behavior and accessibility semantics.
How it works
A pattern defines three core aspects: first, the expected visual presentation (e.g., a stack of headers for an accordion); second, the required keyboard interactions (e.g., arrow keys navigate tabs); and third, the necessary accessibility semantics. These semantics are usually implemented with ARIA (Accessible Rich Internet Applications) attributes. Attributes like role="tab" and aria-selected="true" communicate the component's state and purpose to assistive technologies like screen readers.
When to use it
Use standard patterns whenever you're building a common piece of UI. This is foundational for creating design systems, component libraries, and any application that prioritizes consistency and accessibility. Following patterns like those in the W3C's ARIA Authoring Practices Guide (APG) saves you from reinventing the wheel and ensures your UI is robust and usable by everyone.
When not to use it
Avoid misusing a pattern. Don't use a "Link" pattern (which navigates) to perform an action (which is a "Button" pattern's job). Don't create a custom, non-standard widget when a well-defined pattern already exists and solves the problem. If your UI problem is truly novel, you may need to define a new pattern, but this should be a rare and deliberate choice.
One canonical example
The "Tabs" pattern. Visually, it's a set of headers linked to content panels. Behaviorally, the Left and Right arrow keys should switch between tabs, and only one tab panel is visible at a time. Semantically, the container has role="tablist", each tab has role="tab", and the active tab has aria-selected="true". A common mistake is implementing this with styled divs and click handlers but forgetting the keyboard navigation and ARIA roles, making it unusable for non-mouse users.
Interview question
What is the most significant consequence of implementing a UI component that looks like a standard pattern but lacks its defined behaviors and semantics?
- a.Users, particularly those using assistive technologies, may find it unpredictable and inaccessible.Correct
- b.The component will not be reusable across different parts of an application.
- c.It will require more complex styling and visual adjustments over time.
- d.Other developers will struggle to understand and maintain its codebase.
Why? this is the answer
The card emphasizes that "The biggest footgun is creating a component that looks right but lacks accessible behaviors," resulting in "a confusing and inaccessible experience for users, especially those relying on assistive technologies." While other options might be minor drawbacks, the primary concern highlighted is user accessibility and predictability.
Just read this? Test yourself on what you have been reading.
Read the original → w3.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ui — each one lists the topics its interview covers.
See open roles