Review file explorers and other expandable tree interfaces so screen reader users can identify each item. Check descriptive names and expanded states, then suggest fixes using visible text or ARIA attributes, which provide information to assistive technology.
Use when applies to custom tree widgets built with role='tree', role='treeitem', and role='group'. Common in file explorers, nested navigation menus, org charts, and any UI where items can be expanded or collapsed to reveal children.
Review the names announced by screen readers and the expanded or collapsed states of items in file explorers and hierarchical menus. The skill targets items using role='treeitem' in interfaces where expanding an item reveals its children. It checks for names containing only whitespace and generic names such as “folder” or “item” that make entries difficult to distinguish. It then guides corrections using visible text, aria-label, or aria-labelledby.
Use it when implementing or reviewing a custom file browser, organization chart, or hierarchical navigation interface. For items with children, it also checks that aria-expanded is present and changes as the user expands or collapses the item. This lets you review information conveyed through speech that cannot be assessed from appearance alone.
There are no special notes.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.
The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 23, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Tree widgets represent hierarchical data (file explorers, nested navigation, organization charts). Screen readers announce each focused treeitem's name, level, and position — e.g., 'src, collapsed, level 1, 1 of 3'. If the name is empty or generic ('folder', 'item'), blind users cannot distinguish between nodes and cannot navigate the hierarchy with confidence. VoiceOver on macOS uses the name to populate the rotor, and NVDA reads it as the user moves through the tree with arrow keys.
role='treeitem' must have a non-empty accessible namearia-label to override or supplement the visible text (e.g., adding file type context)aria-labelledby to compose a name from multiple visible elements within the itemaria-expanded must also convey its expanded/collapsed state — this is separate from its nameFind all elements with role='treeitem'. For each, determine its accessible name via the accname computation: check aria-labelledby first, then aria-label, then visible text content. Flag any treeitem with an empty or whitespace-only accessible name. Also check whether treeitems with children have aria-expanded set to 'true' or 'false' (not just absent).
For each unnamed treeitem: (1) If the element has visible text content that is descriptive, no change is needed — the text content becomes the accessible name. (2) If the visible text is ambiguous (e.g., an icon with no text), add aria-label='Descriptive name'. (3) If the item has multiple text parts (e.g., filename + file size), use aria-labelledby referencing the most descriptive element's id. (4) For expandable treeitems, ensure aria-expanded='true' or aria-expanded='false' is present and toggled on expand/collapse.
WAI-ARIA 1.2 requires that treeitem elements have an accessible name as part of the tree widget pattern. Screen readers convey position within the tree using: name + level (aria-level or DOM nesting depth) + set size (aria-setsize) + position in set (aria-posinset) + expanded state (aria-expanded). The name is the only user-facing identifier — without it, a user navigating by arrow keys hears only 'treeitem, level 2' with no way to know which node they are on.
Review the rendered markup and interactive states that affect Provide accessible names for tree items. Flag exact elements, roles, labels, focus behavior, or keyboard interactions that violate the rule, and note how to verify the fix with browser accessibility tooling or assistive tech.
For full implementation details, code examples, and framework-specific guidance,
see references/rule.md.
Rule page: https://frontendchecklist.io/rules/accessibility/aria-treeitem-name
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Create and review custom 404 pages that help visitors recover from broken or moved links through search and navigation. Check the rendered page and HTTP response so missing content returns a proper 404 status.
Audit or create a dedicated About page that explains a website’s purpose and identifies its people or organization. Review the rendered output and supporting information, including expertise and contact details, to find gaps.
Review and add automated accessibility checks for components, pages, and continuous integration workflows. Use axe-based tools to detect structural and attribute issues, while identifying checks that still need keyboard or screen reader testing.
Review sign-in, registration, multi-factor authentication, and account recovery for accessibility barriers. Find blocked paste, difficult code entry, and inaccessible backup methods, then suggest authentication paths that support password managers, autofill, or device approval.
Review form errors, success messages, and live updates so screen reader users receive important notifications. Check the HTML delivered to the browser, announcement settings, display duration, and dismissal controls, then identify specific elements that need changes.
Review HTML tables so screen reader users can understand how headers and data relate. Check header markup, table descriptions, and merged cells, then identify specific fixes and ways to verify them.