Focus State Behavior for v3 List Items Appears Unexpected

[AdamWMoqrane]

Description

The focus states for v3 List components are inconsistent, leading to alignment issues and unexpected focus behavior. This problem seems related to the structure of the component and the keyboard navigation of each "table cell" within the List. This issue persists even when using the icon-start property introduced in 3.0.

User Stories

As a product designer working with List components, I want the focus states to be standardized and consistent so that users have a predictable and accessible experience when navigating through list items.

Acceptance Criteria

• The focus behavior for List components works consistently across all focusable areas (icon, label, and actions).
• Misalignment issues caused by fractional pixel rendering or hitbox inconsistencies are resolved.
• Keyboard navigation within "table cells" behaves as expected.
• Switching to the content-start or icon-start slots does not introduce misaligned or unintended focus behavior.

Relevant Info

• Repro Steps:
  1. Use icon-start with v3 List components.
  2. Observe the focus states and alignment when interacting with the List items.
• Codepen Example: Link to Codepen provided by @adam
• Additional Observations: Misalignment appears fractional depending on the component's internal structure and click targets.

Helpful Details

• The icons were placed in the default content-start slots, which exacerbates the misalignment issues.
• Swapping to the icon-start slot improves alignment slightly but does not completely resolve focus behavior.
• Conversations referenced:
  • Adam Moqrane, Adam Tirella, Paul Coster, Aaron Shetland (see screenshots).

Priority impact

impact - p1 - need for current milestone

Esri team

ArcGIS Knowledge

[github-actions]

cc @ashetland, @SkyeSeitz, @brittneytewks

[ashetland]

@geospatialem I think this focus behavior should be categorized as a bug and I think it's been with us for while. I believe this is the focus state in question where only the content area is focused:

Ideally, focus should only be on the entire item or interactive elements, such as the drag handle, close button, or slotted actions.

[geospatialem]

Confirmed with @ashetland this has been occurring for a while, at least since 2.6 and in our latest 2.13, but this is something we'd like to address ASAP, ideally for 3.0, but if not, shortly thereafter.

[driskull]

This should follow the treegrid role guidelines. https://www.w3.org/WAI/ARIA/apg/patterns/treegrid/examples/treegrid-1/#exampleusageoptions

For example, our options are:

Rows are focused first, but cells can be focused:
Useful when the desired experience is for the treegrid to act primarily like a tree where each row is treated like a node in a tree, but it is still possible for users to navigate across the cells in a row.
Cells are focused first, but rows can be focused:
Useful when the desired experience is for the treegrid to act primarily like a grid where arrow keys move among cells, but it is still possible for users to focus a row and then start navigating the structure like a tree.
Only cells can be focused:
Useful when the desired experience is that the treegrid act primarily like a grid and there is no need to focus complete rows.

[driskull]

Ideally, focus should only be on the entire item or interactive elements, such as the drag handle, close button, or slotted actions.

I think the treegrid role requires cells to be focusable.

Note: A row-only option is not provided. A treegrid where cells cannot be focused would be implemented as a tree view. A treeview that has columns in its visual presentation may be appropriate when all the following conditions are present:

[AdamWMoqrane]

Thanks for the insight, @driskull. While the W3C guidelines are valuable for true table structures, these components lack distinct columns or cells, so applying table-based focus behavior feels misaligned. Focus states here should prioritize the component’s interactive elements rather than mimic treegrid conventions. Thoughts?

[driskull]

@AdamWMoqrane this component is using and following the treegrid role for accessibility purposes. It does have cells for actions and content. Interactivity needs to be based on proper roles for accessibility compliance. As far as I'm aware, there isn't a better role here.

[ashetland]

I may be reading the spec wrong, but in the "rows first" scenario it implies to me that cells can be focused, but not that they have to be. Is it be possible to exclude some cells from focus and not wreak havoc with AT?

[driskull]

It seems like all cells need to be focusable. We can adjust what a cell is if need be.

What I think we could do that would make this less noticable is to only focus on the row when a cell is clicked and not a cell. A user would need to use the keyboard arrows to get to a specific cell. That seems to be what they are doing in the demo.

[ashetland]

Seems like an approach we could test out. Thanks for digging into this @driskull!

[sagewall]

This is also showing up in the JS SDK LayerList

[github-actions]

Installed and assigned for verification.