You have spent the last two chapters building multi-page sites with shared navigation, headers, and footers. Your pages have structure. Your site has consistency. Now you need to fill those pages with well-designed, usable, and accessible content components.

This chapter introduces user interface patterns: repeatable solutions to common content problems. A card grid is a pattern. An image gallery is a pattern. An accordion that hides and shows answers to frequently asked questions is a pattern. A set of tabs that lets users switch between sections without leaving the page is a pattern.

Every website you visit uses these patterns. They work because they solve recurring problems in clear, learnable ways. Users recognize them. Developers can build and maintain them. When done well, they also work for keyboard users and screen reader users.

A user interface pattern, often called a UI pattern, is a proven, reusable solution to a common design and interaction problem.

Patterns are not invented from scratch every time a developer builds a website. They are learned from existing websites, refined over many years, and shared across the web development community. A card grid, an accordion, a modal dialog, a tab interface — these are patterns that millions of websites use because they work.

A pattern is a starting point, not a strict template. You can adapt the visual style of a card to fit your site. You can change the colors of a tab interface. You can expand or simplify an accordion. The structure and the behavior should remain recognizable, but the appearance is yours to design.

This chapter covers five core patterns that appear constantly in real web development:

• Card grids — displaying repeated content items in a structured grid
• Image galleries — displaying a collection of images in a browsable layout
• Show and hide behavior — toggling content visibility with JavaScript
• Accordions — a series of collapsible content panels
• Tabs — a set of labeled panels where only one panel is visible at a time

Each pattern uses HTML, CSS, and JavaScript together. You will see the full code for each one, learn how it works, and practice building your own.

A card is a self-contained content block that represents one item. A card typically includes a title, a short description, sometimes an image, and sometimes a link or button. Cards are grouped into a card grid: a layout that arranges multiple cards into rows and columns.

You have already used cards in earlier chapters. This section treats them more completely, including the HTML structure, the CSS grid layout, the hover behavior, and the responsive adjustments.

A single card is an <article> element (or a <div> when the content is not independently meaningful). It contains the card's internal content.

Each part of the card has its own class. The outer element gets card. The text content area gets card-body. The heading gets card-title. The description gets card-description. The link gets card-link.

Using these specific classes makes your CSS much more predictable. You can style .card-title without accidentally affecting other headings on the page.

Cards live inside a grid wrapper:

The <section> wraps the whole pattern and carries a label through aria-labelledby. This gives screen reader users a clear landmark for the cards section.

The grid layout uses display: grid with repeat() and minmax() so the columns adjust automatically as the screen width changes:

auto-fill tells the grid to fit as many columns as possible. minmax(280px, 1fr) means each column is at least 280 pixels wide and can grow to fill available space. On a wide screen you get three or four columns. On a tablet you get two. On a narrow phone you get one. No media queries are needed for this basic adaptation.

There are a few important techniques here.

flex-direction: column on .card stacks the image and card body vertically. flex: 1 on .card-body makes the body grow to fill available space, so all cards in a row reach the same height regardless of how much text they contain. flex: 1 on .card-description pushes the link to the bottom of the card body.

aspect-ratio: 16 / 9 on the image forces a consistent image shape. object-fit: cover crops the image to fill that shape without distorting it.

The hover state with transform: translateY(-2px) gives a subtle lift effect when the user hovers over a card.

Not every card needs an image. When your content is text-only, simply omit the <img> tag:

The CSS works the same way. The card body fills the full card when there is no image.

Sometimes the entire card should be clickable, not just the link inside it. This is common for content cards where every element leads to the same destination. You can wrap the card in an <a> element:

When you do this, the <a> element takes the role of the card. Change the CSS to apply the card styles to a.card instead. Be careful with display: block on the <a> element so it fills its grid cell correctly.

An image gallery displays a collection of photographs, illustrations, or other images in a browsable grid. Galleries appear on portfolio sites, product pages, event pages, and any site that needs to present many images together.

The simplest form of gallery is a CSS grid of images with no JavaScript:

Each image is wrapped in a <figure> with a <figcaption>. This is the correct semantic structure for images that have captions. The alt attribute on each image provides a text description for screen reader users and for browsers that cannot load the image.

The overflow: hidden on .gallery-item combined with transform: scale(1.04) on the image creates a zoom effect when the user hovers. Because the parent clips overflow, the image enlarges inside its container rather than overflowing into neighboring cells.

Gallery images require careful alt text. The alt text should describe what the image shows in a way that is useful to someone who cannot see it.

A more advanced gallery lets users click a thumbnail to see a larger version. This is called a lightbox pattern. Building a full lightbox from scratch goes beyond this chapter, but here is a simple version using a <dialog> element, which is the modern, accessible HTML element for modal content.

Before you can understand accordions and tabs, you need to understand the simpler pattern underneath both of them: show and hide behavior.

