Site Editor: Tab order of editor canvas and resize handle

[mirka]

In #52443, it was raised that the tab order of the editor canvas and resize handle was unintuitive:

One thing I found a bit confusing is that the 'Drag to resize' handle is placed in the tab sequence after the iframe. I would expect to find it between the navigation and the iframe so that it also matches the visual order.

It would be nice if we could flip the tab order. However, it isn't very easy because the element order depends on the re-resizable library under the hood.

Also, in the general case, resize handles can be on any edge or corner. It's only in this specific case where the handle is only on the left edge. So I do see an argument to optimize for consistency in the general case (for example the one in Style Book with two handles), and have all handles come after the frame.

[afercia]

To my understanding, the problem with the ResizableBox component and the re-resizable library is that it is meant for a different use case :)

By default, re-resizable draws a rectangular box with 8 handles: 4 for the corners and 4 for the edges. Screenshot:

To do so, re-resizable draws an overlay above the element that is resizable and in the DOM order the overlay comes after.

It is possible to hide or disable the handles and keep just one or two of them but regardless they will always come after in the DOM order. I'm not sure there is a way to hack around the re-resizable library but anyways I'm not sure hacking it would be future-proof.

I tend to think the ResizableBox component based on re-resizable is just not the right tool for our use case.

Worth reminding that the DOM order problem occurs also in the Style Book where there is an additional problem:

• Both handles come after the resizable content.
• The right handle is placed in the DOM before the left one so the Tab order is from right to left, which is a totally unexpected user experience.

Marking this issue as a bug because the mismatch between visual order and DOM order is a WCAG violation.

[afercia]

Looking into this after some time. I'd think the best way to solve this issue would be:

• either submit a change request upstream
• or fork re-resizable and build our own, so that we can change its render method.

Looking at re-resizable code:

https://github.com/bokuweb/re-resizable/blob/0f6b2ddcbab2a2864c209e0a59a67b6d51adab86/src/index.tsx#L949-L955

    return (
      <Wrapper ref={this.ref} style={style} className={this.props.className} {...extendsProps}>
        {this.state.isResizing && <div style={this.state.backgroundStyle} />}
        {this.props.children}
        {this.renderResizer()}
      </Wrapper>
    );

• renderResizer renders the resizer overlay, which contains the resize handles.
• The resizer is always rendered after the resizable element (the children passd via props).
• Instead, what we need is;
  • An option to render the resizer before.
  • Even better: a way to render each resize handle before or after the resizable element.