According to: https://www.bugzilla.org/docs/4.4/en/html/bugreports.html, "...the severity of the bug (if the bug you found crashes the program, it's probably a major or a critical bug; ... if it's something you would like to see implemented, then that's an enhancement)." This is not a "critical" "bug". Adjusting the importance accordingly.

Also, from what you stated on the Orca list, you believe Orca should add this support for something you did in xboard. Perhaps it's this commit and/or something similar? http://git.savannah.gnu.org/cgit/xboard.git/commit/?h=gtk3&id=431bea4b49

Things like "It's your turn" do not strike me as accessible descriptions. A widget's accessible description provides additional details **about that widget**. It's the kind of information you see when you hover your mouse over a widget and a tooltip pops up. How does "it's your turn" tell the user more about the widget and how to interact with that widget? Seems to me like that might instead be providing additional details about the state of game being played. Furthermore, it sounds like what you want to notify the user. Which brings me to the following:

The reason why Orca currently does not listen for accessible description changes is because accessible descriptions typically don't change. Orca does, however, present notifications. Would it instead make sense for you to either use platform notification support from within xboard to say things like "it's your turn"? Alternatively, could you create an object with ATK_ROLE_NOTIFICATION with that text and then show the object (i.e. so it emits an object:state-changed:showing event)?

First of all sorry for the mistake! 

>>Would it instead make sense for you to either use platform notification >>support from within xboard to say things like "it's your turn"? Alternatively, >>could you create an object with ATK_ROLE_NOTIFICATION with that text and then >>show the object (i.e. so it emits an object:state-changed:showing event)?

The second method is preferred. So I created a label at the bottom to notify this kind of information and give it ATK_ROLE_STATUSBAR, also make the graph as mnemonic widget for that label. But orca is not announcing change in status bar. So how should I do this ?

