access_info (and the related event) seems suspicious considering we aren't stabilizing access at all, so this should be beta.

@Jaehyun_Cho
The access_root was already removed. The remaining methods are still static methods inside Efl.Access.Object. I wasn't planning to separate them, since the static methods in regular class are perfectly ok with all languages.
However If You insist I can move it to some Efl.Access.Event_Manager class as we previously discussed.

@Jaehyun_Cho
Aren't examples that You provided only the implementation detail that C# developer should not care about? From C# dev perspective mixin only adds method to class, nothing else.

@segfaultxavi
I think it all depends on how we define accessibility event. Those events are in fact defined in AT-SPI2 protocol: https://gitlab.gnome.org/GNOME/at-spi2-core/blob/master/xml/Event.xml
Generally the events from this interface translates 1-1 to dbus signals which are received by external process (screen-reader). It also serves as a flag for screen reader that this object may emit such events in the future.
The interface can be theoretically removed, however the idea was that atspi bridge should talk to objects only via efl_access_* interfaces. Instead it will require some knowledge of elementary classes. TBH i do not know if any other class will ever require to implement this interface. Only something like GIMP multi-window UI comes to my mind.
@woohyun
As a part of T7653 this interface can be removed completely and moved into efl_access_object. Additionally events can be refactored into regular methods, so instead of "window,created" we will have something like window_created_emit method or just emit with some parameter. Is this acceptable?

In my opinion, many mixin cases in EFL can be modified as above (converted to interface or moves into class' method/properties) and its design would be better.

Yesterday I was talking with @Jaehyun_Cho about the MIXINS and C#. I was able to understand C# binding generator a bit better. As it is already known, the C# bindings will
provide binding functionality (the possibility to call C code from C#), as well as extensions functionality (allow to call c# from c code).

To answer Your questions:

1. Yes, there will be no public methods, only single "access_object_create" protected method. It can be extracted into mixin, however I'm afraid it may again cause problems with C# bindings generator.
2. Yes, the plan is to use efl_provider_find method as generic way to get access object from other objects. Alternatively, the dedicated method "access_obect_get" can be created, however I assumed that "provider_find" method fit this concept so may be reused.

As we discussed, the delay is reasonably short (< 20 ms) , so I think this patch is good to go in.

@zmike I think this patch is still valid. @rcybulski is currently busy with other things, however he will be back to this in some time.

For me it is ok to merge its.

Please check first attempt to rename: D5161, D5162, D5163, D5164
I will update this task if new diffs occurs

I agree, that there is inconsistency. however I would like to modify it in other direction:

Please explain to me one thing. Why using callbacks to get accessible information is more convenient then using setters directly? Why setters are not enough in this case?

added D3452. Moreover elm_list do not support scrollto types, so that change will be skipped for now.

It will be. Just in next patches :) Ill try to upload them today.