Fluentui: A11y Detailslist keyboard navigation behaviors are wrong for the role "checkbox".

[ruoxi-lyu]

Codepen demonstrating the issue

Repro with this basic detailslist sample

Actual behavior:

Radio buttons in the basic detailslist control are read as "Checkbox" role by windows narrator and other screen readers. However, the element in the list allows user to use up/down arrow keys to navigate and gets automatically selected while using the arrow keys. This is the expected behavior for radio button role.

For checkbox role. the expected navigation behavior should be: use tab/arrow keys to just get focus on to them. then we need to press space to check/uncheck.

<span role="checkbox" class="checkCover-194" aria-checked="true" data-selection-toggle="true">
</span>

Expected behavior:

Radio buttons in the detailslist control should read as "radio button" role.

Documentation describing expected behavior

MAS reference: MAS 1.3.1

[khmakoto]

Hi @ruoxi-lyu, thanks for raising awareness on this!

@KevinTCoughlin this seems to me like a bug on our part when dealing with navigation more than us incorrectly applying roles. Is that right or am I missing something here?

[KevinTCoughlin]

@KevinTCoughlin this seems to me like a bug on our part when dealing with navigation more than us incorrectly applying roles. Is that right or am I missing something here?

It is not clear to me how the role="radio" would work for one of the default scenarios DetailsList supports which is multiple-selection. This control is used in document libraries across OneDrive & SharePoint so supporting this is crucial.

Note that the W3 ARIA spec states the following re: role="radio":

A checkable input in a group of elements with the same role, only one of which can be checked at a time.
https://www.w3.org/TR/wai-aria-1.1/#radio

Similarly, role="radiogroup" has the same single-selection limitation as per spec:

A radiogroup is a type of select list that can only have a single entry checked at any one time.
https://www.w3.org/TR/wai-aria-1.1/#radiogroup

---

Note that role="checkbox" _does not_ have this single selection limitation, see https://www.w3.org/TR/wai-aria-practices-1.1/#checkbox.

I don't see anything in the specification which disallows selection on focus when using role="checkbox" so I'm not sure this is something that needs to be changed. Doing so would likely cause more accessibility violations in the common multi-select scenario.

cc: @natalieethell @ThomasMichon

[ruoxi-lyu]

@KevinTCoughlin if you decide to keep role="checkbox", the expected keyboard navigation for checkbox should be:
use tab/arrow keys to just get focus on to an element. thenpress space to check/uncheck, so that the user can use pure keyboard navigation to select single/multiple elements.

However, the keyboard navigation behavior for the detailslist on the basic example is not correct. Using up and down arrow key can only select one element and will deselect the previous selected element.

I updated the title of this issue accordingly.

Could you please help fix the keyboard navigation behavior?

[natalieethell]

However, the keyboard navigation behavior for the detailslist on the basic example is not correct. Using up and down arrow key can only select one element and will deselect the previous selected element.

I updated the title of this issue accordingly.

Could you please help fix the keyboard navigation behavior?

@ruoxi-lyu If you hold down the "Shift" key while navigating through the rows with up and down arrows, you should be able to select multiple elements. I believe this is the expected behavior, but correct me if I'm wrong @KevinTCoughlin @betrue-final-final.

Here's an example:

[dzearing]

Yes @natalieethell this is correct. Also holding ctrl down and up/down arrowing I believe moves focus without selecting, as per windows explorer keyboard accessibility.

[dzearing]

@betrue-final-final @ThomasMichon @cschlechty @KevinTCoughlin Do you folks have an opinion here?

My take here is that this is by design. Arrowing up/down should move selection. Ctrl up/down should move focus without selection. Shift up/down should change selection. Pressing space bar should toggle the currently focused element.

[KevinTCoughlin]

@betrue-final-final @ThomasMichon @cschlechty @KevinTCoughlin Do you folks have an opinion here?

My take here is that this is by design. Arrowing up/down should move selection. Ctrl up/down should move focus without selection. Shift up/down should change selection. Pressing space bar should toggle the currently focused element.

As far as I'm aware this navigation is by design. I'm assuming OneDrive / SharePoint document libraries have passed accessibility validation w.r.t keyboard navigation.

[cschlechty]

The row itself isn't a checkbox, which is the thing changing. As a result
of moving selection to a row, the checkbox may or may not change state. It
should be fine as-is.

On Tue, Mar 26, 2019 at 9:15 AM Kevin Coughlin [e-mail]
wrote:

@betrue-final-final https://github.com/betrue-final-final @ThomasMichon
https://github.com/ThomasMichon @cschlechty
https://github.com/cschlechty @KevinTCoughlin
https://github.com/KevinTCoughlin Do you folks have an opinion here?

My take here is that this is by design. Arrowing up/down should move
selection. Ctrl up/down should move focus without selection. Shift up/down
should change selection. Pressing space bar should toggle the currently
focused element.

As far as I'm aware this navigation is by design. I'm assuming OneDrive /
SharePoint document libraries have passed accessibility validation w.r.t
keyboard navigation.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OfficeDev/office-ui-fabric-react/issues/8406#issuecomment-476726046,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATa0jxUOFGHp6FgbjMUz0-D4AxA4Ey9gks5vakeIgaJpZM4b_xCL
.

[dzearing]

Closing as by design.