-
Notifications
You must be signed in to change notification settings - Fork 355
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
Conversation
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]); | ||
|
There was a problem hiding this comment.
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.
Preview: https://patternfly-react-pr-10285.surge.sh A11y report: https://patternfly-react-pr-10285-a11y.surge.sh |
const focusMainContentElement = () => | ||
setTimeout(() => { | ||
wrapperRef?.current?.focus && wrapperRef.current.focus(); | ||
}, 0); |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @mcoker
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
const focusMainContentElement = () => | ||
setTimeout(() => { | ||
wrapperRef?.current?.focus && wrapperRef.current.focus(); | ||
}, 0); |
There was a problem hiding this comment.
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.
d5887dd
to
4f591c7
Compare
There was a problem hiding this 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. 😆
There was a problem hiding this 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
4f591c7
to
3133abd
Compare
3133abd
to
a2061ad
Compare
Your changes have been released in:
Thanks for your contribution! 🎉 |
What: Closes #10249
Some comments on changes below
Additional issues: