Exactly this. For a game engine, accessibility looks like the ability to maintain a tree of accessibility nodes which a screen reader can interrogate and present. In the game engine itself, I'd expect any in-engine UIs to push UI updates to the accessibility API, meaning my screen reader knows whether a button, label, editable text, etc. is on-screen and presents it to me.

In games themselves, I'd say the possibilities are fairly unexplored. Something like a roguelike could, for instance, treat its map as an accessible object with the grid role. Each tile would then be a cell with whatever item(s) are visible on it as its description. Ideally the game would have keyboard controls, but even without them, it would be instantly possible to explore the map with a screen reader, route the mouse to and click on individual tiles, etc. Similarly, the game log could be exposed as text and a live region, meaning it gets read whenever it changes and can also be reviewed with screen readers.

Obviously that doesn't just happen for free, and someone has to do that work. But now with Bevy someone can, and doesn't get bogged down in either having to re-implement that logic on each accessible platform, or avoiding footguns necessary to setting things up (E.g. keeping the window invisible until accessibility is initialized, which is needed under Windows and handled automatically by this integration.)