Hi
I was asking the same question a couple of years ago. My understanding
after looking a bit into the issue is that IBM consulted at the time key
people in accessibility in Linux (there still some minutes of these
meetings) to make both interfaces as close as possible which as
indicated it is somewhat the case.
Reading between the lines, iAccessible2 was not accepted for Linux
because of both companies and Linux vs Windows politics. the interfaces
are close but not the same. At the time perhaps if somebody on the
Linux side took a more favourable approach the communication layer in
iAccessible2 implementations would have been properly separated. As it
happened my understanding from Bil Cox who looked at the issue in more
details in the Windows world the implementation and communication layers
can be mixed with vendors who want to support both Windows and Linux so
in practice they need to a good extend maintain two separate stacks and
with the ratio of Windows to Linux users of something like 90 to 1 Linux
support not suprisingly is always behind.
So now it is probably too late to separate the layers for the large
application as it would involve too much work.
An opportunity lost.
Like Alex, the browsing experience is the main reason I use mainly Windows.
And I never understood why the off screen model is not adopted in Orca
(probably the only screen reader taking this approach) yes there is
sometimes the issue of synchronization with sighted users but it is in
my opinion a price worth paying for speed and then there is of course
the issue of inter processes as opposed to binary interface
communication which is a lot faster in Windows. In addition, I was told
that some screen readers take a pointer to the DOM tree which they are
not suppose to do probably not wise for security but it is very fast.
Regards
Isaac
Previous message...
On 06/06/2011 23:36, [email protected] wrote:
I guess IBM needed a neutral place to dump the interface definitions.
In theory it would be possible to implement iaccessible2 on linux, but the
inter process communication of it would have to be replaced and all that is
hosted as interface files on the linux foundation website can only be used with
windows tools.
So just the abstract interfaces could be taken, but as I said before, it is
quite close to what at-spi is.
For a better browsing experience I guess that browsers/firefox and the orca
people need to have better feedback what is needed. Firefox has a lot of custom
stuff that on windows is using iaccessible2, so maybe there is something needed.
I have not looked at qt webkit yet as that seems to be another big project.
Cheers
Frederik
On Jun 6, 2011, at 11:55 PM, ext Alex Midence wrote:
Meant to send this to the entire list but didn't realize it did not go through.
Thans.
Alex M
---------- Forwarded message ----------
From: Alex Midence<[email protected]>
Date: Mon, 6 Jun 2011 16:54:43 -0500
Subject: Re: Lubuntu and Accessibility
To: [email protected]
Hi, Frederik,
Here is one of the resources that led me to believe that iaccessible2
was a feasible accessibility api for Linux applications and
applications used to make others accessible in Linux to rely upon:
http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2/overview
If it can not be used in Linux, why is it supported by the Linux Foundation?
Alex M
On 6/6/11, Alex Midence<[email protected]> wrote:
Thanks for clearing that up. I was always quite mystified as to why
it wasn't used. I found all sorts of postings as to why it was a bad
idea but never anything quite so informative as to just why At-Spi was
so preferable. I also found many postings when it first came out
touting it as a good solution for cross-platform accessibility which
is the reason I was under the impression that it could conceivably be
implemented in Linux and hadn't been done so due to people preference
and not because it was not feasible.
Thanks again.
Alex M
On 6/6/11, [email protected]<[email protected]> wrote:
Hi,
On Jun 6, 2011, at 3:42 AM, ext Alex Midence wrote:
I seem to recall that Klaus Knopix is reputed to have had some success
making LXDE accessible in his Knopix Adrienne distribution. Perhaps
that is something that could be used as reference? As for
python-related slowness in Orca, I would tend to agree. C is just
faster than Python. Interpreted languages are going to require far
more memory and resources than compiled ones in many cases.
Actually, a saner thing would be an implementation of orca written in
both C or c++ and Python. The low-level code in c and the more
scriptable areas in Python. This is what NVDA's devs did and it's a
slighning fast screen reader on a bloated system like Windows. While
we're wishing, I'll go ahead and wish for iaccessible2 support instead
of complete and exclusive reliance on at-spi/at-spi2 so that more
widget toolkits might become accessible since some of them do support
iaccessible2 but not at-spi.
the APIs of IAccessible2 and at-spi2 are very similar.
Their big difference is the implementation. IAccessible2 (based on MSAA)
uses Windows COM for inter process communication.
at-spi2 uses dbus.
That means having IAccessible2 on Linux doesn't make much sense. And
implementing it using DBus you end up with exactly at-spi2.
Please don't propose solutions that simply don't match the problem.
Instead of speculating about performance we should use profiling tools to
see where the performance lags.
I suspect DBus is a large part of it. And the way we use DBus is used is
another big issue. Python may or may not play a role.
Greetings,
Frederik
I'm on a orle here so, I'll keep
wishing. I want a faster, lag-free web browsing experience with
something akin to an off screen model, navigation by element list.
and an expanded list of elements by which one can navigate like div
and span. The inferior browsing experience in Linux is the only
thing that keeps me going back to windows.
Just my two cents,
Alex
Date: Sat, 4 Jun 2011 09:49:37 +0200
From: Halim Sahin<[email protected]>
To: [email protected]
Subject: Re: Lubuntu and Accessibility
Message-ID:<[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Di, Mai 24, 2011 at 01:14:32 +1000, Luke Yelavich wrote:
The first thing is making sure LXDE is actually accessible, i.e make
sure it has keyboard shortcuts, and supports the launching of the
accessibility framework at startup etc. As to using the LXDE GUI with
Orca etc, I think the biggest problem here is the use of python. The
Hmm, do you think we should replace orca in all desktop environments by
a c-implementation?
Slow performance is not related to lxde only. Orca isn't faster in
gnome
as well so I can't understand what you want to say here.
Regarding lxde a11y:
I played a bit with the components in the past.
The most dificult problem was to run at-spi-registryd before the first
gtk app starts.
The application menu works (ctrl+esc).
pcmanfm in desktopmode doesn't read anything.
pcmanfm started in filemanager mode works when changing to details in
menu->view.
The buttons/panels are not accessible on the desktop because of missing
keyboard shortcuts afaik.
HTH.
Halim
------------------------------
--
Ubuntu-accessibility mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
End of Ubuntu-accessibility Digest, Vol 67, Issue 2
***************************************************
--
Ubuntu-accessibility mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
--
Ubuntu-accessibility mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
--
Ubuntu-accessibility mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
