Re: About proposing "accessibility on by default" as feature

On 04/20/2012 06:41 PM, Peter Korn wrote:
> API,
>
> Accessibility by default has long been a desire.  What about an
> interim, "prove it" step?  Have it turned on by default for the
> various 3.5 builds, with the understanding that it will revert to
> being off if certain metrics aren't met.  BUT... with the plan that
> they will be met?

Hi Peter,

Sorry, but I don't understand this. What it is the difference between
that "interim step" that you propose and the second option that I
proposed and I called "compromised option". Quoting myself:

"Finally, comment that probably there is a compromise option, that is:
<skip>
* For this cycle just propose to change the default value of
accessibility-toolkit. In that case we would still have more runtime
testing, and it would be easy to go back if things are failing."

BR

>
>
> Peter
>
> On 4/20/2012 9:15 AM, Piñeiro wrote:
>> Hi,
>>
>> some context: on last ATK/AT-SPI2 accessibility hackfest [1] one of the
>> ideas that came again to the table was proposing to set accessibility
>> support on by default. That work would include having the accessibility
>> nits running all the time, without a accessibility-toolkit setting
>> switch, and also stop to having the accessibility code loaded as
>> plugins. At this moment the only remaining plugin is the atk-bridge, so
>> the idea is having the same functionality as a library call. Something
>> like a atk_bridge_init (..) call (equivalent to gtk_init).
>>
>> On our last accessibility meeting we were talking about proposing this
>> as a new 3.6 feature, as seems a good way to start the discussion with
>> the community. From that meeting:
>> Apr 19 16:10:13 <API>    #action Piñeiro after some researching, will
>> bring the having accessibility by default 3.6 to the accessibility list
>> Apr 19 16:10:32 <API>    #action Piñeiro after some debate we could
>> propose it as feature
>>
>> So after that research I'm here to talk about this (output of that
>> research at the appendix of this mail).
>>
>> So lets see the current situation:
>>  * Accessibility performance and stability has been improving during the
>> last two releases.
>>  * GNOME-Shell (for user POV, GNOME) accessibility has improved with the
>> last release.
>>  * But there are still several core applications (ie: evolution) without
>> a proper accessibility support (also crash-prone)
>>  * Now it is possible to enable accessibility on runtime, without
>> requiring the uncomfortable logout
>>  * Most of the bus traffic is not sent unless one AT is listening
>>
>> As we mentioned on the meeting, having the accessibility running would
>> provide more testing on the accessibility framework, both on runtime and
>> on compiling time (as at-spi2-[core/atk] will became a compiling
>> dependency).
>>
>> The problems I see are:
>>   a) About having accessibility enabled all the time: right now
>> activating the accessibility on runtime works, so some people would be
>> against adding an inherent risk
>>   b) About stop to using plugins: some people will not like adding a new
>> dependency to their projects (this could be irrelevant if the final
>> solution is add that call on ATK, as randomly suggested on the hackfest)
>>   c) Although we agree that we want to stop to load the bridge as a
>> plugin, we are still not sure about how and where implement it.
>>   d) We didn't debated how all this changes would affect GTK2 apps.
>> Because the fact is that there are apps still not ported.
>>   e) My inner pessimist thinks that getting to a conclusion, implement
>> it, integrate it and test it are too much, and it would be difficult to
>> have all ready for 3.6
>>
>> Finally, comment that probably there is a compromise option, that is:
>>  * Keep working on c), as seems the way to go. Probably with unstable
>> branches of atk, at-spi, gtk and clutter
>>  * For this cycle just propose to change the default value of
>> accessibility-toolkit. In that case we would still have more runtime
>> testing, and it would be easy to go back if things are failing. If
>> things are not failing, it would be a good way to minimize a) if we
>> propose to remove the gsetting switch.
>>
>> With that compromised option, for this cycle we would just propose to
>> change the default value of accessibility-toolkit, while working on the
>> other stuff.
>>
>> So, ideas, thoughts?
>>
>> ***
>>
>> Appendix (somewhat offtopic or this mail main topic)
>> That research that I wanted to do was check why the following was working:
>>  1. accessibility-toolkit is disabled
>>  2. gnome-shell is running
>>  3. Via Universal-Settings you activate "Screen reader", this sets
>> accessibility-toolkit as enabled
>>  4. Orca interacts properly with gnome-shell
>>
>> The "classical GNOME accessibility" wisdom tell us that 4 is not
>> possible, and you need a logout. Also take into account that gnome-shell
>> has a custom code that loads that module if that gsetting is enabled.
>> With GTK3 this was not required anymore thanks to the gsettings-daemon
>> magic, and the at-spi2-atk.desktop file, that informs that when
>> accessibility-toolkit became enabled, it should load the bridge.
>>
>> So, how gnome-shell does that? Well ... thanks to gsettings-daemon, as
>> gnome-shell also calls gtk_init, so it is also a GTK app. In fact, if
>> you remove that custom loading-code, in some situations it is still
>> working (note "some situations", so we can't remove that code yet). As
>> you can guess, those "some situations" are exactly the situations we
>> were expecting this all to be failing. In the same way, that
>> "NO-AT-BRIDGE" "NO-GAIL" code is still required to ensure that AtkUtil
>> implementation of GTK is not loaded. Yes, all this seems tricky and
>> fragile, and for sure requires some cleaning, but for now it is working.
>>
>> BR
>>
>> [1]
>> http://blogs.igalia.com/apinheiro/2012/01/24/atkat-spi2-hackfest-2012-days-2345/
>>
>
> -- 
> Oracle <http://www.oracle.com>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 <tel:+1%20650%205069522>
> 500 Oracle Parkway | Redwood City, CA 94065
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment


-- 
Alejandro Piñeiro Iglesias

_______________________________________________
gnome-accessibility-devel mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel