← Back to Course

Module 13

Components & Patterns

UI components are the building blocks of interfaces. Understanding common patterns - navigation, cards, modals, tabs - helps you create consistent, usable experiences that users already know how to use.

From jQuery plugins to React components to Web Components. The implementation changes, but the patterns remain. A modal is a modal is a modal.

Hamburger menus replaced full navigation, then bottom bars emerged for mobile. Patterns evolve with devices, but core interaction principles persist.

Consistency, discoverability, feedback, and accessibility. Components should work as users expect, be easy to find, respond to actions, and work for everyone.

Part A

Core Concepts

01

Navigation Patterns

Navigation is how users move through your interface. The right pattern depends on content structure, device, and user needs.

Rule of Thumb

Visible navigation is always better than hidden. Hamburger menus reduce engagement. Use them when space truly requires it.

02

Card Components

Cards are containers for related content. They create visual grouping and can be interactive, linkable, or purely presentational.

Card Title

Brief description of the card content goes here.

Basic Card Structure

Cards typically have: image/media, title, description, and action. Border-radius and shadow create the 'card' feel. Keep structure consistent.

Click anywhere

Entire card is interactive

Learn more →

Hover: border-color change, slight lift

Card 1

Card 2

Card 3

Card Grids

Use CSS Grid for card layouts. auto-fit with minmax() creates responsive grids without media queries. Keep gap consistent.

Success

Featured

Dark

Card Variations

Create card variants for different contexts: accent borders, background colors, elevation levels. Keep variants in your design system.

Accessibility

If card is clickable, make it a link or button. Don't rely on hover for essential info. Ensure focus states are visible.

03

Modals & Dialogs

Modals interrupt user flow to focus attention. Use sparingly - they block interaction with the page beneath.

Modal Title

×

Modal content goes here. Keep it focused on a single task.

Modal Structure

Modals need: overlay backdrop, close button, title, content, and actions. Primary action right, secondary left. Always provide escape route.

✓ Close on Escape key
✓ Close on backdrop click
✓ Trap focus inside modal
✓ Return focus when closed
✓ Prevent body scroll
Modal Behavior

Essential behaviors: Escape closes, backdrop click closes, focus is trapped, scroll is locked on body, focus returns to trigger on close.

GOOD USES

• Confirmation dialogs

• Critical alerts

• Quick forms (login)

BAD USES

• Long forms

• Complex workflows

• Newsletter signups

Modal Use Cases

Use modals for: confirmations, urgent messages, quick focused tasks. Don't use for: long content, complex forms, marketing interrupts.

<dialog id="modal">

<form method="dialog">

<p>Confirm?</p>

<button>Cancel</button>

<button>OK</button>

</form>

</dialog>

// modal.showModal()

Native Dialog Element

The native

element handles focus trapping, backdrop, and escape key automatically. Use it when possible. Polyfill for older browsers.

ARIA

role='dialog' aria-modal='true' aria-labelledby='title-id'. Focus first focusable element on open.

04

Tabs & Accordions

Tabs and accordions organize content into sections. They reduce scrolling but hide content - use when sections are mutually exclusive.

Tab One
Tab Two
Tab Three

Content for Tab One. Only this panel is visible.

Tab Component

Tabs show one panel at a time. Active tab should be visually distinct. Content should be at same level (parallel). Don't nest tabs.

Section One−
Expanded content visible
Section Two+
Section Three+
Accordion Component

Accordions can show multiple or single panels. Good for FAQs, settings. Use when users need specific sections, not all content.

TABS KEYBOARD

← → Arrow keys switch tabs
Home/End go to first/last
Enter/Space activate

ACCORDION KEYBOARD

Enter/Space toggle section
↑ ↓ navigate headers
Keyboard Navigation

Tab interfaces need specific keyboard navigation. Arrow keys move between tabs, Enter activates. This is the expected WAI-ARIA pattern.

<details open>

<summary>Click to expand</summary>

<p>Hidden content here</p>

</details>

// Works without JavaScript!

Native Details Element

The native

/ elements create no-JS accordions. Keyboard accessible by default. Style with CSS. Great for FAQs.

Choose Wisely

Tabs: parallel content, one visible at a time. Accordion: sequential content, multiple can be open. Both hide content - consider if hiding is necessary.

