GNOME Accessibility Team
3.0 Planning and Work
Please note: This page discusses the GNOME Accessibility Team's efforts for GNOME 3.0, providing a description of the various touch points, with the key people to contact for each one.
For general information on GNOME 3.0, please see the GNOME 3 website.
For the Accessibility Team's work towards GNOME 3.2, please see the 3.2 planning pages.
Contents
High Risk
1. Accessibility Stack
1.1. CSPI (drop for GNOME3)
Risk level: high |
Work needed/remaining: write a libatspi to CSPI compatibility layer if desired
Key Contacts: LiYuan
- Purpose: provides the C bindings for assistive technologies
- Notes: AT-SPI2 now includes AT-side C bindings with an API friendly to gobject-introspection but not compatible with the original CSPI library. It probably makes sense in the long term to port CSPI applications to libatspi. However, it should be fairly straight-forward to write a compatibility layer on top of libatspi, so it may be desirable to do so.
There are a number of cspi consumers (also listed on this page):
- LDTP - LDTPv2 migrates LDTP away from CSPI to pyatspi. With this, it can operate in both the CORBA and D-Bus environments.
- GOK - GOK is the heaviest user of CSPI. There are no plans or resources to port GOK to D-Bus.
MouseTweaks - Gerd has a branch http://git.gnome.org/browse/mousetweaks/log/?h=at-spi2
Dasher - work to call D-Bus directly has been started by PatrickWelche
- BrlTTY - while not a GNOME project, BrlTTY is used by Orca. BrlTTY also provides direct interaction with AT-SPI, and has been ported to use both CSPI/CORBA and D-Bus for AT-SPI.
Status: 24-Mar-2010 - at the Accessibility/Hackfest2010 meeting on GNOME3, the GNOME accessibility team decided it is OK to drop CSPI for GNOME3. It's not desirable, but there are no resources to do the work. GOK is the component that will be adversely effected, but we will look to Caribou and other keyboard solutions (e.g., OnBoard) to supplant GOK. If there are any GOK users, we will recommend they stay with GNOME 2.30 or work with their distribution to include the CORBA a11y stack alongside the GNOME 3 packages.
1.2. libgail-gnome (drop for GNOME3)
Risk level: high |
Work needed/remaining: find all uses of libgail-gnome and replace them with the ATK "plug and socket" API. These include Evolution and gnome-panel.
Key Contacts: LiYuan
- Purpose: contains GAIL additions which implement ATK interfaces for libbonoboui and libgnomeui widgets.
Notes: ATK also has the new plug and socket API to denote out of process accessibles and is implemented for AT-SPI/D-Bus only. This may be a solution to help replace libgail-gnome. See https://bugzilla.gnome.org/show_bug.cgi?id=601552. LiYuan - will help us with the details of where libgail-gnome is used and help shepherd the replacement of libgail-gnome usage with the ATK plug and socket API's.
- Status: 20-Jan-2011 - Since panel-applets will not be ported to gnome-shell, Evolution is the only risk now.
2. Assistive Technologies
2.1. New Universal Access Preferences UI
Risk level: high |
Work needed/remaining: implement, test, and make sure assistive technologies behave properly to changes in gconf settings.
- Purpose: provide a "one stop shopping" point for customizing interaction with the desktop. This replaces and improves a number of existing spots spread throughout GNOME.
Module: see NewPreferencesGUI, will likely live in http://git.gnome.org/browse/gnome-control-center/tree/capplets/accessibility/at-properties
- Notes: the main workings of the new Universal Access Preferences UI will be to modify gconf settings. These settings may be listened for by *.desktop files with autostart settings, but they may also need to be listened for by assistive technologies (e.g., a running Orca process needs to acknowledge changes to speech settings). So, the work extends beyond just the GUI and needs to be coordinated with other modules in GNOME.
Status: 24-Mar-2010 - JonMcCann is taking a stab at implementing the new UI.
- Status: 04-Oct-2010 - We don't know who is working on it, send a mail to key contacts?
Status: 28-Mar-2011 - JosephS submitted patch https://bugzilla.gnome.org/show_bug.cgi?id=643086 for zoom (magnifier) options. A screen shot of the proposal is visible on the GNOME Shell Magnifier page.
2.2. AccessX-Status Applet
Risk level: high |
Work needed/remaining: provide a new UI?
Key Contacts: EitanIsaacson
Purpose: provide a visual indication of AccessX feature status (e.g., StickyKeys state, SlowKeys timer, BounceKeys timer, etc.)
Module: http://git.gnome.org/browse/gnome-applets/tree/accessx-status
- Notes: as panel technologies change, so to the applets. This applet is very useful for the people that use AccessX features because it lets them know what state their keyboard is in.
- Status:
27-Mar-2011: see this mail from Owen taylor for current status
3. Desktop Environment
3.1. GNOME Shell: General
Risk level: high |
Work needed/remaining: see below
- People: GNOME Shell Team
- Purpose: GNOME Shell is the new black. It is hip. It is rad. It is exciting. It is the new face of GNOME.
- Notes: GNOME Shell is at high risk for a number of reasons described below.
- Gnome-shell team has included Accessibility in his roadmap
- There are already several bugs related to that. You can use the following search to find any accessibility related gnome-shell bugs:
- Status:
- 27-Mar-2011: update of the status due GNOME 3.0 next release. In general: work in progress, and as stated, a "good enough" support planned for 3.2
3.2. Shell Panel
Risk level: high |
GNOME Shell provides its own new panel. The availability and accessibility of applets needs to be taken into account. Need to contact the GNOME Shell team about this.
- Status
27-Mar-2011: taking into account this mail from Owen Taylor, they are not working properly now
3.3. "New" GTK+ Widgets
Risk level: high |
Some "new" GTK+ widgets need testing
- Status - 20 Jan 2011 - Li Yuan is going to review the new widgets and make a plan to work on it.
- New widgets or new features in existing widgets that might need a11y support:
GtkSwitch - has a working a11y implementation builtin
GtkGrid - a GtkTable replacement, inherits generic container a11y implementation; should probably have an AtkTable implementation
GtkLinkButton - implements AtkHyperlinkImpl now
icons in entries - probably need to add AtkImage children for those
- marks in scales - minimally needs to expose the text
links in labels - need an AtkHyperText implementation for GtkLabel; should probably merge the a11y implementation into GTK+ first, since the API doesn't expose sufficient detail about links
the treeview refactoring with GtkCellArea requires some catch-up work on the a11y side
3.4. gnome-panel
Risk level: high |
Work needed/remaining: testing and resolving issues with applet accessibility
People: LiYuan, VincentUntz
- Purpose: provide the top and bottom panel and their contents.
- Notes: While gnome-panel itself tends to do well with accessibility, there are issues with items inside it, both with the CORBA and D-Bus versions of the AT-SPI. These include problems with things such as the volume control applet, notification items, etc. - some regressions seem to have taken place since GNOME 2.28. gnome-panel needs further testing and we need to identify and resolve these issues.
Status: 24-Mar-2010 - still unsure where things are breaking. LiYuan will dig into this.
- It is done? Ask Fernando Herrera and Carlos Garcia.
Medium Risk
1. Accessibility Stack
1.1. at-spi2-registryd (D-Bus)
Risk level: medium |
Work needed/remaining: debugging, testing and performance of the D-Bus version
Key Contacts: LiYuan, MikeGorse, Nagappan, MarkDoffman
- Purpose: provides the rendezvous point between GUI applications and assistive technologies. It is a means for GUIs to register themselves with the AT-SPI and for assistive technologies to discover running applications and register listeners for AT-SPI events.
Module: CORBA=http://git.gnome.org/browse/at-spi/tree/registryd, D-Bus=http://git.gnome.org/browse/at-spi2-core/tree/registryd
- Notes: this is a relatively stable module.
- Status: 24-Mar-2010 - Some work needs to be done on the activation of the registry upon login -- things seem to hang unexpectedly sometimes, more often on a slower machine (i.e., netbook) than faster machines. The registryd can be activated different ways -- D-bus activation and the *.desktop file -- timing issues in other areas may end up ticking both these methods and might be a potential source for the hang. (19-Jan-2011- need to test whether all of this is still happening.)
1.2. pyatspi2 (D-Bus)
Risk level: medium |
Work needed/remaining: debugging, testing and performance of the D-Bus version
Key Contacts: LiYuan, MikeGorse, Nagappan, MarkDoffman
- Purpose: provides the Python bindings for assistive technologies.
Module: CORBA=http://git.gnome.org/browse/at-spi/tree/pyatspi, D-Bus=http://git.gnome.org/browse/pyatspi2
Notes: consumers of the Python bindings should not know the difference between the CORBA and D-Bus versions. That is, they should be able to still "import pyatspi" and function without code modification. See AccessibilityCORBAToDBusMapping for more information on how this is managed.
need to start working on using it with the Orca regression test suite as a means to help test and harden the implementation. Testing with LDTPv2 test suites will also be very useful.
- Status: 19-Jan-2011 - Performance is significantly improved with the new gobject-introspection-based pyatspi2 using libatspi as a back end and direct dbus connections. Works best with pygobject newer than 2.27.0; until recently, there were memory leaks and a bug which made enums very slow. More testing is needed; Orca is generally usable with Firefox and pyatspi2, and performance seems similar to AT-SPI-CORBA, but there are some bugs. For instance, Orca reports that text is being unselected when it is being selected and may sometimes traceback when it tries to process an event from an application that has gone away. Exceptions are not currently equivalent to AT-SPI-CORBA exceptions (need to determine if there is a good way to associate particular exceptions with particular gerrors), which has the potential to cause regressions.
1.3. accessibility bus (D-Bus)
Risk level: medium |
Work needed/remaining: work on proper activation/timing
Key Contacts: LiYuan, MikeGorse, Nagappan, MarkDoffman
- Purpose: a separate accessibility bus so at-spi2 traffic doesn't go over the session bus and accessibility is enabled for administrative applications
- Notes: there is support in the other at-spi2 components to fall back to the session bus if this bus is not available. This might be a source of timing issues if it is assumed that the accessibility bus will be available as soon as the command to launch it is run. There should be some gate put in place to make sure the accessibility bus is available before launching other things (e.g., the registryd and anything using the atk-bridge) try to connect to it.
- Status: 19-Jan-2011 - need to investigate whether timing issues are still present; they likely are since nothing has been done specifically to address them.
1.4. atk-bridge (D-Bus)
Risk level: medium |
Work needed/remaining: debugging, testing and performance of the D-Bus version
Key Contacts: LiYuan, MikeGorse, Nagappan, MarkDoffman
- Purpose: dynamically-loaded GTK+ module that lives inside the GUI process and which talks to the ATK peers created by the toolkit's accessibility layer. It also communicates with consumers of the AT-SPI infrastructure, such as Orca and LDTP via some interprocess communication mechanism (i.e., CORBA or D-Bus, depending upon the bridge). Used by other toolkits as well (GTK+, Gecko, Uno, and the new Java ATK Wrapper)
Module: CORBA=http://git.gnome.org/browse/at-spi/tree/bridge, D-Bus=http://git.gnome.org/browse/at-spi2-atk/tree/atk-adaptor
Notes: the CORBA and D-Bus modules have identical names ("atk-bridge") because it is hardcoded in other external projects, such as Gecko and OpenOffice. Along with the rest of the infrastructure, the D-Bus form still needs testing. It has yet to pass the Orca regression test suite, for example, as of 24-Mar-2010. Note also that the Gecko toolkit seems to crash with the D-Bus bridge.
- Status: 19-Jan-2011 - This is generally working, although it could use some more testing. Requires dbus-glib 0.90 or greater for direct dbus connections to be enabled; will disable if an older dbus-glib is found.
1.5. Java ATK Wrapper (JAW)
Risk level: medium |
Work needed/remaining: testing and hardening
Key Contacts: KeWang
- Purpose: provide a JNI layer for Java AWT/Swing that talks to the ATK.
- Notes: JAW is new and replaces JABG. Because it uses ATK, JAW is independent of whatever bridge is used to talk with external processes, allowing it to be shielded from changes in interprocess communication mechanism. With JAW, however, comes some issues because it loads the atk-bridge. Care needs to be taken to prevent mixed-toolkit environments from loading the atk-bridge more than once.
- Status: 24-Mar-2010 - needs testing with Orca and other assistive technologies as well as a mix of Java-based applications.
1.6. login-helper (deprecate?)
Risk level: medium |
Work needed/remaining: verify this is no longer needed
People: LiYuan, JeffCai, BrianCameron
- Purpose: to help with presenting assistive technology windows on top of "restricted" screens, such as GDM and the screen saver.
Module: http://git.gnome.org/browse/at-spi/tree/login-helper
Notes: the use of this appears to be limited to the old GDM and the Solaris screen saver. If so, we may just be able to let it go away. LiYuan, JeffCai, and BrianCameron will help confirm this is the case.
- Status: 24-Mar-2010 - need to decide if this can go away or not.
- Status: 04-Oct-2010 - we *really* need to decide if this can go away or not
2. Assistive Technologies
2.1. Accerciser
Risk level: medium |
Work needed/remaining: test with D-Bus a11y stack
Key Contacts: BrianNitz
Purpose: Accerciser is an interactive Python accessibility explorer for the GNOME desktop. It uses AT-SPI to inspect and control widgets, allowing you to check if an application is providing correct information to assistive technologies and automated test frameworks.
- Status: 31-Mar-2010 - Several people reported Accerciser was broken in GNOME 3, need info including bug reports.
Status: 24-Mar-2010 - EitanIsaacson and API need to debug the hang together. => solved (no remember one)
- Status: 04-Oct-2010: Brian still thinks it is a high risk level module as it was not heavily tested with DBUS
- Status: 28-Oct-2010 Brian Nitz is the new maintainer
- Status: 28-Oct-2010: Brian lowered the risk to medium based on better understanding of the required changes and information from people who are running with DBUS.
- Status: 17-Jan-2011: Some problems reported with Accerciser and Pyatspi2. Brian needs to discuss with API.
2.2. Dasher
Risk level: medium |
Work needed/remaining: port to D-Bus
Key Contacts: PatrickWelche
- Purpose: an alternative input mechanism
Notes: Dasher's exposure to CSPI seems rather limited and can be removed as a compile time option (search for GNOME_A11Y in the code). Without this support, WillieWalker believes Dasher may still function standalone and can be used to type text by cutting/pasting between the Dasher GUI and another text area, which is how many people use Dasher today in GNOME. Dasher also optionally uses gnome-speech (search for GNOME_SPEECH in the code), but it's not apparent how many users actually use this feature. So, if users do not mind using Dasher standalone without needing AT-SPI or speech support, it should be able to function fine.
Status: 24-Mar-2010 - Dasher can be compiled without AT-SPI and gnome-speech support. This may be an acceptable solution moving forward. PatrickWelche has also begun looking at calling D-Bus methods directly to get to the a11y stack.
2.3. Caribou
Risk level: medium |
Work needed/remaining: see Caribou
Key Contact: EitanIsaacson ,
- Purpose: provide a typing assistant in the form of an on screen keyboard that can be accessed via mouse and/or switch-based access. A possible replacement for GOK.
Notes: Caribou is new technology and uses the pyatspi. It seems to be headed in the right direction. The main risk is making sure Caribou is funded and staffed appropriately.
- Status: 04-Oct-2010: ask all the people involved about his opinion on the project
2.4. gnome-mag (port to D-Bus)
Risk level: medium |
Work needed/remaining: D-Bus API finalization; implementation; testing and hardening
Key Contacts: FernandoHerrera, JosephS
- Purpose: provide a standalone magnifier (mouse tracking only) as well as a magnification service for use by assistive technologies (e.g., Orca)
Notes: CarlosDiogenes has created an initial stab at "D-Bus-izing" the gnome-mag API. Whatever API is developed, it should be common between gnome-mag and the GNOME Shell magnifier, and Orca needs to be modified to use it. We may consider opening a "GOPA-sized" grant for Carlos to do this work and implement the API for gnome-mag and GNOME Shell mag.
- Status: 24-Mar-2010 - the D-Bus API needs to be finalized and agreed upon between gnome-mag and GNOME Shell. Orca needs porting to the D-Bus API. gnome-mag might need modification to allow for conditional compilation of CORBA vs. D-Bus and also whether the CORBA/D-Bus functionality should be simultaneously available or mutually exclusive.
Status: 03-Jun-2010 - CarlosDiogenes said that there are some pieces mising, but right now he can't work on it. Mail here, and he asked for a volunteer for that
- It is important as the current GS-mag DBUS API definition is affected by this, as the idea is to have the same API in both.
Status: 14-Oct-2010 - as a result of discussions at the AEGIS Hackfest, JosephS published a proposed new Common Magnifier Framework.
2.5. GNOME Shell Toolkit
Risk level: medium |
GNOME Shell also is creating its own toolkit based on NBTK/MX. Any additional widgets created here need to support ATK and also need to support keyboard navigation. GNOME Shell may end up using some form of mx (in theory, St and MX will be merge, "eventually")
- Status
- 27-Mar-2011: GNOME Shell has now built-in accessibility support, with custom accessibility objects. So now, orca reacts with it. But it is still missing several labels and specific work. Lowering from high to medium, as the base is there.
2.6. GNOME Shell Magnification
Risk level: medium |
Work needed/remaining:
Three features that need to be implemented are brightness and contrast enhancements (including inverse video), multiple displays, and quick gestures to change magnification (keystrokes and mouse wheels). There is a patch for the first of these (https://bugzilla.gnome.org/show_bug.cgi?id=639851).
The other aspect of magnification that needs work is the Common Magnifier Framework. The specification needs to be finalized, and it needs to be implemented by the GNOME Shell magnifier. The development of GNOME Shell Mag has followed this framework with respect to GSettings. Only the D-Bus aspect needs work.
Key Contacts: JosephS
Module: http://git.gnome.org/browse/gnome-shell, but see Magnification within GNOME Shell, where the magnifier work is tracked.
Purpose: provide magnification within GnomeShell
Notes: See also bug 595507, which is where the initial work is described. Orca is being modified to work with the D-Bus API provided in the patches attached to the bug, but we need to align the D-Bus API with the gnome-mag work (and vice versa). We also need to resolve issues such as how/where to store persistent settings.
Status: 25-May-2010 - the patches associated with bug 595507 were accepted. The magnifier is now built into GnomeShell 2.31.2. See the announcement on the gnome-shell list.
Status: 14-Oct-2010 - as a result of discussions at the AEGIS Hackfest, JosephS published a proposed new Common Magnifier Framework.
- Status: 18-Jan-2011 -
patch submitted for inverse video, contrast, and brightness enhancements https://bugzilla.gnome.org/show_bug.cgi?id=639851; to be reviewed by GNOME Shell developers.
Common Magnifier Framework modified in conjunction with above patch.
- Status: 28-Mar-2011 -
patch for inverse video, contrast, and brightness enhancements https://bugzilla.gnome.org/show_bug.cgi?id=639851 received preliminary review. The code was updated, bugs fixed, and a new patch was submitted. The functionality, however, will not be part of the GNOME 3.0 release.
per the Common Magnifier Framework, the magnifier preferences were moved to the more central location, 'gsettings-desktop-schemas'. See https://bugzilla.gnome.org/show_bug.cgi?id=642034 and https://bugzilla.gnome.org/show_bug.cgi?id=642034.
related to above, there is a proposed UI for zoom options, tracked by bug 643086. A screen shot of the proposal is visible on the GNOME Shell Magnifier page.
2.7. Orca
Risk level: medium |
Key Contacts: JoanmarieDiggs, AlejandroLeiva
- Purpose: provides speech, braille, and magnifier access to GNOME
Module: http://git.gnome.org/browse/orca
- Work Remaining - Updated: 7-April-2011
- Orca does not present all applications in GNOME 3. Investigate why, and if this has anything to do with when/how the registry is started/stopped.
- Additional testing with AT-SPI2.
- Determine what is required from the design team with respect to Orca's GUI.
Migrating to the new magnification API that will be shared between gnome-mag and the GNOME Shell magnifier and/or cause Orca to co-exist nicely with the multiple magnification solutions which exist. Doing the latter is what Joanmarie would like to see occur since the majority of users who require magnification do not require the functionality of a screen reader (i.e. speech and braille); just focus and caret tracking. Such a change will require the magnification solutions to implement focus and caret tracking.
3. Desktop Environment
3.1. Clutter/Cally
Risk level: medium |
Clutter is a very low-level "super class" for making widgets. Alejandro Piñeiro Iglesias (API) is working on Cally.
Cally is basically the GAIL equivalent for Clutter and will help provide a building block for accessibility support in GNOME Shell. It is required to a proper configuration of Cally and atk-bridge on gnome-shell. It is also important the Cally ATK support itself. You can check Cally bugs here:
- Status
27-Mar-2011: last changes not still integrated on the master, you can see then on gitorious
The main issue right now it the incomplete AtkText implementation (lack of a gailutil equivalent)
3.2. GNOME Shell: Theming
Risk level: medium |
GNOME Shell provides some level of theming for adjusting colors, fonts, etc. It is unclear, however, how or if this theming support will be connected to the general GNOME theming/appearance properties. Need to contact the GNOME Shell team about this. Alejandro Piñeiro Iglesias (API) may help with this as well.
- Status
27-Mar-2011: Dan Winship (Gnome-shell developer) opened a bug related to this issue, not started yet
3.3. WebKitGtk (support ATK)
Risk level: medium |
Key Contacts: JoanmarieDiggs, XanLopez, MarioSanchez
- Purpose: provide HTML rendering
Module: http://webkit.org/
- Work Remaining - Updated: 1-April-2011
https://bugs.webkit.org/show_bug.cgi?id=25531 (3 bugs pending to get integrated)
https://bugs.webkit.org/show_bug.cgi?id=30796 (metabug for the rich internet applications)
https://bugs.webkit.org/show_bug.cgi?id=52148 (work in progress)
3.4. gdm
Risk level: medium |
Work needed/remaining: testing and general issue fixing, keyboard and mouse gestures
Key Contacts: JonMcCann, RayStrode, BrianCameron
- Purpose: the login screen
Module: http://git.gnome.org/browse/gdm
Notes: gdm is generally troublesome, but getting better. The work being done with the new Universal Access Preferences UI (see below) will help solve a lot of problems, but we need to make sure it works well with gdm and is easily accessed. While the work includes defining hot keys to enable/disable accessibility features, we're currently lacking the mouse gesture support that was in the old gdm. Missing mouse gestures may or may not be an issue; if we can get the MouseTweaks dwell applet enabled by default on the gdm panel, we might be fine without the old mouse gesture support.
- Status: 02-Feb-2011 (provided by Brian Cameron via email): GDM seems to work reasonably well with accessibility. You can configure GDM to launch AT programs or change to an a11y theme, and this can be configured in a per-display basis. This seems to provide basic section 508 support. Remaining serious issues include:
- There really isn't a good bootstrapping mechanism. How does a user turn on a11y if they can't use the computer without first turning on AT? Or if someone else uses their machine and turns of the login AT program, the user may not be able to turn it back on.
- There has been talk of adding keybindings to launch AT programs. I think this would be a nicer way to help address this problem. However, some mechanism to launch programs for users who cannot use the keyboard would also be needed to avoid these sorts of issues.
- No simple way to configure GDM features aside from turning them on in the GDM login GUI program itself. You can use gconftool-2 to turn on a11y features, but there is no easy GUI program that helps users to configure the system the way they want.
- Not really a GDM issue, but there isn't a great solution out there for how AT programs integrate with the lock screen program. Solutions that exist tend to be partial (e.g. for on-screen keyboard users but not blind users) and not easy to configure (e.g. they do not automagically figure out what AT programs to make available to the user).
3.5. Evince
Risk level: medium |
Work needed/remaining: test accessible text implementation, implement DocumentText interface for others backends like dvi.
People: DanielGarcia, CarlosGarciaCampos
- Purpose: PDF content viewing
- Status:
- 20-Jan-2011:
- Caret mode is implemented and works for pdf documents, but patches are waiting for approval. Pressing F7 change between caret mode and normal mode. In caret mode you can navigate throught text using normal keys, left, right, up and down, and select text pressing shift + normal movement keys.
AtkHypertext interface is implemented and patches are waiting for approval. It's needed to test it more, but it seems to work.
Text attributes like font family aren't exposed in AtkText interface, but I'm (danigm) working on that and will be done soon.
- bugs: Caret mode patch sended, and atkhypertext interface implemented. Related bugs with patch sended waiting for approval:
- 639408 (sidebar grab focus [patch])
- 639850 (open evince with pdf as argument [patch])
- 638905 (caret mode [patch])
- 639403 (atkhypertext [patch])
- 639932 (Expose text attributes in atkText, [patch])
- There's a evince branch in github with a11y patches applied, if you want to test, you can clone it at: git://github.com/danigm/evince.git
- 20-Jan-2011:
3.6. LDTP (port to pyatspi)
Risk level: medium |
Work needed/remaining: LDTPv2 depends upon pyatspi. It needs to be tested against the D-Bus form.
Key Contacts: DesktopTesting
- Purpose: provide testing support for GNOME
- Notes: With LDTPv2, which ported LDTP to pyatspi, LDTP is no longer dependent upon CSPI.
- Status: 20-Jan-2010 - team needs to begin testing more with at-spi2.
Low Risk
These are the items which have been deemed a minimal risk for GNOME 3.0 and/or were higher-risk items that have since been addressed.
1. Accessibility Stack
1.1. atk
Risk level: low |
- Work needed/remaining: None
Key Contact: LiYuan
- Purpose: ATK is the normalizing API for toolkits (GTK+, Gecko, Uno, etc.). Typically, a toolkit's accessibility layer (e.g., GTK+'s GAIL) will create ATK peers for toolkit objects, and the toolkit's accessibility layer will also load the atk-bridge to expose the ATK objects to assistive technologies.
Module: http://git.gnome.org/browse/atk
Notes: Yeah! Because it is independent of the interprocess communication mechanism used, the ATK library remains relatively stable. Note that ATK also has a new plug and socket API to denote out of process accessibles and is implemented for AT-SPI/D-Bus only. This may be a solution to help replace libgail-gnome when moving to AT-SPI/D-Bus. See https://bugzilla.gnome.org/show_bug.cgi?id=601552.
- Status: 24-Mar-2010 - no additional work needed or planned.
1.2. GAIL
Risk level: low |
- Work needed/remaining: None
Key Contacts: LiYuan
- Purpose: dynamically loaded GTK+ module the accessibility implementation for GTK+. Basically just hooks into GTK+ on one side and ATK on the other.
Module: http://git.gnome.org/browse/gail
- Notes: Yeah! Like ATK, GAIL is independent of the interprocess communication mechanism used, so it remains stable.
- Status: 24-Mar-2010 - no additional work needed or planned.
1.3. Java Access Bridge for GNOME (JABG - drop for GNOME3)
Risk level: low |
- Work needed/remaining: None
Key Contacts: KeWang
- Purpose: expose applications that use Java AWT/Swing to the GNOME AT-SPI infrastructure.
- Notes: JABG talks directly to CORBA using the Java CORBA bindings. JABG is to be replaced with the Java ATK Wrapper (JAW - see below).
- Status: 24-Mar-2010 - drop in favor of Java ATK Wrapper (JAW).
2. Assistive Technologies
2.1. MouseTweaks Applet
Risk level: low |
Work needed/remaining: port to GNOME Shell panel?
Key Contacts: GerdKohlberger and FrancescoFumanti
Purpose: the MouseTweaks applet provides on screen interaction for enabling/disabling MouseTweaks via "dwellable" icon in the panel, and then provide a means to select click operations (e.g., single click, double click, right click, drag) once the feature is enabled.
Notes: GerdKohlberger and FrancescoFumanti have been working to make MouseTweaks current with the new GDM panel. Work needs to be done with GDM to enable this applet by default in the GDM panel (and perhaps the desktop panel). Not sure of the status of GNOME Shell panel support.
- Status: 24-Mar-2010 - Gerd has finished the D-Bus port and the GDM panel support. We need to get this into the GDM panel by default. There are also a couple of open bugs with respect to mouse:button and mouse:abs/rel events in AT-SPI/D-Bus.
3. Desktop Environment
3.1. GNOME Shell: Keyboard Navigation
Risk level: low |
GNOME Shell requires support keyboard navigation (e.g., arrowing, tabbing, etc.) for people who cannot use the mouse. This requires support directly inside GNOME Shell and/or the toolkit that GNOME Shell is using.
- Bugzilla: There are several bugs on bugzilla tracking the different aspects of the keyboard navigation, most of them solved.
- Status
- 27-Mar-2011: Dan Winship implemented key nav support at the ST toolkit level, and applied it on most of the views. Some bugs still pending, but in general gnome shell is mostly key nav accessible now
Resolved
1. Yelp 3
Key Contacts: JoanieDiggs, ShaunMcCance
- Purpose: help for the desktop
Module: http://git.gnome.org/browse/yelp
Notes: Yelp 3 is based on WebKitGtk whereas previous versions were based on Gecko. This necessitated much work in both WebKitGtk (implementing accessibility for basic documents) and in Orca (implementing support for WebKitGtk).