Accessibility regression with masonry layout changes

[KevinBatdorf]

Originally posted by @KevinBatdorf in #49958 (comment)

Reflowing the content using the css masonry column rules introduces new behavior for keyboard users that tab through the document.

In this screencast I am pressing tab to move into the content area, then I press the right arrow key.

Screen.Recording.2023-05-08.at.1.44.52.PM.mov

Since the order of the document no longer represents the visual order of the content, the arrow key right-left movement now moves up-down. As you can see in the video, the jumping from the bottom to the top could also be visually confusing to the user as well, especially if there are very many patterns.

There likely isn't a good solution for this unless the mechanism to move left/right gets an upgrade to detect what's visually nearby (I suppose by checking the bounding box), or the masonry functionality is implemented with a JS solution that maintains a document order that follows the visual representation.

[annezazu]

cc @jameskoster since you were working on this!

[jameskoster]

How is the behavior in the "Browse all patterns" modal (at the bottom of the pattern Inserter)? We could adopt that layout here instead. It would be a bit of a shame as the masonry configuration works well given the diverse nature of patterns, but it is an option to consider.

[KevinBatdorf]

It's using a grid layout so would end up looking how it did previously to that merge.

reakit (that handles the keyboard movement) doesn't seem to support masonry layouts or customizing the keyboard controls either it seems, unfortunately.

This would likely need to be rewritten using absolute positioning and built by measuring each pattern's dimensions (pre and post load) and placing them accordingly, combined with some virtualization mechanism to keep it performant with large lists., or pagination to mitigate performance overhead. i.e. a bunch of work.