Show and hide behavior means: a piece of content is initially hidden. When the user clicks a button or trigger, the content becomes visible. When they click again, it hides.

This pattern appears everywhere on the web. Navigation menus on mobile, dropdown filters, expandable product descriptions, collapsible sidebars, and more all use some form of show and hide.

The HTML contains a button and a content panel. The content panel starts hidden:

The hidden attribute on the panel makes it invisible by default. The browser applies display: none to elements with the hidden attribute, which removes them from the visual layout and from the accessibility tree.

The aria-expanded="false" attribute on the button tells screen reader users that this button controls a collapsible section, and that the section is currently collapsed. The aria-controls attribute connects the button to the panel by referencing the panel's id.

The JavaScript reads the current aria-expanded value to decide what state the toggle is in. If it is currently expanded, it hides the panel and sets expanded to false. If it is currently collapsed, it shows the panel and sets expanded to true. The button text updates to reflect the current action.

An alternative to the hidden attribute is toggling a CSS class. This approach gives you more control over visual transitions:

The max-height transition technique is a common CSS trick for animating content expansion. Setting max-height: 0 with overflow: hidden collapses the panel. Setting max-height to a large value with a transition animates the opening.

An accordion is a list of items where each item has a header and a collapsible content panel. Only some panels are open at a time. Users can click a header to open its panel and collapse it again.

Accordions are common for:

• Frequently asked questions (FAQ sections)
• Product feature details
• Legal terms and conditions
• Course topic outlines
• Help and support pages

There are several important structural choices here.

The trigger is a <button> inside an <h3>. This means the heading is still a real heading in the document outline and can be navigated to by screen reader users using heading navigation. The button handles the click interaction.

The aria-expanded attribute on each button starts as "false" because all panels are closed by default.

The aria-controls attribute connects each button to its panel via the panel's id.

The icon <span> has aria-hidden="true" because it is purely decorative. The plus or minus sign does not add information to a screen reader user who already hears "collapsed" or "expanded" from aria-expanded.

The all: unset on .accordion-trigger removes all default button styles so you can style it freely. You must add back the properties you need, including cursor: pointer, which all: unset removes.

The icon rotation uses the aria-expanded="true" attribute as a CSS selector: .accordion-trigger[aria-expanded="true"] .accordion-icon. This means you do not need to add or remove a class to rotate the icon. When the button's aria-expanded attribute changes in JavaScript, the CSS automatically updates the icon's appearance. This is an elegant approach because the visual state is always derived from the accessibility state.

This code handles a single-open accordion: only one panel can be open at a time. When the user opens a new panel, all other panels close. This is the most common accordion behavior.

If you prefer to allow multiple panels to be open simultaneously, remove the loop that closes other panels. Multi-open accordions are less common but appropriate when users might need to compare content across multiple panels.

Now if the user clicks the same button again:

• isExpanded is now "true". So isExpanded === "true" is true.
• The code sets aria-expanded back to "false" and panel.hidden = true.
• The panel disappears. The icon rotates back to a + shape.

A tab interface presents several panels of content. Only one panel is visible at a time. A row of tab buttons at the top lets the user switch between panels. Clicking a tab makes its panel visible and hides all other panels.

Tabs are useful when you have related but distinct content that would be too long to show all at once: for example, different lesson topics, different product specifications, or different sections of a guide.

The HTML for a tab interface uses role attributes to communicate the pattern to screen readers. Tabs are one of the patterns that has a specific ARIA role structure:

There is more ARIA here than in the accordion. Here is what each piece does.

You navigate between tabs using the arrow keys. This is the expected keyboard behavior for tabs as defined by the ARIA specification. The active panel has no hidden attribute. All other panels start with hidden.

Like the accordion, the active tab style uses an attribute selector: .tab-button[aria-selected="true"]. The active tab gets a bottom border in the accent color. This is the most common visual indicator for the active tab.

Tabs require slightly more JavaScript than accordions because of arrow key navigation:

The activateTab() function is a helper that handles both mouse and keyboard activation. It deactivates all tabs, hides all panels, activates the target tab, and shows its panel.

The arrow key logic uses the % modulo operator to wrap around. If the user presses ArrowRight while on the last tab, (index + 1) % tabButtons.length wraps back to 0, activating the first tab. If the user presses ArrowLeft while on the first tab, (index - 1 + tabButtons.length) % tabButtons.length wraps to the last tab.

Home and End keys jump to the first and last tabs respectively. These are standard keyboard behaviors for the tab pattern.

You have seen class toggling throughout this chapter. The .is-open class on accordion panels, the aria-expanded attribute selector for icon rotation, the aria-selected attribute selector for tab styling — all of these depend on JavaScript changing attributes or classes in response to user interaction.

Class toggling means adding or removing a CSS class on an element. JavaScript's classList API makes this easy.

classList.toggle() is especially useful for simple show/hide patterns because it handles the check automatically.

