User Input Flow has accessibility issues

[tofumatt]

Bug Description

The new User Input Flow has several accessibility issues that cause keyboard-only and screenreader users to have, at minimum, difficulty navigating the new flows. Some bits are simply confusing/unexpected but others make it quite hard to navigate as a keyboard-only user.

This issue encompasses several smaller issues all related to improving the baseline accessibility of the User Input flow.

Return/Enter key does not advance form to next question

The enter key, especially in the text field, should advance the question to the next question. But as shown in the screen capture, it currently doesn't.

Focus is reset/destroyed when "Back" button is used

The "Next" button works fine, but the "Back" button destroys the user's focus context and forces them to tab through their entire browser UI, at least in Chrome.

While resetting focus isn't great, in this case we should do it but re-focus the user onto their answered question after changing the question back one step.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The User Input Flow should be navigable and able to be filled out without the use of a pointing device/mouse.
• Focus should not be stolen/reset unexpectedly; when focus is manually changed it should be expected, related to the last user interaction, and not reset to the first tab-able item on the page.
• The "Enter"/"Return" key should submit the current answer/advance the user to the next question.
• The "Other" text input should not be tabbable unless the "Other" radio/checkbox is selected.

Implementation Brief

• When the "Back" button is activated, change user focus to be .googlesitekit-user-input__question or the first selectable item in the active question. This will allow the user to change focus through the question as-expected. The same should happen with the "Next" button, which I think it does, but this should be confirmed.
• When "Enter"/"Return" is used in any of the first four questions, it should proceed to the next question (eg fire the "Next" action) if "Next" is allowed.
• Set a tabIndex="-1" on the "Other" input unless "Other" is selected.
• On the last question, proceed with the "Next" action if the user has entered three terms and cannot create anymore—eg, pressing enter should proceed with the "next" action in this state:

Test Coverage

• No test coverage is needed here.

Visual Regression Changes

• This should not affect VRT.

QA Brief

• Users should be able to navigate through all the user input screens with only his keyboard.
• Focus should not be lost when switching back and forth from screens.

Changelog entry

• Fix User Input Settings flow accessibility issues

[tofumatt]

I sometimes forget that radio buttons in general shouldn't actually be separately tabbable. Someone on the team pointed this out to me and I did more checks thinking "nah, seems they should be tabbable". But the intent is that checkboxes are tabbable—radio inputs should not be.

But to that point, the other three issues are valid. We shouldn't allowing tabbing to the "Other" text input if that option isn't selected.

[felixarntz]

@tofumatt Good additional points you're making here - should they be added to the ACs / IB here or would you rather open a separate issue? Not tabbing through radio buttons and not tabbing to text input if "Other" is not selected makes sense to me.

[tofumatt]

The radio buttons aren't currently tabbable so that's correct—just clarifying that point as earlier I had marked it as a potential problem, but it's not.

I've added the "Other" not being tabbable when "Other" isn't selected to the ACs/IB, so I think this is now good for review again 👍🏻

[felixarntz]

IB ✅

[wpdarren]

QA Update: Clarification with Engineer ⚠️

@tofumatt @asvinb @felixarntz to add to your comments about radio buttons not being tabbable, why not? In my opinion they should be. When the initial page loads wp-admin/admin.php?page=googlesitekit-user-input you are unable to tab to the next answer in the first question. You have no option but to use the mouse if you want to select any answer but the first one. The initial state is that the first answer option is highlighted but when you tab, it jumps down to the Thank you for creating with WordPress. text and then through the WordPress navigation.

Unless I am missing something obvious, based on this, the QAB fails. What are your thoughts?

[asvinb]

@wpdarren As per the docs here:

This section describes the keyboard interaction implemented for most radio groups. For the special case of a radio group nested inside a toolbar, use the keyboard interaction described in the following section.

Tab and Shift + Tab: Move focus into and out of the radio group. When focus moves into a radio group :
If a radio button is checked, focus is set on the checked button.
If none of the radio buttons are checked, focus is set on the first radio button in the group.
Space: checks the focused radio button if it is not already checked.
Right Arrow and Down Arrow: move focus to the next radio button in the group, uncheck the previously focused button, and check the newly focused button. If focus is on the last button, focus moves to the first button.
Left Arrow and Up Arrow: move focus to the previous radio button in the group, uncheck the previously focused button, and check the newly focused button. If focus is on the first button, focus moves to the last button.

So currently, the radio group not being tabbable is in line with W3C ARIA best practices.

[wpdarren]

QA Update: Fail ❌

@asvinb an interesting scenario: if the user selects Other in error, the cursor jumps into the text field as expected. They are then unable to use the arrow keys to move back up the list of options in the question. Pressing tab moves the cursor to the next stop which is the WordPress text at the bottom of the page. Is this easily fixed?

user-input.mp4

[asvinb]

@wpdarren I think it's perfectly normal. If you click on the "Other" radio button, the focus immediately switches to the input text for the user to type his answer. If the user wants to go back to the radio options, he will use "Shift + Tab" and then use the arrows keys to move up and down. If the user presses "Tab" without entering anything in the "Other" option, the "Next" button remains disabled, thus the focus will be on the next available focusable item, which is the WordPress link at the bottom of the page.
Let me know if am missing anything!

[wpdarren]

QA Update: Pass ✅

• Users are able to navigate through all the user input screens with only the keyboard.
• Focus is not be lost when switching back and forth from screens.