Components

Details

Use with caution: candidate Web

The Details component reveals optional, supporting information that isn't required for most users to complete a task. It is used to provide plain language help at the point where it is most relevant.

Examples

Default

View va-details default in Storybook

Different widths

Use a reduced width when you need Details to take up less space on the page.

View va-details widths in Storybook

Usage

When to use Details

Revealing helpful background information. Use this component when you have additional information about an application, process, or form step that isn’t critical. Use this component in instances where a more prominent Alert wouldn’t be appropriate.
Explaining the impact of a choice. If a user’s answer will significantly affect their results or next steps, use Details to put that explanation right next to the relevant field.
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 only loosely related, use an Accordion instead.
Clarifying a form question. If a form question needs clarification, and that clarification is brief, use Details. The lighter design doesn’t interrupt the flow of the form. These can also serve as an alternative when Accordions feel too heavy or when hint text isn’t enough. Be sure to review the hint text guidance for more information.
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. The Details component can hide information that doesn’t apply 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, use an Accordion instead. For example, a series of FAQ questions or a set of payment options that each have additional information.
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 Information Architecture (IA) team to edit content and explore alternatives.
Required content. If most people need the content to accomplish the main task, don’t hide it from view.
Content organized under a new heading. If the content warrants a new heading that doesn’t belong under the same heading as nearby content, use an Accordion instead.
Error messages or other immediate actions. Don’t 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. See placement guidance on this page for more information.

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

How this component works

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. This component requires no JavaScript 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 Accessible Rich Internet Applications (ARIA) attributes, following web standards universally supported across browsers.

Placement

You can use Details in these places:

After a header (h2, h3, or h4) or paragraph to provide supplementary information or answer 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
When you need to help users understand a particular choice

Note: Placement of Details doesn’t change the content considerations for this component.

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 label of the component. Framing help text as questions can confuse people who expect questions to ask for their input. 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, use 1 or more Accordions instead. You can also include a brief overview in Details with a link to a page that has more detail. Collaborate with a member of the Content and Information Architecture team to edit content and explore alternatives.
Use lists in expanded content as needed. Use numbered (ordered) and bulleted (unordered) lists to make content easier to scan.

Accessibility considerations

Wrap content in HTML elements. Place all text content inside va-details within an appropriate HTML element such as <p>, <span>, or <div>. Some screen readers, particularly NonVisual Desktop Access (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.
Don’t 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.
Native keyboard interaction. Users can tab to the component and toggle it open or closed with Enter or Space. If the component contains interactive elements, the next Tab keypress moves focus to those 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: Apr 10, 2026