05

Feedback Components

Users need feedback when things happen. Toasts, alerts, and loading states communicate system status.

✓ Changes saved
Toast Notifications

Toasts appear temporarily for non-critical feedback. Position consistently (usually bottom-right). Auto-dismiss after 3-5 seconds. Don't require action.

⚠️ Error: Could not save changes×
✓ Your profile has been updated
⚠ Your trial expires in 3 days
Alert Banners

Alerts persist until dismissed or resolved. Use color + icon for status. Error alerts need close button or fix action. Position in context.

Spinner

Progress

Skeleton

Loading States

Spinner for unknown duration. Progress bar when you know percentage. Skeleton screens preserve layout. Always show something is happening.

📭

No messages yet

Start a conversation to see messages here

Empty States

Empty states occur when there's no content. Explain why it's empty and what to do next. Include illustration and action button.

Priority

Errors: blocking, require action. Warnings: important, user decides. Success: brief confirmation. Info: contextual help.

Part B

Print vs Web

09

Static vs Interactive

Print layouts are static. Web components are interactive, responsive, and state-driven.

Navigation

Print

Table of Contents

Page 1, 2, 3...

Fixed page numbers, linear reading

Web

Click anywhere

Instant access

Links, menus, any-order access

Feedback

Print

📄

Static, no response

Reader gets no confirmation of actions

Web

✓

Real-time feedback

Immediate response to every action

Content

Print

Everything visible

What you see is all there is

All content always visible

Web

Progressive disclosure

Reveal on demand

Tabs, accordions, modals show/hide

Key Difference

Print has no states. Web components have hover, active, focus, disabled, loading, error, success states. Design for all of them.

Part C

Science & Psychology

10

Psychology of UI Components

Components work because they leverage cognitive patterns and learned behaviors.

☰

= Menu

×

= Close

🔍

= Search

Users already know these

Jakob's Law

Users spend most of their time on other sites. They expect your site to work like those sites. Follow conventions - don't make users think.

Looks clickable

Click me

Looks like a link

Visual Affordances

Components should look like what they do. Buttons look pressable. Links look clickable. Inputs look typeable. Don't break these expectations.

Loading...
✓Saved
✗Error
System Status

Nielsen's first heuristic: keep users informed. Every action needs feedback. Loading? Show spinner. Success? Confirm. Error? Explain.

RECALL

Type command...

_

RECOGNIZE

Click option:

Copy
Paste
Recognition vs Recall

Recognition is easier than recall. Show options rather than requiring users to remember them. Menus, dropdowns, and autocomplete all leverage this.

Core Principle

Components that match mental models feel intuitive. Components that break expectations feel frustrating. Follow the platform.

Part D

Real-World Examples

11

Real-World Components

How successful products implement common UI patterns.

🏠 Home

🔍 Search

📚 Library

Content

Principles Identified:
Persistent Sidebar Always visible, never hidden behind hamburger
Clear Icons Icon + label for clarity
Current State Active section highlighted

User Name 10:30 AM

Message content here...

Principles Identified:
Avatar Pattern Visual identifier for each user
Metadata Position Name and time inline, not separate
Hover Actions Reactions/menu appear on hover

Share

Messages

Mail

Principles Identified:
Bottom Sheet Slides up from bottom on mobile
Swipe Dismiss Drag down to close
Thumb Accessible Actions within easy reach

Pattern Library

Study established patterns: Material Design, Apple HIG, Ant Design. Consistency across apps creates user familiarity.

Part E

Common Failures

12

Component Failures

Common mistakes that break usability and accessibility.

Failure: Modal on Modal

Modal 2 over Modal 1

Fix: One modal at a time

Single focused modal

Failure: Hidden Navigation

Logo☰

Fix: Keep primary navigation visible

Logo
ProductsAbout

Failure: Focus Trap Escape

Modal with no close button

ESC doesn't work

Fix: Always allow escape from modals

Modal title×

ESC + X + backdrop click all close

Failure: No Loading State

Click... nothing happens... is it working?

Fix: Show feedback during async operations

User knows action is processing

Test

Can users always escape modals? Does every button show loading states? Is navigation findable? Can keyboard users access everything?

Part F

Visual Tests

13

Component Tests

Quick checks to ensure your components work correctly.

