Modeling dockable panes

[viridia]

Hi, I'm the primary author of Bevy Feathers, the UI widget library that is slated to be used for the official Bevy editor, currently under construction. One of my goals has been to closely follow AccessKit and ARIA when modeling widget states. However, one of the things that users are asking for is dockable panes: the ability to drag panes around and configure the layout of the editor. I did some research, and it looks like this is outside of ARIA's scope (although there are some older, deprecated things like "grabbed").

What I'm wondering is, should I implement docking of panes independently of AccessKit, or is there some way I can model this behavior in the accessible metadata?

[DataTriny]

Hi @viridia, nice to see you back! There isn't any clearly defined way to expose dockable panes to assistive technologies, either in ARIA or AccessKit currently. Here are a set of common patterns I have seen in the wild:

• Use Splitter nodes to control the size: with numeric_value, min/max, orientation, reacting to arrow keys matching the orientation...
• Use F6 / Shift+F6 to jump between panes.
• Docking/undocking is usually accessible through a button or a popup menu on the pane title bar.
• Moving is usually restricted to a predetermined set of positions accessible via a popup menu, a button could transition to a "move mode" where arrow keys would control the location of the pane.
• You'd likely need a status node somewhere to announce these custom events, like entering or exiting "drag mode". Note that we have not really tackled the status role right now, I don't even know if it works out of the box on desktop platforms or if we would need to fire specific events for it.

I hope that's useful to you. Feel free to ping me somewhere if you need a tester. I'll try to install good old Miccrosoft Visual Studio if I find the time, I recall the interface was quite well designed in that aspect.