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

API,

Oops!  Sorry, no difference.  I just missed the compromise option in 
your text.


Peter


On 4/20/2012 9:53 AM, Piñeiro wrote:
> 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

-- 
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

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