A very common use of class toggling is the mobile navigation menu. On small screens, the navigation is hidden. Clicking a hamburger button reveals it.

On small screens, the navigation starts without the is-open class and is hidden. Clicking the toggle button adds the class, making the navigation visible. Clicking again removes the class and hides it. The aria-expanded attribute keeps screen reader users informed of the current state.

Every interactive pattern you build should work without a mouse. Many users navigate entirely by keyboard: people with motor impairments, power users who prefer keyboard efficiency, and screen reader users who navigate with a keyboard.

You do not need to handle every keyboard edge case in an introductory course, but you should understand the basics.

The Tab key moves focus forward through focusable elements on the page. Shift + Tab moves focus backward. Focusable elements include links, buttons, form inputs, and any element with tabindex="0".

When you build a button or link, it is automatically keyboard-accessible because the browser handles Tab focus, Enter key activation, and Space key activation for you. Using <button> elements instead of <div> or <span> elements for interactive controls is one of the most important accessibility habits you can develop.

Buttons can be activated with both Enter and Space. Links can be activated with Enter. This behavior is built into the HTML elements. If you use a <div> as a button and add a click listener, keyboard users pressing Enter or Space will not activate it unless you add extra JavaScript.

This is why using semantic HTML elements for interactive controls is not just a good idea — it is essential for accessibility.

When a keyboard user presses Tab and moves focus to a button, the browser shows a focus indicator — typically a colored outline around the button. This indicator is critical. Without it, keyboard users cannot tell where focus is on the page.

The :focus-visible pseudo-class applies focus styles only when the browser determines the user is navigating by keyboard, not when they click with a mouse. This means mouse users do not see a focus ring after clicking, while keyboard users always do.

Some patterns have their own keyboard navigation beyond Tab. The tab interface in Section 27.6 uses arrow keys to move between tabs within the tab list. This is the standard behavior for the ARIA tab pattern.

The reason is usability: if each tab were individually Tab-focusable, a tab interface with ten tabs would require ten Tab presses to move through. Arrow keys allow faster navigation within a widget while Tab moves focus to and from the widget as a whole.

You do not need to implement arrow key navigation for every component in this course. But understanding that some patterns have their own keyboard conventions prepares you for more advanced work later.

You have seen accessibility considerations throughout this chapter. This section collects those practices and explains the reasoning behind them.

The single most effective accessibility habit is using the correct HTML element for the purpose.

Use <button> for controls that do something on the current page. Use <a> for links that navigate to another page or location. Do not use <div>, <span>, or other non-semantic elements as interactive controls.

Using <button> gives you keyboard focus, Enter and Space activation, and screen reader announcement all automatically.

Screen reader users hear the label of every button and link. "Click here" and "Read more" are not useful labels. "Open navigation menu", "Close image viewer", "Show answer to: What is HTML?" — these labels tell the user exactly what the control does.

Use aria-label to provide a label when the visual text is insufficient or when the button contains only an icon. Use aria-labelledby to connect an element to a nearby heading that serves as its label.

When you change the state of an interactive component, update the ARIA attributes:

• Toggle aria-expanded when you open and close accordions, menus, and dialogs
• Toggle aria-selected when you change the active tab
• Toggle aria-hidden when you hide content from screen readers

Screen readers read ARIA attribute values as users interact. If you open an accordion but forget to update aria-expanded, screen reader users will hear "collapsed" even though the panel is open.

Using visibility: hidden, display: none, or the hidden attribute hides content from both visual and screen reader users. This is appropriate for panels that are genuinely closed. But do not use these techniques to hide content that keyboard users should still be able to reach — for example, skip navigation links that let keyboard users jump past the header.

A skip navigation link is an anchor link placed before the header that jumps to the main content. It is visually hidden by default but becomes visible when it receives keyboard focus:

When a keyboard user presses Tab on page load, the skip link appears. If they press Enter, focus jumps to the main content area, skipping the header and navigation. This is a small addition that makes a significant difference for keyboard and screen reader users.

User interface patterns are tools. Like any tool, they work well for the right job and poorly for the wrong one. Learning when to use a pattern is as important as learning how to build it.

A page with too many patterns — a card grid inside an accordion inside a tabbed interface — becomes exhausting to use. Restraint in pattern use is a design skill, not a limitation.

Here is a complete, working FAQ accordion you can adapt for your own project.

The JavaScript is wrapped in an immediately-invoked function expression (IIFE): (function() { ... }()). This is a common pattern for wrapping a block of JavaScript so its variables do not pollute the global scope. You will learn more about scope and IIFEs in later JavaScript courses, but the important thing to know now is that this wrapper prevents naming conflicts when multiple JavaScript files are used on the same page.

Your running project now has a Lessons page and a Resources page. This chapter's patterns fit naturally into your site.

User interface patterns are repeatable solutions to common content and interaction problems. They work because users recognize them, developers can build and improve them, and the accessibility community has documented how they should behave.