An accordion suits one level of sections on a single page, each with content inside. A tree suits deep hierarchies where folders contain folders, like a file system or an org chart. Past two levels of nesting, accordion stacking becomes unwieldy.

Should clicking a folder also select it?

Pick one model and keep it. File explorers usually select on click and expand on chevron or double-click. Some admin trees select the folder row when clicked and load folder metadata. Document the rule in the product so expand and select never fight the same click.

How deep can a tree go?

Technically any depth, practically about four levels before indent eats the content column. Figma's layer list scrolls horizontally when indent runs long. Consider breadcrumbs above the tree for very deep paths.

What keyboard support does a tree need?

The WAI-ARIA Authoring Practices define a tree pattern: arrow keys move between items, Right opens a closed folder or moves into children, Left closes or moves to parent. If you ship arrow keys, follow that pattern so muscle memory from other trees still works.

Icons for folders and files?

Folder and document icons are convention. Keep them muted so the label stays primary. Colour alone should not distinguish types (WCAG 1.4.1): the icon shape and the word folder or file in the name carry the meaning.

Scroll the whole tree or each branch?

Scroll the whole tree in one viewport, with sticky section labels only when you group unrelated roots. Per-branch scroll regions trap keyboard focus and confuse scroll wheels on trackpads.

Tree

A tree shows nested items with folders that expand and files that select. It is built for hierarchy that goes more than one level deep.

Structure and navigationBuild difficulty: Hard<ul role="tree">

Also called Tree view, Folder tree, Hierarchy tree.

logo

Preview area for the selected file.

Open and close folders with the chevron. Click a file to select it. Arrow on a folder rotates when open. Tab moves through triggers and file rows.

For designers

A tree is how file pickers, layer lists and permission editors show structure without flattening it. Folders hide their children until opened, which keeps a thousand files manageable in one panel.

The cost is interaction complexity. Expand, collapse, select and sometimes drag each need a clear rule. A tree that reimplements half of the WAI-ARIA tree pattern with different keys will feel broken to anyone who uses VS Code or Finder daily.

VS Code's explorer is the benchmark many developers carry. Click chevron to expand, click name to select, arrow keys move the highlight. Your tree does not need every power feature, but diverging on the basics creates support tickets.

Use a tree when

Items nest more than one level, like files inside folders inside projects
People need to see the hierarchy and open only the branches they care about
Selection and expansion are separate: opening a folder does not always open a file

Reach for something else when

Every section is one level deep and nothing nests further. Use an accordion instead.
The data is a flat stack of peers with no parent-child relationship. Use a list instead.
People only pick one leaf and never browse the structure. Use a combobox instead.

Variants

Closed

Projects

Open

ProjectsHomepage copy.md

Selected

Logo concepts.pdf

Folder closed, folder open with children visible, and a selected file row.

Closed folder. Chevron points right, children hidden.

Open folder. Chevron rotates, children indented one step.

Selected file. Background fill on the leaf row, folder rows stay neutral unless folder selection is part of your model.

How to build a tree

Use a tree role on the root list, treeitem on each row, and group on nested lists. Folders toggle expanded with aria-expanded.

<ul role="tree" aria-label="Files">
  <li role="treeitem" aria-expanded="true">
    <button type="button">Projects</button>
    <ul role="group">
      <li role="treeitem" aria-expanded="false">
        <button type="button">Brand refresh</button>
      </li>
      <li role="treeitem">
        <button type="button">Logo concepts.pdf</button>
      </li>
    </ul>
  </li>
</ul>

Arrow key handling is the piece most prototypes skip. If you add it, follow the WAI-ARIA tree pattern so Right opens, Left closes and Up and Down move between visible rows. Tab should leave the tree and move to the next control outside it, not visit every row.

Indent children with padding, not nested margin on every icon, so deep trees can scroll horizontally when indent exceeds the panel width.

Search inside large trees is common: filter visible nodes while keeping parent folders open when a child matches. Announce how many results matched so people know the filter worked. Clearing search should restore the previous expand state if you changed it during the filter.

Lazy loading children on first expand keeps the initial tree fast. Show a loading row inside the folder, not a spinner that replaces the whole panel.

Edge cases

Loading children. Show a spinner or skeleton on the folder row while children fetch. Do not collapse the folder on error without a message.

Empty folders. Say Empty in the group or disable expand when there are no children, so open does nothing confusing.

Reduced motion. Chevron rotation can animate. Under prefers-reduced-motion: reduce, snap between open and closed angles.

Drag and drop. Reordering tree nodes adds a second interaction model on top of expand and select. If you ship drag, keep a non-drag path for keyboard users and document the grab handle separately from the expand chevron.

Common questions

Tree or accordion?: An accordion suits one level of sections on a single page, each with content inside. A tree suits deep hierarchies where folders contain folders, like a file system or an org chart. Past two levels of nesting, accordion stacking becomes unwieldy.
Should clicking a folder also select it?: Pick one model and keep it. File explorers usually select on click and expand on chevron or double-click. Some admin trees select the folder row when clicked and load folder metadata. Document the rule in the product so expand and select never fight the same click.
How deep can a tree go?: Technically any depth, practically about four levels before indent eats the content column. Figma's layer list scrolls horizontally when indent runs long. Consider breadcrumbs above the tree for very deep paths.
What keyboard support does a tree need?: The WAI-ARIA Authoring Practices define a tree pattern: arrow keys move between items, Right opens a closed folder or moves into children, Left closes or moves to parent. If you ship arrow keys, follow that pattern so muscle memory from other trees still works.
Icons for folders and files?: Folder and document icons are convention. Keep them muted so the label stays primary. Colour alone should not distinguish types (WCAG 1.4.1): the icon shape and the word folder or file in the name carry the meaning.
Scroll the whole tree or each branch?: Scroll the whole tree in one viewport, with sticky section labels only when you group unrelated roots. Per-branch scroll regions trap keyboard focus and confuse scroll wheels on trackpads.

Last reviewed 26 AUG 2026