Bug - Wizard - Keyboard Navigation - High Visibility Accessibility issue

[Arathy-s]

Describe the problem
Unable to navigate through the Wizard component using the keyboard.

This is an issue with

• Patternfly 5

Please give a clear and concise description of the problem. Which components are affected?
On navigating the Wizard component through the keyboard, upon clicking the next/previous buttons, the focus remains on the wizard footer buttons even though there are interactive elements in the wizard's panel/body.

How do you reproduce the problem?
https://www.patternfly.org/2022.05/components/wizard/#anchors-for-nav-items

In this example, on navigating to the third step, the focus directly moves to the Next button at the bottom even though there is an interactive element Join the conversation in the panel.

Expected behaviour
Upon clicking the next/previous buttons, the focus should move to either the first interactive element in the wizard's main panel or (if there are no interactive elements) the main panel itself so that the user can navigate through the wizard easily

Is this issue blocking you?
The issue is blocking one of the highest-priority items.

Screenshots
If applicable, add screenshots to help explain the issue.

What is your environment?

• OS: Mac OS Sonoma 14.3
• Browser: Chrome
• Version: 122.0.6261.129 (Official Build) (x86_64)

What is your product and what release date are you targeting?
Customer Portal

Any other information?

[Arathy-s]

@hellogreg @nikkimk
Could you please provide your insights on the same.

[Arathy-s]

The component is not screen reader-friendly.
A user is given no indication that anything has happened after clicking the button--except that the button may become disabled upon hitting the last step.

[cfbryan]

Hello, folks - let me know what I can do to escalate this issue.

[nikkimk]

One solution if we're keeping the focus on the Next button is that we add an aria-describedby to the Next and Back buttons, like this:

1. On step 1, Next would have an aria-describedby with an ID ref for step 2.
2. On step 2, Next would have an aria-describedby with an ID ref for step 3, and Back would have an aria-describedby with an ID ref for step 1.
3. On step 3, Back would have an aria-describedby with an ID ref for step 2.

That way the Next and Back buttons themselves can provide the feedback about the step change.

[nikkimk]

I'd also suggest that the navigation use a roving tabindex pattern so that screenreader users can can use tab to skip over it and arrow keys to navigate within it, especially since some variants use a tree view.

[thatblindgeye]

One potential work around for now would be utilizing a custom WizardFooter, and manually handling focus on the onNext and onBack callbacks. We have a custom footer Wizard example showing how a custom footer is used; though the example doesn't show focus being handled, it could be implemented by adjusting the applicable callbacks passed into the WizardFooter component.

That would most likely require also wrapping step content in some wrapper that has a tabindex of -1, as right now the only time we apply a tabindex is when the content in the main Wizard content area causes a scrollbar to render.

[markcaron]

@nikkimk I like the idea of a roving tabindex pattern here as well. The wizard steps are essentially a tabset.

CC: @adamjohnson

[hellogreg]

I agree with @Arathy-s that moving focus to the first interactive item in the panel is desirable in this case (especially in the use case for Customer Portal). Hopefully, in the short term, something like @thatblindgeye 's workaround would help for now!

The component is not screen reader-friendly. A user is given no indication that anything has happened after clicking the button--except that the button may become disabled upon hitting the last step.

Yes. In addition to what @nikkimk said, having an element announce step status throughout the wizard (e.g., with role="status") could be useful in letting the user know they've progressed upon button click.

[hellogreg]

And, yes, the main wizard nav is a great opportunity for incorporating roving tabindex.

[nikkimk]

@thatblindgeye The workaround is a great idea, but I'd also suggest making a note of the accessibility issues with the other examples in the docs. Otherwise we could be propagating more accessibility issues.

One potential work around for now would be utilizing a custom WizardFooter, and manually handling focus on the onNext and onBack callbacks. We have a custom footer Wizard example showing how a custom footer is used; though the example doesn't show focus being handled, it could be implemented by adjusting the applicable callbacks passed into the WizardFooter component.

[thatblindgeye]

Here's a codesandbox of a workaround that I threw together pretty quickly (and hackily 😆 ) that could be achieved. Note that I added a timeout so that the new content could render and then focus be placed on it.

Overall this isn't something that seems to have a totally straight forward solution so there's been discussion around this.

In regards to a roving tab index, I might worry whether that would interfere with wizard content that has a scrollbar, where the arrow keys are necessary to "scroll" the area but would also be necessary to "focus" the next element. I might be misinterpreting this, though.

[kelsS]

@cfbryan 👀

[Arathy-s]

Hey @thatblindgeye

I tried implementing the codesandbox of a workaround and it worked! 🎉

This solution resolves the keyboard navigation issue temporarily.

And once the issue is resolved in the Patternfly Wizard component, we can remove this temporary fix and update the component.