FDIC Design System

Appearance

Content Page Recipes ​

Content-heavy pages need more than component examples. They need repeatable page structures that keep long reading, side navigation, filters, metadata, and related content understandable.

Guide

Use these recipes for news, articles, policy pages, and other authored content where the main task is reading, scanning, filtering, or moving through a section of content.

The examples are based on the FDICnet News Article and News Stories with Filters frames. They use existing components, semantic HTML, and the shared page-shell contract instead of creating a page-template component.

Current recipes ​

News article with sidebar — page header, section navigation, readable prose rail, cover image, topics, related stories, page feedback, and footer. View in Storybook →
News stories with filters — sidebar navigation, filter criteria, action row, and a dense headline list with metadata. View in Storybook →
Event detail page — leads with date, time, audience/location, primary actions, and a concise event description. View in Storybook →

When to use ​

  • Long-form news, policy, guidance, or editorial pages.
  • Event pages where date, time, location, description, and attendance actions must be visible without turning the page into a dense metadata card.
  • Section pages where a sidebar helps readers understand location and sibling pages.
  • News or archive pages where readers need keyword, topic, office, or date filtering.
  • CMS templates where authors need constrained layout choices instead of freeform spacer and column controls.

When not to use ​

  • Application screens where the main task is data entry or transaction completion.
  • Short landing pages or hub pages that work better with section bands and resource tiles.
  • Navigation that must behave like a disclosure tree, menu, or route-aware app shell. That should be promoted to a component only after the interaction contract is clear.

Layout contract ​

Use .fdic-content-layout inside a shell-aligned .fdic-page-band__content row. Use the standard fd-sidebar-nav component for local navigation; do not hand-build sidebar lists inside content recipes.

html
<section class="fdic-page-band" aria-label="Article content">
  <div class="fdic-page-band__content fdic-content-layout fdic-content-layout--detail-priority">
    <article class="fdic-content-layout__main prose" aria-label="Article title">
      <!-- article body -->
    </article>

    <div class="fdic-content-layout__sidebar">
      <div class="fdic-content-layout__sidebar-panel">
        <fd-sidebar-nav></fd-sidebar-nav>
      </div>

      <details class="fdic-content-layout__sidebar-disclosure">
        <summary>More in News & Events</summary>
        <div class="fdic-content-layout__sidebar-disclosure-body">
          <fd-sidebar-nav></fd-sidebar-nav>
        </div>
      </details>
    </div>
  </div>
</section>

The default layout uses a 320-ish sidebar rail and a readable content rail. At tablet and mobile widths, the sidebar stacks above the main content. Use .fdic-content-layout--detail-priority when the page's primary content needs to come before section navigation on narrow screens. In that modifier, the DOM order should put the main content before the sidebar; grid areas keep the sidebar in the left rail on desktop.

For detail-priority pages, keep the full local navigation visible on desktop, but use .fdic-content-layout__sidebar-disclosure to collapse the local navigation on narrow viewports. That keeps section navigation available without making it look like the next article section. Both placements should render fd-sidebar-nav from the same structured navigation data.

The narrow treatment uses the same native disclosure primitive documented in Details / Accordion, but it is a navigation placement pattern rather than prose accordion content. Do not wrap local navigation in .prose or hand-build an accordion list; keep fd-sidebar-nav as the navigation component inside the disclosure.

Use Sidebar Nav or Sidebar Menu for governed, repeated section navigation:

  • Pass structured root and items data so the component can render native lists and links consistently.
  • Pass currentHref or currentId from the current route. Do not mark multiple item objects as current.
  • Use the optional root for the web-area link shown above the divider.
  • Keep indentation shallow. The component supports four levels, but deeper trees usually need IA review.
  • Use Sidebar Nav when the route should determine the visible branch and unrelated descendants should be omitted.
  • Use Sidebar Menu when people need to expand and collapse sibling branches without leaving the page.
  • Do not use sidebar navigation for article table-of-contents links. Use the Prose table-of-contents pattern for in-page navigation.
  • Do not replace local navigation with prose accordions. If narrow viewports need a collapsed affordance, put the actual fd-sidebar-nav component inside a native disclosure wrapper.
  • Do not wrap the sidebar in aside when it sits inside main; the labeled nav is the meaningful landmark.

The .fdic-section-nav class remains available as a legacy recipe bridge or low-level fallback when a page cannot use the Web Component yet. New governed section navigation should prefer fd-sidebar-nav or fd-sidebar-menu, depending on whether the section needs user-controlled branch expansion.

Article pages ​

Article pages should keep the main story in .prose:

  • Use one page h1 in fd-page-header.
  • Start article body headings at h2.
  • Put author, office, and date metadata before the cover image when present.
  • Use .fdic-article-media for 16:9 cover images and captions.
  • Omit the topics block when there are no topics.
  • Keep related stories to a small set and use descriptive link text.

Event detail pages ​

Event detail pages should not bury attendance details in the article body, but they also should not repeat the same facts in multiple places. Put the date, time, location, concise description, and actions in .fdic-event-detail-summary:

  • Show the full date, time, and location as plain text.
  • Use an en dash for time ranges, such as 11 a.m.–Noon ET.
  • Include audience or category before the format when useful, such as FDIC-Wide | Virtual.
  • Put the primary join or registration action immediately after the date/location block.
  • Put secondary actions, such as Add to Outlook, next to the primary action when space allows.
  • Put the event description immediately after the action row.
  • Fold short delivery notes into one sentence, such as “Microsoft Teams link sent after registration,” instead of adding a separate alert.
  • Avoid repeating the same destination as both a primary button and a metadata row.
  • Add .fdic-content-layout--detail-priority to the content layout so the event details appear before sidebar navigation on mobile.
  • On narrow viewports, collapse the local navigation into a native details disclosure, such as “More in News & Events,” instead of rendering the full sidebar as a long block after the content.

The application or CMS still owns event data, calendar file generation, registration state, and meeting-link permission rules. The design system owns the layout, ordering, component choices, and semantic structure.

Filtered news lists ​

Use .fdic-content-filter for filter controls above a list of results:

  • Label the filter form with the visible heading.
  • Use fd-input for keyword search and fd-selector for constrained choices.
  • Keep actions in .fdic-content-filter__actions.
  • Keep results as a real ol or ul; use .fdic-headline-list for dense headline-and-metadata rows.
  • Provide an empty state when no results match. Do not leave a blank results area.

Filtering behavior belongs to the application or CMS integration. The design system owns the layout, spacing, semantics, and component composition.

Accessibility ​

  • Preserve landmark order: header, main, labeled section navigation, article or results section, feedback, footer.
  • Sidebar links must have unique labels or enough surrounding context to distinguish them.
  • Filter controls need visible labels and predictable reset behavior.
  • Event detail summaries must expose date, time, location, description, and actions as real text; do not rely on visual-only date blocks or icon-only controls.
  • Result counts and empty states should be announced in the application when filters update dynamically.
  • Images need useful alt text when they convey story content. Use empty alt only for decorative related-story thumbnails.
  • The layout must reflow without horizontal scrolling at 400% zoom and narrow mobile widths.