> Begin forwarded message:
> 
> Subject: Re: [Bug-XBoard] Accessibilty request.
> From: Joshua Pettus <[email protected]>
> Date: January 20, 2015 at 10:05:41 AM EST
> To: "H.G. Muller" <[email protected]>
> 
> What about using Orca, Gnome’s screen reader, as the screen reader for GTK 
> stuff and OSX’s VoiceOver for the OSX menubar.  
> To be honest I have no idea if Orca can be compiled for OSX.  It is likely 
> beyond my ability, but should be a decent solution for linux, and I’m told is 
> included with Ubuntu.
> 
> -Josh
> 
> 
> 
>> On Jan 20, 2015, at 9:44 AM, H.G. Muller <[email protected]> wrote:
>> 
>> 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.
> 

_______________________________________________
Bug-XBoard mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-xboard

Reply via email to