Tk Source Code

Since all widgets are activated when mapped and the API is limited to tk windows it doesn't seem to make sense to have a proc to add an object. When would someone use it ?

See: 
https://github.com/tcltk/tk/blob/main/library/accessibility.tcl#L1109
https://github.com/tcltk/tk/blob/main/library/accessibility.tcl#L1268

However, since under X11 the screenreader doesn't seem to work automatically it would be useful to have ::tk::accessible::speak exported. Isn't it ?

https://github.com/tcltk/tk/blob/main/library/accessibility.tcl#L102

Closing, see the previous comments.

You CAN use thst command - the exported script-level API is “tk accessible add_acc_object” etc.  Your use of internal interfaces is not supported.

First of all, thank you very much for your time and effort to implement the feature. It overall looks great and I can't wait to use it.

"has a more rigid structure and does NOT support posting any kind of custom notification"
I think I understand that. But I also thinking about a canvas listing rows of text. I can route the focus to these elements and it would be possible to change  the value on the canvas by accessible::set_acc_value and posting emit_selection_change would work for Orca and NVDA, as far as I can tell, but without accessible::speak I can't implement the same clever trick as you did.

That's why I think it should be exported.

Custom widgets would be any Tk widget not part of the core, such as tablelist. The accessibility API supports registering such widgets, assigning them a role, and otherwise making them accessible. 

You are correct that ::tk::accessible::speak is necessary to make accessibility complete on X11. NSAccessibility and MSAA both support custom events or announcements to verbalize state changes. This is useful in cases where we are dealing with window elements that are not full Tk windows, such as listbox rows or text; we can use selection or other Tk events to capture the live data in the widget and pass that to the accessibility API as a string to be verbalized. I used this design to keep the accessibility API manageable; exposing text and other window sub-elements as accessible objects would have added a great deal of complexity. It's a compromise, but an acceptable one. 

ATK, the accessibility API I chose on X11, has a more rigid structure and does NOT support posting any kind of custom notification. Calling out directly to the speech engine powering Orca, the X11 screen reader, allows us to implement the same functionality as the custom events/notifications on macOS and Windows. This works because of the tight integration between the speech engine and Orca - the voices are the same. So the accessibility experience is more or less seamless on X11.

Not sure what you mean by custom widgets. However I see speak is been used in various places where on other platforms `emit_selection_change` would be sufficient. It appears to me that on X11, without speak, the feature would be incomplete.

Also, the “add” proc is there to allow registration of custom widgets.

“speak” is an internal function to support the accessibility implementation on X11 for certain widgets and datatypes. It is not intended to be a public function.