GNOME Bugzilla – Bug 511468
Ekiga chat window accessibility problem.
Last modified: 2009-05-27 01:16:55 UTC
Steps to reproduce: 1. Launch ekiga and setup a h323 chat. 2. Invoke screen reader, orca. 3. Chat with another setup ekiga. Bug observations: When user typing words in his chatting window, the message sent by other can not be read by default, user has to change focus to the chat pane and get the message. If user did not change focus position, it's impossible to get informed that there is a new message coming.
This may call for a script in Orca, much like what was done for GAIM/Pidgin.
Can you propose a patch? Is it still current in 3.00 ?
The Orca team hasn't had a chance to look into these issues yet, but my hopes are that we can handle this in a script in Orca. Reassigning this to Orca for now.
Retargeting for 2.27.3 since I'm now looking more closely at Orca's support for Ekiga.
Created attachment 135192 [details] [review] proposed (interim) fix - version 1 1. It seems that we are not getting any text-inserted events initially. "Tickling" the hierarchy changes that. Go figure.... 2. We need special handling to present the text in the chat history. This patch addresses both of the above. Also, please note that this patch does NOT add in all the functionality (e.g. chat room history, distinguishing between focused and non-focused chats, etc., etc.) we have in pidgin. It just gets the messages speaking -- which is better than what we currently have. Will, please review. Thanks! Also, thoughts for inclusion in 2.26.3?
(In reply to comment #5) > Created an attachment (id=135192) [edit] > proposed (interim) fix - version 1 > > 1. It seems that we are not getting any text-inserted events initially. > "Tickling" the hierarchy changes that. Go figure.... > > 2. We need special handling to present the text in the chat history. > > This patch addresses both of the above. > > Also, please note that this patch does NOT add in all the functionality (e.g. > chat room history, distinguishing between focused and non-focused chats, etc., > etc.) we have in pidgin. It just gets the messages speaking -- which is better > than what we currently have. > > Will, please review. Thanks! Also, thoughts for inclusion in 2.26.3? This is simple and isolated to the Ekiga script. I think it looks great and improves Ekiga nicely. Definitely go for master and gnome-2-26. Thanks!
Thanks Will. Patch committed to both master and the gnome-2-26 branch. Closing as FIXED.
Jacob reported on the Orca list that this fix causes us to speak the call duration constantly. I was able to reproduce this issue using the Echo test. What distinguishes the two text objects is that the chat history's parent is a scroll pane. Therefore the following one-line change should solve the problem: ~~~~~~ --- a/src/orca/scripts/apps/ekiga.py +++ b/src/orca/scripts/apps/ekiga.py @@ -58,7 +58,8 @@ class Script(default.Script): - obj: the accessible object to examine. """ - if obj and obj.getRole() == pyatspi.ROLE_TEXT: + if obj and obj.getRole() == pyatspi.ROLE_TEXT \ + and obj.parent.getRole() == pyatspi.ROLE_SCROLL_PANE: state = obj.getState() if not state.contains(pyatspi.STATE_EDITABLE) \ and state.contains(pyatspi.STATE_MULTI_LINE): ~~~~~~ Because this is a safe, one-line change which solves the problem, is limited to the Ekiga script, is pylinted, yadda, yadda, yadda, I've gone ahead and committed this change both the the gnome-2-26 branch and to master.
*** Bug 583947 has been marked as a duplicate of this bug. ***