Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(Wizard): added prop to focus content on next/back #10285

Merged
merged 6 commits into from
Apr 29, 2024

Conversation

thatblindgeye
Copy link
Contributor

What: Closes #10249

Some comments on changes below

Additional issues:

Comment on lines -71 to -87
const ariaLabel = React.useMemo(() => {
if (status === WizardNavItemStatus.Error || (isVisited && !isCurrent)) {
let label = content.toString();

if (status === WizardNavItemStatus.Error) {
label += `, ${status}`;
}

// No need to signify step is visited if current
if (isVisited && !isCurrent) {
label += ', visited';
}

return label;
}
}, [content, isCurrent, isVisited, status]);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting this aria-label was kinda interfering/producing extra noise with the aria-live attr added in. We probably shouldn't append "visited" text via aria-label for a Wizard step, and just let users know whether a specific step is the current one or not. If it's vital for users to know what steps they've visited/successfully completed, we could just utilize the hidden text that is used in this PR now.

@patternfly-build
Copy link
Contributor

patternfly-build commented Apr 17, 2024

Comment on lines +94 to +97
const focusMainContentElement = () =>
setTimeout(() => {
wrapperRef?.current?.focus && wrapperRef.current.focus();
}, 0);
Copy link
Contributor Author

@thatblindgeye thatblindgeye Apr 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preface by saying I don't exactly love this 😆

So something I think we should consider is adding a new wrapper element to the actual Wizard step content. Right now we have a structure of:

< .pf-v5-c-wizard__inner-wrap >
  < .pf-v5-c-wizard__nav >
  < .pf-v5-c-wizard__main >
    < .pf-v5-c-wizard__main-body >
  < ...several empty divs with display: none for steps taht aren't rendered >

(Note that Core does not have a bunch of empty divs with display none for steps whose content is not currently rendered, so maybe the intent was that __main element should be static and __main-body dynamically renders step content? Curious as to whether we need these empty div's rendered in React at all.)

When we could either add a wrapper element around the .pf-v5-c-wizard__main and the display: none elements, or have pf-v5-c-wizard__main always rendered and whatever step content just gets placed in there (so pf-v5-c-wizard__main-body and the empty div elements).

Right now we allow preventing that .pf-v5-c-wizard__main from being rendered which will be an issue for this focus management. Having it always rendered and placing all the step contents in there, rather than each step content dynamically updating from an empty div to a div with class .pf-v5-c-wizard__main would help with this focus management (shouldn't need to wait for the __main element to render before placing focus since it'd always be rendered) as well as being able to set the aria-live on it instead of the pf-v5-c-wizard__inner-wrap element (which doing this, any updates to nav content will be announced which may or may not be wanted/beneficial).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely curious about what scenario we could have that wouldn't include a main. If we went the aria-live route this would be necessary. However, maybe it's ok if we avoid using aria-live for now. I typically see live regions used for things like updates/status, alerts, logs, etc. Like this article talks about, live regions typically aren't used for interactive content (and I imagine we'd expect wizard content to be interactive often). Based on our discussion, I agree that it probably makes sense to omit aria-live for now and rely on the announcement of the shifted focus.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @mcoker

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Note that Core does not have a bunch of empty divs with display none for steps whose content is not currently rendered, so maybe the intent was that __main element should be static and __main-body dynamically renders step content? Curious as to whether we need these empty div's rendered in React at all.)

FWIW the wizard is built very similarly to a page, so __main was intended to mimic the page main container. In both cases, it's more of a static, structural element of the layout, so I would expect content within it (__main-body elements) to re-render, or possibly attributes and stuff on __main to change, but not the whole element to re-render... though I suppose that would be fine as long as it didn't cause layout shifts or anything?

/** @beta Flag indicating whether the wizard content should be focused after the onNext or onBack callbacks
* are called.
*/
shouldFocusContentOnNextOrBack?: boolean;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little nit picky, but I find this name a little confusing. Is there something that we could use that would be a little clearer?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd definitely be in favor of updating this prop name, I just couldn't really think of a better alternative at the time 😆 shouldFocusContentOnStepChange wouldn't be totally accurate since technically clicking a nav item changes the step, but we don't move focus on that. shouldFocusContent would be shorter, but probably less clear? shouldFocusContentOnFooterAction?

If it matters the prop is beta, so we should be able to tweak the naming if needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tlabaj do you have any suggestions for a potential prop name here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would vote for the shorter name. I think shouldFocusContent will work as long as description is clear.

Comment on lines +94 to +97
const focusMainContentElement = () =>
setTimeout(() => {
wrapperRef?.current?.focus && wrapperRef.current.focus();
}, 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely curious about what scenario we could have that wouldn't include a main. If we went the aria-live route this would be necessary. However, maybe it's ok if we avoid using aria-live for now. I typically see live regions used for things like updates/status, alerts, logs, etc. Like this article talks about, live regions typically aren't used for interactive content (and I imagine we'd expect wizard content to be interactive often). Based on our discussion, I agree that it probably makes sense to omit aria-live for now and rely on the announcement of the shifted focus.

Copy link
Contributor

@jessiehuff jessiehuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Still not sure on naming, but that is not my forte. 😆

@thatblindgeye thatblindgeye requested a review from tlabaj April 22, 2024 12:58
Copy link
Contributor

@tlabaj tlabaj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than changing the prop name this looks good to me

@tlabaj tlabaj merged commit fe1d86c into patternfly:main Apr 29, 2024
13 checks passed
@patternfly-build
Copy link
Contributor

Your changes have been released in:

Thanks for your contribution! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug - Wizard - Keyboard Navigation - High Visibility Accessibility issue
5 participants