(In reply to Nalin-x-GNU from comment #2)

> The second method is preferred. So I created a label at the bottom to notify
> this kind of information and give it ATK_ROLE_STATUSBAR, also make the graph
> as mnemonic widget for that label. But orca is not announcing change in
> status bar. So how should I do this ?

Short version: Assuming what I say in the long version is correct (i.e. about what it is you've done/not done), try putting the label with the "it's your turn" inside a GtkContainer which is inside the status bar. Use ATK to set the role of that GtkContainer to ATK_ROLE_NOTIFICATION. Lastly, emit state-changed showing events to show/hide the notification.

-----

Long version:

There are a lot of chatty status bars, so automatically speaking changes would annoy users if done across the board. (And no, we don't need a checkbox for that. ;)) But your status bar approach seems a lot more reasonable. After all, the status IS changing. So let's see if we can tweak it into convincing Orca it's a notification. In order to do so, you'll want an object which:

1. Has the text you want Orca to present as a notification
2. Has a role of ATK_ROLE_NOTIFICATION (so Orca knows that's what it is)
3. Emits an object:state-changed:showing event with detail1 = 1 (true)

Going just based on what you described, I'm guessing you don't have all of the above and instead have an object which:

1. Has the text you want Orca to present as a notification (good)
2. Has a role of ATK_ROLE_LABEL and a parent of ATK_ROLE_STATUSBAR (fails here)
3. Might emit an object:state-changed:showing event with detail1 = 1 (??)

In order for you to confirm or deny my theory: You should be able to examine the roles in Accerciser's tree of accessible objects (left-hand pane usually). Accerciser also has an event monitor which you should be able to use to see what events you are emitting. With respect to the latter, here are some protips I've learned the hard way: ;)

1. You only want to monitor the selected application (at most; selected accessible sometimes works, but sometimes is too narrow). If you monitor all applications and are using an accessible graphical desktop environment, you may be flooded with spewage.

2. You want to narrow down the types of events you are monitoring. object: is too much. Heck, object:state-changed might still be a bit much depending on your app. But give it a try.

Assuming I'm right about my theory.... What might be an interesting thing to try, and which might be a good compromise between you adding sad hacks and me adding them is what I said in the short version, namely:

1. Keep the status bar as-is.
2. Keep the label as-is (insofar as it is where the text is)
3. Put that GtkLabel in some sort of GtkContainer
4. Set the accessible role of that GtkContainer to ATK_ROLE_NOTIFICATION
5. Each time you need to notify the user of the status change:
   a. emit object:state-changed:showing false on the container/notification
   b. change the label text to the thing you want Orca to present
   c. emit object:state-changed:showing true on the container/notification

That should not change the appearance of your UI. And it should hopefully convince Orca that a new notification has appeared every time xboard wants to tell the user something.

Lemme know how that works out for you.

Thanks a lot!! http://git.savannah.gnu.org/cgit/xboard.git/commit/?h=gtk3&id=8212cf2a30916a0ded4abd90e518fdf247a3535c 

Please let me know any more ideal solution for this :P :)

(In reply to Nalin-x-GNU from comment #4)
> Thanks a lot!!
> http://git.savannah.gnu.org/cgit/xboard.git/commit/
> ?h=gtk3&id=8212cf2a30916a0ded4abd90e518fdf247a3535c 
> 
> Please let me know any more ideal solution for this :P :)

Since I'm still traveling, I've not yet built and tested it. Did that commit solve everything for you? Or are there still issues related to the bug you opened here?

Yes it solved everything :) Yup it's working well :) I was searching for this ideal solution :P Once again thanks a lot :)

The additional widget is bit annoying for sited users. So I hide it using simple gtk_widget_hide but this makes orca not announcing the information. But orca simply announces the role name("notification") on each change. I think orca should announce that too.

I'll try to take a look, but it might be a day or three as I've got some deadlines and meetings.

In the meantime, here's my guess:  gtk_widget_hide takes the AtkObject backing the GtkWidget out of the accessible tree. This is something you can check via Accerciser. If it's not in the accessible tree, then Orca cannot find it let alone speak it. If that is indeed what's going on, is there a way you can get the AtkObject(s) needed back in the tree without annoying sighted users?

By the way, something I was wondering the other week (and then promptly forgot about due to being busy and your indicating the problem was solved for you) is: If a/the main reason for these notifications is to tell the user where he/she is when navigating on the board:

1) Is there an accessible object for each square? If not, why not?

2) If there is an accessible object for each square, and:
   a) its accessible name was based on its position and piece
   b) it emitted an object:state-changed:focused event when moved to

Orca should speak the name and piece without any status-bar-notification hacks or support.

>>If a/the main reason for these notifications is to tell the user where he/she >>is when navigating on the board:

Ahh not only that. These include possible attacking moves, say time remaining, last machine move, white piece positions, say upper diagonals, announcing machine vs machine play. etc etc.


>>In the meantime, here's my guess:  gtk_widget_hide takes the AtkObject backing >>the GtkWidget out of the accessible tree. This is something you can check via >>Accerciser. If it's not in the accessible tree, then Orca cannot find it let >>alone speak it. If that is indeed what's going on, is there a way you can get >>the AtkObject(s) needed back in the tree without annoying sighted users?

Ahhh nope! gtk_widget_hide is not hiding that widget from tree. I can see it using accerciser. I think orca should announce this. I will send(email) the patch for xboard that can make status bar hide.

Ok, I'll see if I can debug this today. Thanks.

Orca was looking for visible labels. Which is normally appropriate; just not for this approach. <insert shrug here> Anyhoo, I've fixed that in master:
https://git.gnome.org/browse/orca/commit/?id=52064c1e190

Also, given that we seem to be using a bug which is closed and whose summary reflects something that is very likely not going to happen (i.e. "Orca should announce the changed accessible-description property"), I'll re-open this bug and change its summary.

Given that we're getting close to the GNOME release, is there anything else I need to do in Orca to support XBoard Gtk?

Nothing! The latest orca is working fine with accessible XBoard. Thanks for your great co-operation and support :)