cauldron
cauldron copied to clipboard
dequelabs
Accessibility issue if `<Layout />` component has overflow and 0 focusable children (sighted keyboard users are unable to scroll the layout region)
We should revisit how this layout container works and potentially move back to the more simple approach of allowing the body to have overflow.
Background on this decision was that we wanted to avoid the browser allowing things to be in focus behind our topbar. By default, the browser will minimally scroll a focused element into "view" but as far as the browser is concerned, being behind the topbar is in "view"
@schne324 Do you know if this is still an issue or anything we can do to address it? Is there an example somewhere either in cauldron or one of the webapps?
@scurker, sorry for the lack of info. I just updated the title which should help clarify which a11y issue we are referring to here. The gist of it is that sighted keyboard users have no way of scrolling our layout container with a keyboard when there aren't any focusable elements within the layout container. This is a result of our layout container being the scrollable region on the page rather than just the <body /> element like "normal" web apps (my fault btw--I'm the one who did that 😜 ). The solution for anyone running into this right now would be to set tabIndex={0} on the <Layout /> scrollable element but I think cauldron should consider refactoring our layout to allow the <body /> to be the scrollable element and let browsers handle reflow and allow keyboard users to use their expected means of scrolling a page with ↑ and ↓ keydowns
Thanks for the background. I'd definitely like to reconsider how we do content layout because it's funky and does cause issues as you mentioned and isn't well documented. Maybe that's something we can get together at some point and discuss in more detail since it might be difficult to avoid breaking changes in cauldron with this change unless we're really creative.