Closed bennypowers closed 3 months ago
Latest commit: c58361337afb644efc73e1f6dc642b05cfc94ef2
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
Name | Link |
---|---|
Latest commit | 580764be2d626ab7539730f9c9552505ff5c5dc1 |
Deploy Preview | https://deploy-preview-2703--patternfly-elements.netlify.app/ |
To edit notification comments on pull requests, go to your Netlify site settings.
Name | Link |
---|---|
Latest commit | c58361337afb644efc73e1f6dc642b05cfc94ef2 |
Latest deploy log | https://app.netlify.com/sites/patternfly-elements/deploys/65fc34ddeca5ef000810736b |
Deploy Preview | https://deploy-preview-2703--patternfly-elements.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
Looks like the button and list may be getting misaligned upon expansion in Chrome and Safari (Firefox is okay):
With VoiceOver/Safari on Mac, the button is not currently announcing an expanded or collapsed state upon focus.
@hellogreg PTAL, thanks
Looks like the aria-expanded
attribute on <pf-button>
isn't being applied to the actual button--and thus the state is not getting announced by screen readers:
WIth the Windows Firefox/NVDA browser and screen reader combo, the screen reader stays in browse/read mode when focus is on the button. The user can manually activate focus mode to use the button, but it should auto-detect.
This isn't an issue with any other browser/reader combo. (Typically, this issue crops up for more than one of them at a time, so this is a little unusual.)
i think we'll need to remove the native <button>
from pf-button's shadow root, and make the pf-button host a role: button with element internals. this could affect chip, select, and others.
i think we'll need to remove the native
<button>
from pf-button's shadow root, and make the pf-button host a role: button with element internals. this could affect chip, select, and others.
Yep. Until we have a cross-root ARIA solution, this is probably a necessary evil.
@hellogreg PTAL
There may be a CSS issue right now where the dropdown button isn't displaying. However, I am still able to place keyboard focus on it and activate it for testing:
Dropdown works well with these combos. I do have one question. Do you want/need to have a default designated focus destination when a menu item is activated and the dropdown closes? After pressing esc
, focus returns to the button, as I'd expect. But when activating a menu item, visible focus disappears. (It seems like it's then being set back to the beginning of the page, maybe.)
Works as expected--and focus returns to the button by default upon menu item activation.
Visibility issue
Please see #2710
Mac Safari/VoiceOver, Win Firefox/NVDA, Win Chrome/JAWS, Android Chome/Talkback
Dropdown works well with these combos. I do have one question. Do you want/need to have a default designated focus destination when a menu item is activated and the dropdown closes? After pressing
esc
, focus returns to the button, as I'd expect. But when activating a menu item, visible focus disappears. (It seems like it's then being set back to the beginning of the page, maybe.)
@nikkimk wdyt?
I'm going to merge this now, and if @nikkimk you want to adjust the default focus behaviour that @hellogreg mentioned above, we can follow up later or do a patch release
What I did
Testing Instructions
custom-trigger
demoNotes to reviewers
This is required in order to replace the docs version
<select>
with pf-dropdown