Re: [Bug-XBoard] Accessibilty request.

I looked a bit at XBoard, and it seems the accessibility is awful. I 
recal that someone
was doing a GSOC project on this, but I never heard about it again.

For use by blind people it is essential that everything can be 
controlled from the keyboard.
But XBoard does not even have a way to pen the main menus through 
keystrokes. This
is easily repaired by using "gtk_menu_item_new_with_mnemonic" in stead 
of ...with_label,
and putting underscores in the menu names before the shortcut letter. 
This will allow
people to use <Alt> + letter to open the corrsponding menu. For 
selecting an item from
the menu he is then dependent on the up/down arrow keys, as the 
individual menu items
also have no mnemonics defined for them.

One of the WinBoard for JAWS features which was pretty essential was the 
ability to
navigate through all windows using the Tab key. Within a GTK dialog the 
Tab key navigates
through all controls, and allows the user to type something there, 
toggle a checkbox, etc.
This is perfect for transient dialogs, as they are supposed to grab all 
mouse and key events,
and allow return to other windows only after you close them. But in the 
non-modal 'auxiliary
windows' Engine Output, Move History, Edit Tags/Comment etc. there are 
large (multi-line)
text edits, where Tab is considered valid input, and is just added to 
the text edit that has focus.

In WB for JAWS operating the Tab key in those windows navigates between 
them, through a
'grand loop' chess board -> main window button bar -> Engine Output 
upper pane -> Engine
Output lower pane -> Move History -> ICS output -> ICS input -> chess 
board...

Windows that are not open are skipped. As usual Shift + Tab navigates in 
the opposite
direction. Most of the items in the gand loop are read-only, but it is 
important for a blind
person to give them focus, because that triggers the screen reader 
reading their contents.
The rationale behind the orderis that (in ICS mode) starting to type to 
the board automatically
transfers focus to the ICS Input, so that there is no disadvantage to 
having ICS input late in
the cycle. When the board has focus, the arrow keys control a 'board 
cursor', highlighting a
'current square' and speaking its contents.

To implement this in XBoard we would need to define handlers for 
keyboard events on
the various text memos, to intercept Tab and transfer focus to the next 
item in the loop.

Normally a screen reader should start reading out loud the item that 
receives focus.
Blind persons will surely have a screen reader, or they could not use 
the computer at all.
If the screen reader would not operate on GTK dialigs because they do 
not use native
OS X API, there would be a problem, and we would have to provide an 
'acquired focus'
event handler for every coltrol element, sending the name of the element 
to a voice
synthesizer to emulate a screen reader.

The number of cases where WinBoard for JAWS sends text to the voice 
synthesizer itself
is quite small: moving the board curser, and when a new move appears 
above the board
(as in WinBoard there is no independent message widget, and the move+PV 
text is
is part of the board graphics there). And then there is an extra menu 
with explicitly
requests voice output for various purposes: reading out the entire 
position, telling
the moves from or to the current squares, repeating the last move, etc.