Ken, it sounds like you have some really cool things going on. Here are a few words about Java accessibility and some holes into which one can fall.
1. Macintosh uses a proprietary Apple VM which doesn't have anything resembling a way to make programs accessible. Once again, Apple's "my way or the highway" attitude bites us in the balls.
2. While the Swing classes provide some automatically, they are not the most common set of widgets used by Java hackers.
3. Different screen readers handle Java differently and results, even on the same OS can vary quite a lot. For instance, JAWS uses the Java Accessibility Bridge to try to make Java applications speak and braille useful things. Unfortunately, there is no one currently maintaining the bridge so its many bugs and downright bizarre way of sending data to the AT is often broken. A perfectly accessible Java application can be rendered useless by problems in the bridge.
A volunteer hacker made a really nice Java accessibility solution using the relatively new Window-Eyes scripting facility. His solution does not use the bridge and WE, with his scripts installed, provides a much nicer user experience than the AT that use the bridge.
If I remember correctly, a member of this list had written a Java screen reader using some of the same techniques as the one in Window-Eyes.
Neither Window-Eyes or the Java based screen reader require the swing classes to become very accessible.
3. Although Sun pretty much designed and implemented the GNOME Accessibility API, GNU/Linux Java programs require the bridge to communicate with orca. The bridge introduces its usual set of bugs and orca pretty much sucks in Java programs.
HH, cdh On 06/12/2010 11:53 AM, Roopakshi Pathania wrote:
Hi Jamal, You left out Java Accessibility API that provides access to Swing based applications on all platforms (not completely sure about Mac) through Java Access Bridge. In this regard, the guidelines laid down by IBM on developing a completely accessible Java application are quite useful. http://www-03.ibm.com/able/guidelines/software/accesssoftware.html I like to point the developers of inaccessible applications to this page. One more toolkit might be of interest: AxTk. http://code.google.com/p/axtk/ It is built on wxWidgets and is especially geared towards screen reader users. It is also suppose to have text to speech wrapper class supporting a number of speech engines. I’m building my own tools for financial and data analysis, so have looked at cross-platform accessible libraries. Regards Roopakshi --- On Sat, 6/12/10, Jamal Mazrui<empower@xxxxxxxxx> wrote:From: Jamal Mazrui<empower@xxxxxxxxx> Subject: Developing cross-platform, accessible apps To: "programmingblind"<programmingblind@xxxxxxxxxxxxx>, program-l@xxxxxxxxxxxxx Date: Saturday, June 12, 2010, 8:27 PM This is to share some points I have learned about developing cross-platform, GUI-accessible, desktop apps. Currently, the key is using programming libraries that wrap native widgets of the platform. These native widgets generally implement the main accessibility API of the platform, much more so than custom widgets. On Windows, native widgets are most likely to implement Microsoft Active Accessibility, or increasingly, User Interface Automation as it replaces MSAA. On Linux, the GTK+ widgets that are native to the Gnome desktop implement the Assistive Technology Service Provider Interface. On the Mac, Cocoa-based widgets implement the Mac Accessibility Protocol. Thus, a cross-platform library is most likely to create accessible GUIs if it wraps native widgets of each platform, rather than defining its own widgets. A disadvantage of this approach is that the developer needs to be conscious of small differences in the behavior of widgets across platforms, even though wrapping code of the library tries to minimize such differences. Besides accessibility, an advantage of this approach is that widgets have the look and feel that sighted users are accustomed to experiencing on each platform. Sometimes, a GUI library is closely associated with a programming language that has especially strong support for that library in wrapper functions and design tools. A few language and library combinations that seem to work particularly well for cross-platform, accessible development are as follows: * Java and the Standard Widget Toolkit http://www.eclipse.org/swt/ * Python and wxWidgets http://wxPython.org * C# and the System.Windows.Forms classes of the Mono Framework http://mono-project.org Note that, in this case, the Microsoft .NET Framework should be used as the runtime environment on Windows in order to have native widget support. http://msdn.microsoft.com/en-us/netframework/default.aspx If others have further info or ideas on this topic, please share. Jamal __________ View the list's information and change your settings at //www.freelists.org/list/programmingblind__________ View the list's information and change your settings at //www.freelists.org/list/programmingblind
__________View the list's information and change your settings at //www.freelists.org/list/programmingblind