Re: GNOME Accessibility on by default, and Firefox
Hello, Jason White wrote: On Thu, Oct 23, 2008 at 09:54:03PM -0400, David Bolter wrote: Are there any objections to all this? For what it's worth, there's strong endorsement from me. All that the user should have to configure is whether to start her or his chosen assistive technology by default. Activating the accessibility infrastructure should be entirely a matter between the Gnome environment and the AT. We should not forget GDM. Supposing that the accessibility infrastructure has been modified to automatically run only when it is needed; will it behave the same way at the GDM login screen? Cheers Francesco ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
I agree too. When using an assistive technology to have a11y support enabled, but if you disable the AT disable it in order to improve performance for non AT users. I don't know if this is possible to enable/disable on the air without restarting the session. Regards, Javier. El jue, 23-10-2008 a las 00:53 -0700, T.V Raman escribió: I think this is a good idea. Performance matters to everyone, and the last thing you want as someone who depends on accessibility is for the rest of the world to perceive accessibility as something that slows things down for everyone else. David Bolter writes: Hi all, Firefox (and other apps) provides accessibility support conditionally. This means that on GNOME it always runs a little slower for everyone, and eats up extra resources. I wonder if we could have GNOME accessibility turned on, but a separate setting that Firefox can check on GNOME to tell it if the at-spi is actually being used by a client? This matters because people outside our circle make choices about browsers based on performance... and I think we want the most accessible one to win ;) cheers, David ___ dev-accessibility mailing list [EMAIL PROTECTED] https://lists.mozilla.org/listinfo/dev-accessibility ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Ang. Re: GNOME Accessibility on by default, and Firefox
I strongly support this too. It would smoothly remove one of the awkward issues presented to the user when starting an application like GOK - and which we discussed eralier this week. Mats Lundälv Jason White [EMAIL PROTECTED] Sänt av: [EMAIL PROTECTED] 2008-10-24 09:04 Till gnome-accessibility-list@gnome.org Kopia Ärende Re: GNOME Accessibility on by default, and Firefox On Thu, Oct 23, 2008 at 09:54:03PM -0400, David Bolter wrote: Are there any objections to all this? For what it's worth, there's strong endorsement from me. All that the user should have to configure is whether to start her or his chosen assistive technology by default. Activating the accessibility infrastructure should be entirely a matter between the Gnome environment and the AT. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
Hi All: There are a lot of things to think about here. From the internals point of view, we can think about the following: 1) The accessibility gconf setting: this says whether or not accessibility has been requested for the session. Right now, this tends to be used by GTK+ just to say whether or not to load the accessibility modules and start the AT-SPI registry. We've been trying for a long time to not require this setting and just always have the support turned on. But, there are performance and stability issues that prevent us from doing this, some of which might be addressed by making things more dynamic. BTW, I'm not sure about the details of what the Gecko implementation does, but it would surprise me if it *always* loaded the accessibility modules regardless of the gconf setting. 2) ATK and the ATK bridge: the ATK is a utility toolkit for use by applications and graphical toolkits to create an accessible representation of widgets: ATK peers are created for application/toolkit widgets and ATK events are issued for application/toolkit events. The bridge provides the communication with the outside world. That is, the bridge is the thing that currently speaks CORBA and which we are moving to D-Bus. Note that ATK and the ATK bridge are not required for an application to participate in the AT-SPI infrastructure; they merely make it easier to do so. So, GTK+, OOo, and Gecko all use the ATK and ATK bridge. Java, on the other hand, currently has its own bridge and speaks CORBA directly (I've argued that Java should use ATK via JNI to help normalize things somewhat and make it less dependent upon the AT-SPI transport). 3) The AT-SPI registry. This provides the rendezvous mechanism between applications and assistive technologies. When an application starts, it lets the registry know it exists so that assistive technologies can discover it. An application also issues events to the registry, which then delivers them to assistive technologies. When an assistive technology starts, it lets the registry know the event types it is interested in. Like the ATK bridge, the communication with the registry is dependent upon the IPC mechanism being used (i.e., CORBA or D-Bus). 4) GAIL: this provides the accessibility implementation for GTK+, creating ATK peers for GTK+ widgets and causing ATK events to be issued. It is designed to loaded as a GTK+ module at GTK+ initialization time and is currently not designed to be unloaded/reloaded over the course of an application's lifetime. Modifying it to be more dynamic might be rather difficult, and this is independent of the IPC mechanism in use. That is, I don't believe its behavior matters whether we use CORBA or D-Bus. From the assistive technology point of view, we can think of the following: 1) Assistive technologies that mostly examine object hierarchies. GOK tends to be this type of assistive technology. Accerciser fits into this category as well. These kinds of ATs might work with the just wakes up model, especially if one queries from the top of the object hierarchy down. However, *something* needs to already be awake so that an assistive technology can discover the top level application object in the first place. 2) Assistive technologies that mostly listen for events. Orca tends to fit into this category. I believe GOK also needs to listen for events, however, so it knows where to enter text and which UI needs to be grabbed. These kinds of assistive technologies might be more difficult to support the just wakes up model since they tend to depend upon receiving events from the application in order to learn that an application exists. Given these, I'm not sure it's really feasible to completely shut off accessibility in an application and dynamically turn it on when an assistive technology appears. That is, I think something probably needs to live in the application to at least support a rendezvous with an assistive technology. I also believe the main performance issues we face are the ATK peering of objects and event notification: we don't want unnecessary ATK peers to be created and we don't want unnecessary events to be issued. As such, I think we at least need the ability for assistive technologies to discover applications that are already running and to be notified when new applications start. From there, we could investigate generating ATK peers and issuing ATK events on an on demand basis. So...to make a long story short, I'd guess most of the work needed is independent of CORBA/D-Bus and would live in the AT-SPI implementation for the toolkit (e.g., GAIL). Li Yuan would be a good person to help us understand the scope of this problem. Will On Oct 23, 2008, at 9:54 PM, David Bolter wrote: Hi Aaron, Replying to a message from Aaron which didn't have the lists cc'ed. As Steve has brought up separately, this might indeed fit into the D-BUS
Re: Problem with Java Access Bridge
On Thu, 2008-10-23 at 22:02 +0800, Jeff Cai wrote: I guess you didn't configure orbit correctly. Please refer to http://live.gnome.org/Java%20Access%20Bridge to check your configuration. I did that. I found out I need to log out and in after creating /etc/orbitrc. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Problem with Java Access Bridge
Robert Voigt 写道: On Thu, 2008-10-23 at 22:02 +0800, Jeff Cai wrote: I guess you didn't configure orbit correctly. Please refer to http://live.gnome.org/Java%20Access%20Bridge to check your configuration. I did that. I found out I need to log out and in after creating /etc/orbitrc. Yes. That is because your at-spi-registerd needs to be restarted if the orbit configure has been changed. Jeff ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
BTW, I'm not sure about the details of what the Gecko implementation does, but it would surprise me if it *always* loaded the accessibility modules regardless of the gconf setting. Afaik we do just use the gconf setting, which is the problem. Then we start creating accessible objects, firing extra events, doing extra processing for DOM mutations, lalala. What other check should we use before turning it on? To be clear, if the gconf setting is not set, then no accessibility support will be enabled in Firefox. Is that right? If so, I'm confused. By enabling accessibility, the user is saying they want accessibility enabled. But, it seems like the argument being made here is that even if the user enables accessibility, they really don't want it. I think I might have missed the actual use case (I've been out of the country for the past week). Can you describe why someone would call to order pizza and then complain when it is delivered? Seems to me they should not have ordered it in the first place. ;-) However, *something* needs to already be awake so that an assistive technology can discover the top level application object in the first place. ... Any time any app asks for even the root accessible object for a given window, that window receives a signal. This may be the case on Windows, but I don't believe it is the case for GNOME. Will ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
Here is my understanding of this thread that I have been quietly watchig from the sidelines. WHat is being asked for is something closer to the windows model. In other words if accessibility is needed by an AT app like orca then it is started and runs. However if it is not needed it is not being used. THis can be important on a computer used by many people where one wants accessibility and one does not. In windows you simply shut down the screen reader and the lag it introduces goes away which is not the case in Gnome as far as I can tell. Ideally of course there would be no difference between having an AT program running and not but given that there is extra proccessing involved that isn't likely to happen. DOn't know if that is a correct reading but it is my understanding. Tom On Fri, Oct 24, 2008 at 04:23:51PM -0400, Willie Walker wrote: BTW, I'm not sure about the details of what the Gecko implementation does, but it would surprise me if it *always* loaded the accessibility modules regardless of the gconf setting. Afaik we do just use the gconf setting, which is the problem. Then we start creating accessible objects, firing extra events, doing extra processing for DOM mutations, lalala. What other check should we use before turning it on? To be clear, if the gconf setting is not set, then no accessibility support will be enabled in Firefox. Is that right? If so, I'm confused. By enabling accessibility, the user is saying they want accessibility enabled. But, it seems like the argument being made here is that even if the user enables accessibility, they really don't want it. I think I might have missed the actual use case (I've been out of the country for the past week). Can you describe why someone would call to order pizza and then complain when it is delivered? Seems to me they should not have ordered it in the first place. ;-) However, *something* needs to already be awake so that an assistive technology can discover the top level application object in the first place. ... Any time any app asks for even the root accessible object for a given window, that window receives a signal. This may be the case on Windows, but I don't believe it is the case for GNOME. Will ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
On Fri, Oct 24, 2008 at 05:22:35PM -0400, Willie Walker wrote: Note that I'm not necessarily encouraging or supporting the current you-get-it-or-you-don't behavior of GNOME. I'd much prefer NOT to have a gconf setting to enable accessibility, and I would prefer it to be a bit more dynamic. With the current architecture, I think we can get *close* to this with some extra work. To be clear, what I'm supporting is the proposal not to require a gconf setting to enable accessibility, without this resulting in performance-degrading events occurring when no assistive technology is active. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
