feat(Drawer): added focustrap functionality #9469
Conversation
|
Preview: https://patternfly-react-pr-9469.surge.sh A11y report: https://patternfly-react-pr-9469-a11y.surge.sh |
thatblindgeye
force-pushed
the
iss5354_drawerFocustrap
branch
from
86fd02f to
2c428c0
Compare
|
|
||
| ### With focus trap | ||
|
|
||
| Use the `focusTrap` property to enable and customize a focus trap on the `<DrawerPanelContent>`. Enabling a focus trap with `focusTrap.enabled` will also automatically place focus on the first focusable element when the drawer panel expands, and return focus to the previously focused element when it collapses. |
There was a problem hiding this comment.
| Use the `focusTrap` property to enable and customize a focus trap on the `<DrawerPanelContent>`. Enabling a focus trap with `focusTrap.enabled` will also automatically place focus on the first focusable element when the drawer panel expands, and return focus to the previously focused element when it collapses. | |
| A focus trap contains focus within an overlay element. When a focus trap is enabled on an element, a user can only interact with elements inside of the focused area until the focus trap is closed or deactivated. | |
| To enable and customize a focus trap on a drawer panel, apply the `focusTrap` property to the `<DrawerPanelContent>` component. Enabling a focus trap with `focusTrap.enabled` will also automatically place focus on the first focusable element when the drawer panel expands, and return focus to the previously focused element when it collapses. |
Does this addition sound accurate and useful? Thought it may be good to briefly describe what a focus trap is, but lmk if not (I scrapped together an understanding from a little googling).
There was a problem hiding this comment.
It might be worth mentioning. Considering other components use a focus trap, would it be better to have it in a single place that can be referenced? We do have content on trapping focus on the PF site, though it's a bit more specific to Modal and Popover.
For the example description, what do you think about, "When a focus trap is enabled on an element, a user will only be able to interact with the contents of that element until the focus trap is closed or deactivated." as the first line (followed by the "To enable and customize a focus trap..." content)?
There was a problem hiding this comment.
Ahh thanks for the extra info! Since we have that section on trapping focus in the accessibility docs, what if we just link to that doc on the first instance of "focus trap"? If that trapping focus info would benefit from being expanded we could always do that in a followup issue (doing a content review/audit of the accessibility docs is already on my to-do list as part of the wider site content audit)?
I like your suggestion for reframing the content!
|
@edonehoo updated per convo above, let me know what you think! Would you want to open a followup in org for updating the "trapping focus" docs? |
|
Looks great to me! I made a note to include trapping focus updates in this issue. |
thatblindgeye
force-pushed
the
iss5354_drawerFocustrap
branch
from
fc7c7f0 to
0a3e2b1
Compare
thatblindgeye
force-pushed
the
iss5354_drawerFocustrap
branch
from
0a3e2b1 to
eceebd6
Compare
| */ | ||
| elementToFocusOnExpand?: HTMLElement | SVGElement | string; | ||
| /** One or more id's to use for the drawer panel content's accessible label. */ | ||
| 'aria-labelledby'?: string; |
There was a problem hiding this comment.
Why is this only needed when we have focus trap enabled?
There was a problem hiding this comment.
With the focus trap enabled we're adding a role="dialog" to the panel content. MDN has some context on labelling a dialog. For the non-focus trap Drawer, we just have a plain div which typically doesn't do well with aria labelling.
|
Your changes have been released in:
Thanks for your contribution! 🎉 |
What: Closes #5354
Drawer with focus trap example
Additional issues: