[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XBoard-devel] [Bug-XBoard] Accessibilty request.
From: |
H.G. Muller |
Subject: |
Re: [XBoard-devel] [Bug-XBoard] Accessibilty request. |
Date: |
Tue, 20 Jan 2015 15:44:25 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [XBoard-devel] [Bug-XBoard] Accessibilty request.,
H.G. Muller <=