Fluentui: DetailsList: when selectionMode == none, remove focusability and hover treatment from row

[krvdgulik]

Environment Information

fabric version >=6.92.0

Please provide a reproduction of the bug in a codepen:

https://codepen.io/Anonymous1993/pen/pBVZQM?&editable=true

Actual behavior:

When SelectionMode.none is used on the details list, the list rows still show hover and focus styles. However this is confusing as the list should not allow selection.

Expected behavior:

When SelectionMode.none is used with the details list, the focus and hover styles should not show.

Priorities and help requested:

Are you willing to submit a PR to fix? Yes, but would prefer that the fabric team could do it, as that would be likely faster.

Requested priority: Normal

Products/sites affected: web.powerapps.com

[joschect]

@krvdgulik thanks for submitting this! And for including the codepen, it really helps us. I definitely see that it's behaving the way that you say.

@micahgodbolt can you comment as to whether or not that is the expected behavior for the list to show hover state even though nothing can be selected?

[ecraig12345]

@KevinTCoughlin might be able to help answer about the expected behavior here too.

[KevinTCoughlin]

I know @natalieethell disabled these styles for our documentation as part of #8737.. I do agree that the behavior is confusing. Looks like there's an email thread with design to see if modifying the styles for this state is agreeable.

I'd like to note that Selection _should no longer_ be possible when SelectionMode.none is used as of https://github.com/OfficeDev/office-ui-fabric-react/pull/8605, can you confirm @krvdgulik? That was released in [email protected].

[natalieethell]

Thanks for the tag @KevinTCoughlin! Yes, here's an example of how I'm overriding the hover styling right now if you want a quick workaround while we discuss modifications to the styling in the DetailsList code:

https://codepen.io/naethell/pen/rbZEXR

[KevinTCoughlin]

Since there's a workaround proposed in https://github.com/OfficeDev/office-ui-fabric-react/issues/8783#issuecomment-485930695 I think we should add this to the backlog for DetailsList.

We'll resolve once we align with design and support it at the component level.

[janjachacz]

@KevinTCoughlin, this workaround #8783 (comment) only covers the mouse over effect, not the focus management which is very important for a11y.

[KevinTCoughlin]

the focus management which is very important for a11y

@janjachacz can you clarify the above? Should focus not occur when selectionMode === 'none'?

Is the expectation that a user only read the row content in scan mode then?

Note that we still have the onItemInvoked callback that can be issued when selection is disabled which modifying focus behavior would break.

[cnamal]

We have a guideline that non actionable items shouldn't be focusable. Therefore, like you said, screen reader users would only be able to read the table through scan mode.
However, I wasn't able to find a WCAG/MAS rule associated with that guideline. Let me get back to you after talking with some SME.

[cnamal]

@KevinTCoughlin confirmed with a11y experts.

The guidance you received about only actionable items receiving focus was correct, it would be a bad idea to make a list item or table row receive focus, as both those roles do not support interaction. If you wanted the user to interact with a list item in some way, the best approach would be to nest something like a button within the list item.

that particular behavior would likely violate both 2.4.3 Focus Order and 4.1.2 Name, Role, Value.

[cnamal]

I noticed, I didn't respond to this part:

Note that we still have the onItemInvoked callback that can be issued when selection is disabled which modifying focus behavior would break.

That is tricky indeed. You could add the FocusZone/data-is-focusable only if selectionMode!==SelectionMode.none || onItemInvoked, though I admit it's not great :/ (and I'm probably missing some use cases)

[webdes03]

Another vote for this. We're using the DetailList control in a teams app and I've been racking my brain trying to figure out why rows are still receiving hover treatment even though they're not selectable. The way this control currently works is counter intuitive as from a UI perspective as a user should expect that something happens or can be done when the appearance of the row physically changes on hover.

I will attempt the workaround for now, but do believe this to be a bug.