niklasegger
commented
1 week ago In modern web applications and pages, there are often iFrames that need to be moved in the DOM from A to B or lists that can be reordered by the user - just to name two examples. From a technical point of view, these elements must first be removed from the DOM and then reinserted in the desired position. As a result, the elements lose their state as well as their focus/selection. As the issue thread shows, the consequence for many developers and frontend frameworks is to implement their own work arounds, some of which have disadvantages. In one iFrame example, it is explicitly mentioned that the accessibility tree breaks due to the work around.
The desired introduction of native atomic move operations, for example in the form of a new API, should make it possible to move the elements without these negative side effects and without the overhead for the developer. With regard to the examples mentioned, this also makes sense from an accessibility perspective. If the iFrame content loses the scroll position and returns to the top of the loaded page, this can certainly be confusing for some user groups and should therefore be avoided.
Moreover, the API must be compatible with ARIA. For example, when some content is moved into an Aria-Live component. As atomic moves and the general implementation are quite low-level and beyond my expertise, I don't know if this is automatically taken into account and works out of the box. I haven't read anything about ARIA in the discussions, so I wanted to write it down here to be on the safe side.
Another case I can think of is when you move a list entry from list A (“Do”) to list B (“Done”) and the focus is kept. In this case, the usual screen reader information should be read out, just as if you had tabbed into the second list normally.
Maybe out of scope, but I had to think of „WCAG 3.2.1 On Focus“ and „3.2.2 On Input“ when reading the thread. Because of the possibility of sudden focus changes i.e. when the focused element is moved to a different location. If the API progresses and a W3C document is created, these points should probably be listed in the accessibility section.
I hope my thoughts make sense.
This is a tracker issue. Only discuss things here if they are a11y group internal meta-discussions about the issue. Contribute to the actual discussion at the following link:
§ https://github.com/whatwg/dom/issues/1255