Re: [g-a-devel] GNOME Launches Campaign for Accessibility
- From: Jason White <jason jasonjgw net>
- To: gnome-accessibility-devel gnome org, "gnome-accessibility-list gnome org" <gnome-accessibility-list gnome org>
- Subject: Re: [g-a-devel] GNOME Launches Campaign for Accessibility
- Date: Sun, 8 Jan 2012 11:19:47 +1100
Christian Hofstader <cdh gnu org> wrote:
> cdh: The Gnome a11y issues for people with vision impairment in the 2.xx
> releases are many, especially when compared to what users enjoy with JAWS or
> VoiceOver. These issues, though, are not all based in Gnome itself, rather,
> across the ecosystem of OS, UI, app, etc. The Gnome Accessibility API has
> most of the power necessary but too few programs fully implement it.
Correct.
>
> cdh: Sure, there will always be room for improvement but, again, compared to
> a Windows user with JAWS, WE, SA, NVDA, etc. a Gnome user has far fewer
> options and, in some really important application categories, they have
> nothing even remotely fully featured (compare using MS Excel with JAWS to
> Orca with the LibreOffice spreadsheet as a quick example of what one can and
> cannot do).
I've been a Linux user since the late 90s and an Orca user for a number of
years.
I wouldn't recommend Linux and gnome to a blind person who insisted on working
primarily in a GUI environment, due to the bugs and limitations of the
accessibility support. The problem largely lies not in the Orca project
itself, but in bugs and inconsistencies in the implementation of ATK and
AT-SPI by desktop environments such as Gnome and by applications.
I use Linux full-time and exclusively, but I only run X11 and Gnome when I
really need the capabilities of an X application (e.g., Mozilla firefox for
accessing certain Web sites). This actually suits me, as I don't like typical
graphical user interfaces even if the accessibility works - I find them too
constraining and inefficient compared with textual tools from the UNIX
tradition that offer much richer and more flexible command sets as well as
greater configurability.
If I were in a job that truly required heavy use of an office suite, though,
Linux/Gnome/Libreoffice wouldn't be a compelling choice, as the comments
quoted above imply.
If accessibility-related regulations are tightening, this might create
incentives for distributors and other commercial supporters of free operating
systems to increase their funding commitments in this area.
I think the Gnome accessibility community has a good grasp of the technical
issues that have to be addressed, including the lack of appropriate
documentation for desktop and application developers as to how to implement
accessibility interfaces. I would encourage the completion of any proposed
redesign of ATK to solve the problems which have been identified.
It should also be recognized that the ATK/AT-SPI infrastructure is now used by
other desktop environments (XFCE, and KDE with the QT to AT-SPI bridge), and by
various application developers - Mozilla Gecko, LibreOffice, Eclipse, etc.,
which are independent of Gnome, and that these projects need to be part of
whatever solutions are decided upon.
The coordination problems and resource shorages discussed in this thread are
very real. I've seen the following pattern repeatedly on the Orca list.
1. A user identifies a bug.
2. The bug is traced to shortcomings in the ATK support provided by a UI
library, desktop environment or application.
3. The bug is reported to the relevant project.
4. The project in question lacks the resources to deal with the bug in a
timely fashion, or for some other reason it simply doesn't get addressed in
the next release, or the one after that, or... Thus the original reporter and
everyone else affected by the bug waits, and waits...
A further difficulty identified in this thread is how better to involve
programmers with disabilities who want to fix bugs. Some suggestions would be
to provide better mentoring and assistance with review processes, and to
simplify and document the accessibility infrastructure as far as possible to
make it easier to implement, and easier to debug. By "simplify", I do not mean
"reduce the power of" - we actually do need all of those roles, states,
properties and events for good accessibility.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]