01

Keyboard Navigation

Tests: Accessibility

Tab through all interactive elements. Can you reach everything? Is tab order logical? Do modals trap focus correctly?

Tab → Tab → Tab

Every component reachable

02

State Coverage

Tests: Design Completeness

Does every component have: default, hover, focus, active, disabled, loading, error states? Screenshot each state.

defaulthoverfocusactivedisabled
03

Responsive Test

Tests: Layout

Resize browser from 320px to 1920px. Does navigation adapt? Do modals work on mobile? Do cards reflow correctly?

320px → 768px → 1920px

Test at each breakpoint

04

Screen Reader Test

Tests: Accessibility

Navigate with VoiceOver/NVDA. Are component names announced? Do alerts get read? Do tabs have correct roles?

"Navigation, list of 5 items"

"Home, link, 1 of 5"

Priority

Keyboard test catches 80% of accessibility issues. Run it first. State coverage ensures complete design. Responsive ensures it works everywhere.

Part G

CSS Implementation

14

Component Implementation

CSS and HTML patterns for building common components.

.card {
  background: var(--color-surface);
  border-radius: var(--radius-md);
  box-shadow: var(--shadow-sm);
  overflow: hidden;
}

.card--interactive {
  cursor: pointer;
  transition: box-shadow 0.2s, transform 0.2s;
}

.card--interactive:hover {
  box-shadow: var(--shadow-md);
  transform: translateY(-2px);
}

.card--interactive:focus-visible {
  outline: 2px solid var(--color-primary);
  outline-offset: 2px;
}
Card Component via CSS
  • Design tokens - Use variables for consistency
  • Modifier classes - card--interactive for clickable cards
  • Smooth transitions - 0.2s feels responsive
  • Focus visible - Only show outline on keyboard focus

  

    

      
      
    

    
Content
Modal Structure via CSS
  • - Native modal with built-in accessibility
  • method="dialog" - Form closes dialog on submit
  • aria-labelledby - Associates title with dialog
  • showModal() - Opens with backdrop and focus trap

  
  




Content 1
Tabs ARIA via CSS
  • role="tablist" - Container for tab buttons
  • aria-selected - Indicates active tab
  • aria-controls - Links tab to its panel
  • tabindex="-1" - Remove inactive tabs from tab order
.toast-container {
  position: fixed;
  bottom: 1rem;
  right: 1rem;
  z-index: var(--z-toast);
  display: grid;
  gap: 0.5rem;
}

.toast {
  background: var(--color-surface-inverse);
  color: var(--color-text-inverse);
  padding: 0.75rem 1rem;
  border-radius: var(--radius-sm);
  box-shadow: var(--shadow-lg);
  animation: slideIn 0.2s ease-out;
}

@keyframes slideIn {
  from {
    opacity: 0;
    transform: translateX(100%);
  }
}
Toast CSS via CSS
  • Fixed position - Always visible in viewport corner
  • High z-index - Above other content
  • Grid gap - Stack multiple toasts neatly
  • Animation - Slide in draws attention

Resources

WAI-ARIA Authoring Practices has exact patterns for tabs, modals, menus, etc. Follow them exactly for accessibility.

Part H

Self-Assessment

15

Self-Assessment

Test your understanding of UI component patterns.

Q1

When should you use a hamburger menu?

Click to reveal
Q2

What behaviors must a modal have for accessibility?

Click to reveal
Q3

What's the difference between toasts and alerts?

Click to reveal
Q4

Why should interactive cards avoid nested buttons?

Click to reveal
Q5

How do tabs work with keyboard navigation?

Click to reveal

Score

5/5: Ready for the next module

3-4/5: Review the sections above

1-2/5: Re-read core concepts

Key Takeaways

Follow established patterns
☰×🔍

Users already know how components should work. Novel patterns require learning. Follow conventions - don't make users think.

Design all component states

default → hover → focus →

active → disabled → loading

Every interactive component needs multiple states. Missing states feel broken. Design them all upfront.

Everything works with keyboard

Tab → Enter → Escape

If you can't Tab to it, keyboard users can't use it. Every interactive element needs focus states and keyboard activation.

Every action gets feedback

✓ Saved

Users need to know their actions registered. Loading states, success messages, error alerts - never leave users wondering.