Well, if AtkUtil were a AtkObject, we could have tried to use:
http://library.gnome.org/devel/atk/stable/AtkObject.html#atk-object-get-attributes

AFAIK, AtkAttributeSet is oriented to the text related methods:
http://library.gnome.org/devel/atk/stable/AtkText.html#AtkAttributeSet

As there isn't any reason to not use that for more general things.

The missing thing is a general way to add attributes from the app or library side, something like atk_object_add_attribute. So, the attributes of a specific gailobject would be their custom implemention plus the one defined used this method (like ref_state_set, that each gailwidget get the set from their parent, and then add their custom ones).

As AtkUtil is not a AtkObjects, more new methods are required. So a proposal would be something like:
   atk_util_get_attributes
   atk_util_add_attribute
   atk_util_remove_attribute (not really required right now, but why not)

And keep using AtkAttribute type for coherence.

So, on the Webkit case, the solution would be something like:
   static void webkit_accessible_init(AtkObject* object, gpointer data)
   ....
   atk_util_add_attribute ("source", "Webkit");
   ...
And in orca:
   settings = atk_object_get_attributes (
   
BTW: as I said on webkit bug, and probably a nitpick, I wouldn't use a "toolkit:Webkit" pair. In that specific case, it is still using Gtk+ (so Gail) as a toolkit, by definition:
http://library.gnome.org/devel/atk/stable/AtkUtil.html#atk-get-toolkit-name
"Gets name string for the GUI toolkit implementing ATK for this application."
                          ^^^^^^^^^^^

I would use "source:Webkit" or something similar, but probably a minor detail here ;)

The issue we're dealing with here is that some applications may freely mix toolkits.  A prime example is Firefox mixing Gecko, XUL, and GTK+.  The implementation of some roles (e.g., combobox) can vary enough that an assistive technology can find it useful to know which toolkit an object came from on a per object basis.

As such, looking at the 'toolkit' field of an AccessibleApplication object is not sufficient since it applies to the entire application and not individual objects.

The proposal at hand is to add an object attribute that identifies the toolkit used to create the object.  Since the word 'toolkit' is already in use to identify this kind of thing at the AccessibleApplication level, I would argue that we either add a 'toolkit' field to the Accessible object or just make a 'toolkit' name to be reserved.  This name would be used to obtain an optional attribute from the object's attribute list and would specify the toolkit being used.

The attribute name itself is very important since assistive technologies will want to use just one attribute name (i.e., not 'guithingy' for the Java Swing toolkit, 'flurblekit' for Gecko, 'widgetset' for GTK+, etc.).

After think this a little more, and after Willie and Joanmarie explanation about how to use it, you can forget my comments about new methods on AtkUtil, and in fact what Joanmarie wanted, AFAIU, is just use atk_objet_get_attributes, but just opened this bug to conclude which attribute use, and how name it in any toolkit.

In the same way, probably I was just too obstinate with the "toolkit vs source" thing, something paradoxical, as I had the perfect example of why we would require to get the toolkit name per object: in the hypothetical mixed environment of Clutter and Gtk+, we will have objects created with different toolkits (Clutter vs Gtk+, Cally vs GAIL).

Anyway, in the case of Webkit, I would try to keep this Gail or Gtk somewhere. If finally the (KDE,Qt) world starts to use at-spi and atk things, there are a possiblity that Webkit would require to create a different Atk wrapper for the Qt thing (anyway, just guessing, I don't know anything about the Qt backend in Webkit).

So perhaps something like attribute="toolkit", value="Gail:Webkit" or value="Qt:Webkit" is another (and random, quick-thought) proposal.

If we finally go for this way... what will happen with the atk_util_get_toolkit_name? Would be used only to know which implementation (or toolkit or whatever) is providing the root object?

(In reply to comment #3)

> If we finally go for this way... 

It works splendidly for WebKitGtk and is coming in quite handy for both Yelp 3 and Epiphany. I hope everyone else sees fit to follow. :-)

> what will happen with the atk_util_get_toolkit_name? 

To be honest, that method at the moment is at best a crapshoot due to its inherent assumption that there is only a single toolkit being used in any given app. More and more that is an erroneous assumption. If we could get every toolkit to expose to us where its widgets came from, we'd have reliable information that we could act on, thus:

> Would be used only to know which implementation (or
> toolkit or whatever) is providing the root object?

At most. More likely it would no longer be used at all. ;-) Because if everyone were to do as is proposed here, the root accessible non-application object would expose that information just like any other AtkObject. And what the application object itself claims to use as its toolkit would become irrelevant.

Follow-up thought: We will also need a way to get the toolkit version in at least some cases. We do get that now via atk_get_toolkit_version. It of course shares the same issues as getting the toolkit name. Guess I have more RFEs to file....

ATK Hackfest Conclusions:

1. There should be a cleaner/less-hackish means to provide this information. (To be discussed later this week towards ATK2.)

2. Because this is needed currently, providing this information as an object attribute is acceptable to the group.

3. There are no objections to also providing the toolkit version as an object attribute for ATK1.

4. The object attributes should be documented as 'best practice' for now, until the ATK2 solution is defined and implemented.

[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 .
PLEASE NOTE:
If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add atk-maint@gnome.bugs to your watchlist at the bottom of https://bugzilla.gnome.org/userprefs.cgi?tab=email to keep watching atk bug reports in GNOME Bugzilla.
Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of atk, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a ticket at
  https://gitlab.gnome.org/GNOME/atk/-/issues/

Thank you for your understanding and your help.