GNU nano with terminal emulator accessibility layers: status bar and wrap indicator exposure

The goal is to clarify how GNU nano’s user-facing workflow elements are exposed through a terminal emulator to assistive technologies, with a focus on consistent accessibility support.

Nano uses a bottom status bar for commands and a modal-like prompt behavior for actions such as save confirmation. Keyboard shortcuts rely on control-key mappings that can conflict with terminal emulator shortcuts, and the editor’s accessibility surface is constrained by the terminal’s handling of escape sequences and its ability to expose the buffer to assistive technologies.

An unresolved behavior concerns the consistency of soft-wrap versus hard-wrap visual indicators when external accessibility overlays interact with the terminal. The status bar may not be natively announced without specific terminal configurations, and sequential key-press workflows for Search and Replace lack a unified command palette.

What information about the status bar and wrap mode state is made available to the terminal emulator’s accessibility API? Is the soft-wrap versus hard-wrap state distinguishable to screen readers through the terminal? Is there a documented contract for modal prompts to be announced without interrupting the primary text-entry flow?