2. Community Tools
- Mailing lists:
Issue tracker: File a bug, bug list
3. Getting Orca and Its Dependencies
Orca and its dependencies are already included in many distros. For more information and/or to get the code, please see the following:
Orca: Orca's git repository
- Accessibility Libraries:
- Braille and Speech Output:
4. How Can I Help?
4.1. Help Triage Problems
Pick your favorite application and set up an environment in which the only variable is that app, and where you can have multiple versions of that app co-existing simultaneously. Then use the most bleeding-edge version of that app as often as you can.
When something breaks, do the following:
- Identify as precisely as possible the version/build where things broke. The closer you can get to an exact date and/or build the better.
Having found the first version/build that is broken (say, Firefox Nightly from 15 September), reproduce the problem while capturing a full debug.out. (See the Debugging page for more info.)
- Perform the very same steps, commands etc. in the last version/build that is not broken (e.g. Firefox Nightly from 14 September), also capturing a full debug.out.
Compare the two debug.outs. They should be awfully similar because the only thing that's different is your favorite app, and you've taken the time to find the exact version of that app where things changed. So find out what happened: Look for events that are missing. Look for new events. Etc. A sample dissection of debug.out information can be found in the Orca-list archives: Part 1 and Part 2.
- Take all of the above data along with your analysis of it and file a bug against the appropriate component. That might be Orca; it might be the app you were testing.
We spend far more time doing the above than we do fixing the problem -- or reporting the problem to the developers who need to fix it when the bug is not within Orca. If you can identify the precise point when something broke *and* identify what exactly changed (e.g. the new/different at-spi event), it would help the Orca team out tremendously.
4.2. Fixing Bugs in Applications and Toolkits
Developers interested in helping out can implement and/or fix accessibility support in applications and toolkits. Here are some bugs Orca users need fixed:
The XFCE accessibility roadmap with descriptions of issues which need to be fixed in their applications
Developers who are skilled in speech synthesis development/refinement would be greatly appreciated in contributing to make eSpeak more human-sounding. See the documentation on adding or improving a language in eSpeak for more information.
Try testing your favorite application by using ONLY the keyboard. If an application is not fully keyboard navigable, it will be much harder for Orca users to use.
4.3. Other Ways to Help
Tackle something on the Roadmap
Join the GNOME Translation Project and help translate Orca to your favorite language.