Accessibility improvement with windows and the sections and views navigation widgets

[andrewdfahey]

I found that a button opening a window with section and views navigation will hard lock keyboard navigation by not allowing users to tab, shift-tab, escape, or enter out of the window. If it could be more accessible, this would be a fantastic way to supply step-by-step instructions to an application which is how I first saw it in I believe an ESRI presentation.

In my testing, it is not just the window aspect since I can open a window to immediately focus on the configured close button of the window (Image 1). It also is not section and views navigation widgets broadly since I have used them successfully not in a window. Rearranging the elements in the window does not change the result. Ultimately, pulling all of these widgets and elements together creates something that looks great but seems to hit a brick wall in terms of keyboard navigation (Image 2).

My ESRI ticket confirmed this last week as case #03952209.

[TonghuiMing]

Hi @andrewdfahey 

Thanks for bringing this up. Thought I'd seen it somewhere, and it turns out the support ticket is from you, too.

This problem is a bit tricky, since when we tried to keep the hidden view out of the section active view. The current workaround that we can provide is that:

Put everything inside your section - the close button, and use the built-in navigator of the Section widget instead of the Views Nav widget.

This way, at least the scenario can be achieved. In the meantime, we will try to find a good solution to that issue, not an easy and quick fix, though.

Thank you,

Tonghui

[andrewdfahey]

Hi @TonghuiMing ,

Thanks for getting back to me and for the suggestion.

Unfortunately, the issue seems to be the part where the section widget is in the window. I originally thought it was the combination of the section and views navigation inside of a window. However, after trying your suggestion of removing the views navigation, keyboard navigation still focuses on the window element itself first which leads to the same keyboard trap.

That said, and for anyone who stumbles on this, an accordion widget can be used to get similar results if trying to include instructions either step-by-step if sharing a singular workflow or blocked into larger workflows (e.g. "How to edit data" vs "Finding work sites near you").

All the best,

Andy