From federico on IRC:
GtkLabel just does two things for accessibility:
Set its role on the GTK side to GTK_ACCESSIBLE_ROLE_LABEL in the class initialization function gtk_label_class_init (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/gtklabel.c#L2675)
Later, that gets translated with gtk_accessible_role_to_atspi_role() to an AtspiRole enum value in gtk_accessible_role_to_atspi_role (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/a11y/gtkatspiutils.c#L38)
Those enum values in AtspiRole (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/a11y/gtkatspiprivate.h#L27-158) correspond to the integer values that the Accessible.GetRole() method expects (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/a11y/atspi/Accessible.xml#L40), and which are unfortunately just hardcoded in atspi-constants.h (https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/master/atspi/atspi-constants.h)
The other thing GtkLabel does is to change its text in its corresponding GtkAtContext. Every widget gets a GtkAtContext created for it; it's just an object that collects data to feed to the a11y backend. gtk_label_set_text_internal (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/gtklabel.c#L3010-3012) is where the label changes the text, and much later that gets collected, and sent to the accessibility backend's state_change method , gtk_at_context_update (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/gtkatcontext.c#L693-695)
The only implementation of state_change right now is for the atspi backend. And for labels in particular, gtk_at_spi_context_state_change (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/a11y/gtkatspicontext.c#L1084-1089) picks up the new accessible-name, and emits it as a dbus signal via emit_property_changed() in emit_property_changed (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/a11y/gtkatspicontext.c#L803-819)
Going in the other direction, when a screen reader asks an accessible object for its Name property:
The gtkatspicontext receives the property request from dbus, and processes it in handle_accessible_get_property (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/a11y/gtkatspicontext.c#L671-676) - that calls gtk_at_context_get_name(), which is at https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/gtkatcontext.c#L1091 and the first thing that function does is to call gtk_at_context_get_name_accumulate(), which does the ARIA magic to compute a name based on an object's actual label, labelled-by, etc. ([[https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/gtkatcontext.c#L929-934])]
How editable_handle_method() gets called? GTK uses the g_dbus API internally to talk DBus. Whereas in python it's super easy to do something like
@dbus.service.method('org.my.Interface.Name', in_signature="whatever", out_signature="whatever")
def MyMethodName(self, blah, blah, blah):
In C it's a bit more complicated. g_dbus wants to be told the path of the object, the name of an interface, and a vtable with functions that when called, can deal with calling methods or getting/setting properties
For example, https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/a11y/gtkatspicontext.c#L1341-1354 first gets the vtable for the editable text interface, and calls g_dbus_connection_register_object(). That vtable is gtk_at_spi_context_register_object (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/a11y/gtkatspieditabletext.c#L341-344) - its first element is the handler that g_dbus will call when it wants to call a method on the interface. The "call a method
From the editable text interface" handler is text_view_handle_method (https://gitlab.gnome.org/GNOME/gtk/-/blob/8944493e/gtk/a11y/gtkatspieditabletext.c#L209) - you'll see that it compares the method_name with SetTextContents, InsertText, etc. - all methods names from https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/master/xml/EditableText.xml