CC @1Copenut for thoughts
Push flyouts (link)
These flyouts have the most severe keyboard/screen reader accessibility issues that may or may not require addressing depending on what the intention of them are. Current issues:
-
Focus traps on them are completely disabled. Keyboard users are not automatically focused into the flyout. Flyouts do not trap focus (users can tab in/out at all). Depending on where in the DOM the consumer places the push flyout, accessing the flyout can either be a huge headache or visually not make sense with the rest of the page.
-
Focus is not automatically returned to the flyout toggle on close (focus stranding)
-
Push flyouts do not close on Escape keypress
At first glance, all of these issues seem extremely problematic. However, if the goal of these "flyouts" is really more to "conditionally render some content within the existing flow of the page but visually to the side", then maybe they're not really dialogs at all, and we can get away with simply removing role if type === 'push' and call it a day? 😕
Or, should we prefer to say "no, these are definitely dialogs, treat them like ownFocus={false} flyouts?
ownFocus={false} flyouts (link)
While not nearly problematic or difficult for keyboard/SR users to use, the main problem with ownFocus={false} flyouts is that they deliberately advertise a functionality available to mouse users that is not available to keyboard/SR users:
Mouse users are allowed to interact with items outside the flyout, keyboard/SR users are not. While this is certainly a design/UX decision, it feels like a slightly unfair/against best practices one, since usually the recommendation for accessibility parity is that keyboard users should be able to access everything mouse users can.
That being said, in this case it's not a hugely debilitating UX loss (unless some team in Kibana is literally relying on outside-flyout changes to happen at the same time as inside-flyout UI/UX), so I think we would have a case for keeping this as-is, but I would want to make sure it's an extremely conscious and a11y-vetted decision.
CC @1Copenut for thoughts
Push flyouts (link)
These flyouts have the most severe keyboard/screen reader accessibility issues that may or may not require addressing depending on what the intention of them are. Current issues:
Focus traps on them are completely disabled. Keyboard users are not automatically focused into the flyout. Flyouts do not trap focus (users can tab in/out at all). Depending on where in the DOM the consumer places the push flyout, accessing the flyout can either be a huge headache or visually not make sense with the rest of the page.
Focus is not automatically returned to the flyout toggle on close (focus stranding)
Push flyouts do not close on
EscapekeypressAt first glance, all of these issues seem extremely problematic. However, if the goal of these "flyouts" is really more to "conditionally render some content within the existing flow of the page but visually to the side", then maybe they're not really dialogs at all, and we can get away with simply removing
roleiftype === 'push'and call it a day? 😕Or, should we prefer to say "no, these are definitely dialogs, treat them like
ownFocus={false}flyouts?ownFocus={false}flyouts (link)While not nearly problematic or difficult for keyboard/SR users to use, the main problem with
ownFocus={false}flyouts is that they deliberately advertise a functionality available to mouse users that is not available to keyboard/SR users:Mouse users are allowed to interact with items outside the flyout, keyboard/SR users are not. While this is certainly a design/UX decision, it feels like a slightly unfair/against best practices one, since usually the recommendation for accessibility parity is that keyboard users should be able to access everything mouse users can.
That being said, in this case it's not a hugely debilitating UX loss (unless some team in Kibana is literally relying on outside-flyout changes to happen at the same time as inside-flyout UI/UX), so I think we would have a case for keeping this as-is, but I would want to make sure it's an extremely conscious and a11y-vetted decision.