Components

Details

Use with caution: candidate

USWDS v3 Web

Details makes content easier to scan as it hides information that may not be applicable to all users or situations. We use the Details component to situate plain language help at the point of the process where it is most relevant.

Examples

Default

View va-details default in Storybook

Different widths

Use the Details component with a reduced width when you need the Details component to have less visual space on the page.

View va-details widths in Storybook

Usage

When to use Details

Revealing helpful background information: When you have additional information you want to convey about an application, process, or a step or question in a form that is not critical. This component should be used in instances where a more prominent Alert would not be appropriate.
Clarifying outcomes for an input: In cases where a person’s input can have large or complicated impact on outcomes we use contextual help in Details to locate expanded guidance next to the relevant interaction.
Information closely tied to an input. Use this component over an Accordion when the content is closely tied to a particular message or input on the screen. If the content is more tangentially related then use an Accordion.
Clarifying a form question: If a form question needs clarification, and that clarification is brief, use Details. The lighter design prevents breaking up the visual progression as the user navigates the form. These can also serve as alternative to where accordions feel too heavy. Be sure to review the hint text guidance for implementation details. If a form is a conversation, Details would be considered an aside. (This case study on structuring complex health care questions for healthcare.gov goes into greater detail on how to structure your form as a conversation.)
Content that can be organized under the current heading. If you have additional content that provides context and makes sense under the same heading as the content nearby.
Information not applicable to all: Details can hide details that may not be applicable to all users.

When to consider something else

Accordions for a series: If you have a series of content in the body of a page and outside of a form or tool then an Accordion is preferred. For example, if you have a series of questions as part of an FAQ section or a set of options for payment that each have additional details.
Too much content: Only include critical information inside this component. This includes form fields that require a lot of explanation. Link to another page, consider an Accordion, or shorten the content. Collaborate with a member of the Content and IA team to edit content and explore alternatives.
Required content: If the majority of people need the content to accomplish the main task then it should not be hidden from view.
Content organized under a new heading. If you have enough content that it makes sense to organize under a new heading that does not make sense under the same heading as the content nearby then use an Accordion.
Error messages or other immediate actions: Do not use this component for error messages or other critical or timely information.
Inside Alerts: Use this component inside an Alert only as a last resort and if approved in the Collaboration Cycle. Instead use the Alert - Expandable component, especially when the Alert is within the page content and not at the top of the page.
Floating in space: Try to avoid using Details outside of the flow of the page, unattached to a section of content or another component. For example, there are instances of Details between a h1 and a Card. See placement for more.

Choosing the right component for forms

When deciding which component to use inside a form, consider how essential the information is and how it relates to nearby content:

Essential information for form fields: Use hint text for brief, critical information that most users need to complete a field successfully.
Helpful context tied to specific content: Use Details for brief explanations related to nearby form fields or sections that users can access when needed.
Substantial standalone information: Use Accordion for lengthy content that deserves its own heading or multiple related topics like FAQ sections.

Decision tree

Decision flowchart for choosing between Details, hint text, or Accordion components when used inside a form.

Loading chart...

