Select to view content in your preferred language

LayerList Tab Order and WCAG

134
2
Wednesday
D_Atkins
Frequent Contributor

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

0 Kudos
2 Replies
Sage_Wall
Esri Regular Contributor

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.

D_Atkins
Frequent Contributor

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!

LayerList_keyboardAccessibility.png

 


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.

0 Kudos