topic Re: LayerList Tab Order and WCAG in ArcGIS JavaScript Maps SDK Questions

LayerList Tab Order and WCAG

D_Atkins — Wed, 13 May 2026 12:01:37 GMT

Working on WCAG guidelines for some public applications, and was surprised when I struggled to expand a Group Layer in the Layer List. The behavior is consistent across browsers:

When tabbing through the Layer List, the tab order skips the group layer 'carat'. Even if there is another keyboard shortcut here, it seems the intuitive "tab to carat, then enter-key to toggle group visibility" is missing.

Everything else is accessible (even the dragEnabled buttons, and custom ActionButtons); see in a CodePen: LayerList Tab Order

Re: LayerList Tab Order and WCAG

Sage_Wall — Wed, 13 May 2026 14:30:40 GMT

Hi @D_Atkins

The layer list is based on the calcite list which uses the Treegrid pattern for keyboard navigation which is also described here in the calcite documentation: https://developers.arcgis.com/calcite-design-system/components/list/#keyboard-navigation

The chevron icons are there to provide a visual indication that the group is expanded or closed but cannot be focused on using the keyboard and are not used to expand or collapse the groups when using keyboard navigation.

Re: LayerList Tab Order and WCAG

D_Atkins — Fri, 15 May 2026 14:49:54 GMT

For the LayerList specifications: the W3 treegrid says 'tab' from end-of-row should exit the treegrid widget, but the Calcite implementation is that a 'tab' event from end-of-row moves to the next cell in the next row. I'm assuming this was an intentional design choice -- most LayerLists are only a couple of rows, and the End key still works for large lists. But then 'tab' doesn't allow me to access the 'row' (or to expand nested layers).

But then also: if we define a single button in the .actionSections, then that button is accessible as a cell (with arrow keys or tab). But if we define multiple actions, we get a list menu ("..."); visually, this menu-button remains a member of the focused row, but it is only accessible via 'tab' and not 'arrow keys'.

As a 'challenged user' new to all this, it feels like we're straddling two standards: if I need 'tab+Enter' to access the actionSection, then why can't I also use tab+Enter on the carat to expand the row? Vis-versa, if I need to learn the treegrid pattern to expand a row, then why can't I also use arrow keys to navigate to the actionSection?

To exaggerate the issue: the .actionSection is fully navigable by arrow-keys once focus is on the "..." button, but then a left-arrow from anywhere in the .actionSection sends focus back to the TreeGrid and leaves the actionSection open (with an incorrect focus-highlight, too).

The reorder panel is similar, though it is focusable by arrow keys as a treegrid cell initially and you can expand the menu with either tab or down-arrow. Once open, it has two different behaviors: tab moves focus to the next treegrid-cell and closes the reorder-menu, meanwhile, the right-arrow moves focus the same way but leaves the menu open (at least, unlike actionSection, it does remove the focus-highlight).

----

Another, hopefully quick one, while we're on the topic of keyboard navigation...

For <arcgis-search>, a 'tab' input seems to send focus somewhere esoteric? According to quick test on the console, the activeElement remains 'arcgis-search': typing doesn't send anything to the text box but 'enter' will submit whatever text was previously present.

----

Enter key roulette!

I know some of this may sound petty to bring up but at the very least it constitutes a level of due diligence on our part in regard to WCAG.

Re: LayerList Tab Order and WCAG

Sage_Wall — Mon, 18 May 2026 21:04:02 GMT

Thanks for taking the time to document all of this so thoroughly — we really appreciate the level of detail and the care you’re putting into evaluating these interactions from a WCAG and real-world usability perspective.

Using the arrow keys to navigate within list- and grid-like components, such as the Layer List, is the preferred and expected interaction model. This pattern is widely established and very familiar to individuals who rely on assistive technologies, such as those relying on keyboard and screen readers. Maintaining consistency is important so individuals don’t have to relearn interaction models as they navigate between components.

On the specific point about the search component, the tab behavior you’re experiencing, where focus appears to move in an unexpected way does not sound intentional. We're going to explore this further to determine if it is a bug for next steps.