Standardize grid selection and selected row display

[tlmii]

Splitting this off from #590

Right now we've got a couple different ways that selection happens in our grids:

Resources, Structured Logs and Traces: A View button (under the Environment (Resources), Details (Structured Logs) and unlabeled (Traces) column headers respectively) needs to be clicked to go to details. In the case of Resources and Structured Logs this pops open the details pane. In the case of Traces it navigates to another page.

Trace Detail: The entire row is clickable. Clicking pops open the details pane.

In all three of the details pane scenarios (Resources, Structured Logs and Trace Detail) there is no indication on the grid of what was selected. The details pane has a header that displays identifying information about the selection, but there's no visual connection back to the row.

In some cases, full-row selection may not be appropriate (what's the UX with clickable links/buttons within the row, for instance).

We should determine if (or when) we want full-row selection and how we want to indicate the selection in each of the above scenarios.

[DamianEdwards]

Would like to ensure that where appropriate the selection is keyboard shortcut friendly so that it's easy to select an item to see its details, and then arrow up/down to change selection. Makes browsing through a list of items really smooth.

[JamesNK]

Showing which row a details view is open for needs to be prioritized. Is this the right issue?

I think a row needs to be highlighted if its details are being displayed.

For example, on the logging page, the open details view is for which log entry?*

*trick question, I opened the details view and scrolled to view new log entries, but someone can easily get lost trying to remember or find the log entry in the grid for its open details.

[adamint]

@leslierichardson95 could we get guidance on this, so it can be implemented?

[leslierichardson95]

implemented?

Let's do the single-row click option. I think that may allow us to keep the main grid a reasonable size as we continue to add content in the future.

[JamesNK]

@adamint Is their progress on adding row selection to Fluent UI? It will take time to agree on this feature, the feature to be implemented and then for it to get released. It needs to be started far in advance of changing Aspire to use it.

[adamint]

Moved the issue about the component we're adding to #1782 - it will be more similar to a tree view so that we can easily display replicas

[JamesNK]

I'll be clearer:

I thought there was a decision at a meeting a month ago that you'd reach out to the Fluent UI folks about a feature to make row selection better. Has that happened? Or did one of us misinterpret the outcome of the meeting?

[adamint]

You’re right that there will be an additional component we will use; it was then decided that we (I) will be the ones to create that new component in fluentui-blazor @JamesNK

[JamesNK]

It's really important to start talking to them sooner rather than later about what we want to do and come to a consensus about the best way to do it.

We can probably simulate a tree view by building on top of GridView - there is an example of doing that here. We can do something similar on the resource grid. But row navigation will definitely require changes inside GridView. Please create an issue on the FluentUI repo about what we want and start a discussion about the changes required.

[tlmii]

Copied from #1788 (comment)

span details is currently completely inaccessible to keyboard and screen reader users with no workaround

Can we get specific about what doesn't work with the current grid as far as accessibility goes? I'm sure I'm missing something from the list, but here's a starting point:

1. Per-cell keyboard focus and navigation work on the current grid. You can use the arrow keys to move around the grid and give focus to various cells. There's no row selection, but being able to select each cell covers that scenario for now at least.
2. Selection does not work right now.
3. Presumably we need some indication to screen readers that a particular cell/row can be "executed".

For 2 The W3C examples (e.g. https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/data-grids/) use a keydown handler on cells. We could do the same.

For 3 it seems like it might be sufficient to give the div for the cell an aria-role of button. The W3C examples above use a hidden button, though off hand I don't see a reason why that'd be better.

[adamint]

1. Per-cell keyboard focus does work, ideally it would be better to allow row focus too so that unnecessary information isn't being read.
2. Yes, keydown should be used, but should be attached to the cells/rows themselves.
3. aria-role of button should work. Per mdn,

If using role="button" instead of the semantic or elements, you will need to make the element focusable and define event handlers for click and keydown events. This includes handling the Enter and Space keypresses in order to process all forms of user input.

We will be ensuring the elements are focusable, and we will already be attaching click and keydown events, so there is nothing else needed!