joouha
commented
1 month ago Hi,
I have a heavily modified alternative menu widget implementation in euporie which does this:
https://github.com/joouha/euporie/blob/77e1d06170bc69820fb24be63638c3af4fd25069/euporie/core/widgets/menu.py
Blind dev here. While playing with the various examples in the prompt_toolkit repo, I noticed that MenuContainer is lacking cursor positioning, which makes it very hard to use with a terminal screen reader like BRLTTY.
For a bit of background, I wrote about a similar issue in the Haskell brick library roughly 3 years ago:
https://blind.guru/blog/2021-06-25-brick.html
(Since then, all the deficiencies with Brick in regards to cursor positioning have been fixed by either me or the brick maintainer.)
The short story: Screen readers for the blind actually use the cursor position to track what part of the screen currently has "focus". For editing fields, it is obvious how this works. For other widgets, the general idea is: Position the cursor where the focus is, but maybe hide it to not confuse a sighted user.
I noticed that the Dialog widget of prompt_toolkit already does the right thing in respect to buttons. When I Tab through the buttons, the cursor is always placed inside the currently focused button.
For MenuContainer, something similar would need to be done such that the screen reader can track which menu/submenu is currently selected.
I am submitting this as an issue because I am very new to the prompt_toolkit codebase, and I am suspecting a dev with good knowledge about the codebase can fix this in about 10 minutes. It will take me a lot longer. However, I will try if this gets ignored long enough.
TL;DR: Screen readers use the cursor position regardless if the cursor is hidden or not. Using this fact to position the cursor at the currently highlighted widget greatly imroves the accessibility of a terminal application for people with low vision or blindness.