Re: The new text-mode menu and the cursor in -nw mode

[Mario Lang]

Eli Zaretskii <address@hidden> writes:

>> From: Mario Lang <address@hidden>
>> Date: Mon, 28 Apr 2014 14:21:46 +0200
>> 
>> The new text mode menu is nice, something I have been waiting for since
>> a long time.  However, I have an accessibility issue with it: When I hit
>> F10 to go to the menu, the menu pops up and the selected item is
>> highlighted with a change of color, but the terminal cursor stays at the
>> place in the currently selected buffer.  I can see that this makes sense
>> for some use cases (you can still see where point is while navigating
>> the menu), but it is quite a problem to (some) blind users of Emacs.
>
> Actually, we turn off the cursor while a menu is active, because
> otherwise it can show through the menu, which is ugly.  We turn it
> back on only when the menu pops down, i.e. the user either makes a
> selection or quits the menu.

As far as I am concerned, this is only a visual trick, see below.

>> Screen readers on UNIX usually do only track the hardware cursor
>> position, but they do not track background color changes.  So my screen
>> reader has currently no way to follow the currently selected menu item,
>> which makes the menu as such, rather useless because it is very
>> time-inefficient for me.
>> 
>> Similar to my recent request about allowing blink-matching-paren being
>> set to 'jump, and therefore getting the old hardware-cursor behaviour
>> back, I'd like to ask if there is a way to enhance the new text mode
>> menu with a user option to have the terminal cursor jump to the
>> currently selected menu item?  
>
> Please tell more, as I don't yet understand the requirements (and
> don't have Unix screen readers anywhere near me to try this myself).
> E.g., is it OK to have the cursor turned off when the menu is
> displayed?  IOW, are you saying that only the cursor coordinates
> matter, not whether it is visible or not?

Exactly.  Typical screen readers do not differenciate between
visiable and non-visible cursors.  What they do, is to position
the viewing area around the (visible or not) hardware cursor.

So, if we keep the hardware cursor invisible, that is perfectly fine to
me.   What I need is the hardware cursor positioned at the currently
selected item in the menu.  Either on the first character, or the
character preceding it, would be most convenient.

> Next, what happens when some sub-menu is selected?  When the user
> does this, we redraw large portions of the screen (to remove the old
> menu and display the new one), and each screen line that is partially
> or fully redrawn causes cursor motion -- will this cause those
> portions that are redrawn to be read, and if so, is that OK?

It would be ideal to only reposition the cursor when the drawing has
been complete.

> Also, moving to a different menu item will generally display the
> corresponding help echo in the echo area -- does it matter whether the
> help echo is read before or after the newly highlighted menu item?

I don't think it matters much, although it might be better to display
the echo are change *after* the menu change has been redrawn.

> Finally, what exactly is read by the screen reader, given a cursor
> position?  That is, how does the reader know when to stop reading
> stuff off the screen?  I'm asking this because the TTY menus overlay
> the buffer text at some arbitrary place, so where the menu item ends,
> there's some random text, which typically starts in the middle of a
> word.  If the reader will read that, you will hear a terrible
> gibberish.

I am a braille user.  A braille display typically consists of 40 or 80
characters.  When the hardware cursor position changes, my braille
display is typically updated around that cursor position.  As a braille
user, I can make sense of text that is mixed, i.e., I can understand
that a part of the text is related to the menu item, and the rest is
related to the text that was displayed before the menu overlayed this
area of the screen.  Speech users typically can also cope with this
situation.  However, as mention in this thread, what is important to
both groups, is
that the hardware cursor position is update if the currently
"highlighted" area of the screen changes, so that the screen reader can
"follow" the hightlight around on the screen.


> Thanks.

Thanks for asking, and answering so swiftly.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang/address@hidden
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>