flowchart TD Start["What type of additional information
do you need to provide?"]:::node-start --> Q1{"Is this information essential
for completing a form field?"}:::node-question Q1 --> Essential(["YES
Field requirements,
input patterns"]):::node-answer-primary Essential --> ResultHint(["Use HINT TEXT"]):::node-result-button Q1 --> NonEssential(["NO
Background context,
helpful clarifications"]):::node-answer-secondary NonEssential --> Q2{"Is content related to a
nearby form field or section?"}:::node-question Q2 --> DirectlyRelated(["YES
Why we ask questions,
field-specific help"]):::node-answer-primary DirectlyRelated --> Q3{"Is content brief and
doesn't need a heading?"}:::node-question Q3 --> Brief(["YES
Short explanations,
simple clarifications"]):::node-answer-primary Brief --> ResultDetails(["Use DETAILS"]):::node-result-link Q3 --> NotBrief(["NO
Long content,
complex explanations"]):::node-answer-secondary NotBrief --> ResultAccordion1(["Use ACCORDION"]):::node-result-action Q2 --> NotDirectlyRelated(["NO
General information,
standalone topics"]):::node-answer-secondary NotDirectlyRelated --> ResultAccordion2(["Use ACCORDION"]):::node-result-action

Text-based decision guide

Is this information essential for completing a form field?
- Yes (Field requirements, input patterns) → Use hint text
- No (Background context, helpful clarifications) → Continue to question 2
Is content related to a nearby form field or section?
- Yes (Why we ask questions, field-specific help) → Continue to question 3
- No (General information, standalone topics) → Use Accordion
Is content brief and doesn't need a heading?
- Yes (Short explanations, simple clarifications) → Use Details
- No (Long content, complex explanations) → Use Accordion

Behavior

The Details component uses native HTML <details> and <summary> elements, which provide several advantages over JavaScript-based implementations:

Searchable and discoverable content: Browser search (Ctrl+F or Cmd+F) can find text inside collapsed Details, and search engines can index the content for better search engine optimization (SEO).
Better performance and reliability: No JavaScript required for basic functionality, improving load times and ensuring content works even when JavaScript fails.
Enhanced accessibility: Native semantic meaning provides better assistive technology support without additional ARIA attributes, following web standards universally supported across browsers.

Placement

The following are places where Details can be used:

After a header (h2, h3, h4) or paragraph to provide orthogonal details or provide an answer to a common question.
Within a Process list to shorten the length of content within a step.
Within, or at the end, of a Form to provide additional help text.
Whenever there is a chance to enhance the understanding a user has about a particular choice.

Note: Placement does not alter content considerations in any way.

Code usage

Web

Attributes and Properties

Property Attribute Type Default Description

label label string

The text for the summary element that triggers the details to expand.

width width "2xl" | "xl"

Displays the component at a specific width. Accepts xl (40ex) or 2xl (50ex).

Content considerations

Use a statement, rather than a question. Use a statement (like “Why we ask for this information”) rather than a question (like “Why does VA ask for this information?”) for the title (trigger text) of the component. Because we use questions to gather information from people in our forms, structuring additional information as questions as well can cause confusion. Keep titles to a single sentence or sentence fragment with no ending punctuation.
Limit the amount of expanded content. Limit content to fewer than 500 characters (with spaces) when possible. If you need to provide more information, consider using one or more Accordions instead or providing a brief overview in the Details component with a link to another page with more information. Collaborate with a member of the Content and Information Architecture team to edit content and explore alternatives.
Use lists in expanded content as needed. To make content easier to scan, we encourage you to use numbered (also called “ordered”) and bulleted (also called “unordered”) lists as needed.

Accessibility considerations

Wrap content in HTML elements. All text content inside va-details must be wrapped in an appropriate HTML element such as <p>, <span>, or <div>. Some screen readers, particularly NVDA, may ignore unwrapped plain text. For example, use <p>This is the content.</p> instead of placing text directly inside the component without a wrapper element.
Do not add ARIA roles or state attributes. The details component uses the <details> HTML element that exposes expanded/collapsed state and interactive behavior natively. Adding any role="button" or aria-expanded is redundant and can create conflicting announcements in assistive technology.
Keyboard interaction is provided natively. Users must be able to tab to the component, toggle it using Enter or Space, and if there are interactive elements in the component, the next tab takes them to those interactive elements.

Component checklist

Web Platform

69%

9 of 13 complete

Updated: February 02, 2026

Maturity

Guidance: Web

Examples, usage, code usage, content considerations, and accessibility considerations are all complete.
Research: Web

VFS team conducted research on this component which is linked from this page.
Stability: Web

Component has been in production for more than 3 months with no significant issues found.
Adoption: Web

Multiple teams have adopted this component.

Accessibility

For more information on each category, see Accessibility testing for design system components.

Platform: Web

Last audit date: This category has not been tested.

Code review: This category has not been tested.

Readability: This category has not been tested.

Automated scans: This category has not been tested.

Use of color: This category has not been tested.

Text resizing, zoom, and magnification: This category has not been tested.

Screen readers: This category has not been tested.

Input and interaction methods: This category has not been tested.

Code assets

Variations: Web

Storybook includes all variations (style, size, orientation, optional iconography, selection, error state, etc.)
Responsive: Web

Component depicted in all responsive breakpoints.
Interactive states: Web

Includes all interactive states that are applicable (hover, active, focus, keyboard focus, disabled).
Tokens: Web

All design attributes (color, typography, layout, etc.) are available as tokens.
Internationalization: Web

Describes i18n attributes.

Visual assets

Variations: Web

Figma library includes all variations (style, size, orientation, optional iconography, selection, error state, etc.)
Responsive: Web

Component designed to work in all responsive breakpoints.
Interactive states: Web

Includes all interactive states that are applicable (hover, active, focus, keyboard focus, disabled).
Tokens: Web

All design attributes (color, typography, layout, etc.) are available as tokens.

Legend:

Complete
Incomplete
N/A Not applicable

Provide feedback

Share your feedback, report issues, or suggest improvements for the Details component. Your input helps us make the design system better for everyone.

Get immediate support in #platform-design-system for technical or urgent issues.
Explore all feedback channels for additional ways to share your input.

Edit this page in GitHub (Permissions required)

Last updated: Mar 18, 2026