Expanding on what I brought up at today's office hours.

Parley's LayoutAccessibility API requires access to the root TreeUpdate, which it pushes nodes directly into. When trying to integrate this into egui, I ran into an issue: egui's AccessKit integration does not expose that TreeUpdate. It seems that in egui, the intended way to create an AccessKit node is through Context::accesskit_node_builder, which pushes the node into the TreeUpdate itself (technically, it defers doing that until later). For reference, see the current code for AccessKit text interop.

I've managed to work around this in my current branch by creating a dummy TreeUpdate for Parley and then taking the nodes from it, then overwriting the entire node that accesskit_node_builder gives us but this seems a bit fragile and results in a lot of extra allocations.

@mwcampbell mentioned potentially changing Parley's AccessKit API to something callback-based. I assume this means something like Parley calling a provided callback once per node that it creates, which seems like a good API to me.

egui's accesskit_node_builder approach provides the node itself and requires all its properties to be instantiated within its callback, and integrating that with Parley seems like it'd require some gnarly nested callbacks--Parley would call a "node factory" function, which would call accesskit_node_builder, which would then call some Parley-provided function with the node that it created. Some extra flexibility on egui's side may therefore also be necessary.