I do not know what to say, as far as what technologies and layers should fix the accessibility issues, but my guess is that it is up to every software developer to do as much as they can. I like development, but the more that the lower layers can do things without the need for more development at the UI level the better. That way more people can take advantage of the bug guys doing their part. This includes Microsoft, Apple, Sun, and everybody else that makes their big money off of selling things and making big bucks.
My two cents. Tom----- Original Message ----- From: "Jamal Mazrui" <empower@xxxxxxxxx>
To: "Roopakshi Pathania" <r_akshi_tgk@xxxxxxxxx> Cc: <programmingblind@xxxxxxxxxxxxx>; <program-l@xxxxxxxxxxxxx> Sent: Sunday, June 13, 2010 10:28 AM Subject: Re: Developing cross-platform, accessible apps
This reminds me of a debate related to Section 508 accessibility standards. Some argue that a software application should be considered accessible if it implements the main accessibility API of the platform, e.g., if a Java app implements the Java access API. Others argue that functional performance must also be considered as well as design specs. So, if relevant assistive technology does not support that API, then, in practice, the app is inaccessible even though, in theory, it could or should be accessible.Proponents on one side say that it is optimal for the responsibility for accessibility to be divided among different parts of the ecosystem that necessarily must work together to achieve accessibility. If assistive technologies do not take advantage of an API that is availble, they are at fault, not the application, and it is important for AT to meet its responsibility on behalf of users with disabilities. Without such an expectation on AT, its vendors will lack sufficient incentive to support APIs that are critical for accessibility.Proponents on the other side say that idea sounds good in principle, but the result can be that users with disabilities are set back by inaccessible apps in their work and personal lives, a reality that is unacceptable.Jamal On 6/13/2010 12:21 AM, Roopakshi Pathania wrote:Hi Jamal,Well Most major screen readers support working with Swing, even if a screen reader like Window Eyes uses a different approach. I’ve checked and Hal also supports the bridge. Besides, it’s not possible to dismiss access to Swing based applications out of hand especially because Swing components are widely used in software developed for corporate environment. SAP and Oracle, both state the need of using Java Access Bridge on their accessibility requirements page.Java Access Bridge is probably the crux of the problem because it does not expose the entire Java accessibility API to a screen reader. If anyone is interested, here is a forum for discussing accessibility of Java for developers who want to make their software accessible.http://forums.sun.com/forum.jspa?forumID=3&start=0If you go through some of the posts, you’ll realize the kind of limitations Java Access Bridge imposes on assistive technology.I quite agree with Ken, we do need a better bridge to Java’s accessibility API. This might be possible if we try to get developers (from the general community) interested in this project.Regards --- On Sat, 6/12/10, Jamal Mazrui<empower@xxxxxxxxx> wrote:From: Jamal Mazrui<empower@xxxxxxxxx> Subject: Re: Developing cross-platform, accessible apps To: programmingblind@xxxxxxxxxxxxx Cc: "Roopakshi Pathania"<r_akshi_tgk@xxxxxxxxx>, program-l@xxxxxxxxxxxxx Date: Saturday, June 12, 2010, 11:54 PM Hi Roopakshi, I am aware of the Java access API, but unfortunately, I do not think there is sufficient screen reader support for it on Windows. This is more the fault of the screen reader companies than Sun, since the API is strong on the server side. Window-Eyes, for example, does not support that API at all. JAWS works partially. I hear that NVDA works well. I do not know about System Access or Hal. With the SWT approach, on the other hand, apps can be fully accessible because native widgets are used, including MSAA-integrated controls on Windows. Thanks for the info about Axtk, which I had not heard about. At first, I thought the name was associated with the cross-platform GUI library called TK, which has poor accessibility, but I see that it is actually wx-related, as you say. Jamal On 6/12/2010 11:53 AM, Roopakshi Pathania wrote: > > Hi Jamal, > Thanks for the info about Axtk -- I had not heard of it. The name made me first think it was related to the cross-platform GUI library called TK, which has poor accessibility, but I see that it is based on wxWdigets, as you say. Jamal On 6/12/2010 11:53 AM, Roopakshi Pathania wrote:Hi Jamal, You left out Java Accessibility API that providesaccess 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 ondeveloping 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 inaccessibleapplications 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 gearedtowards 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 dataanalysis, 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, accessibleappsTo: "programmingblind"<programmingblind@xxxxxxxxxxxxx>,program-l@xxxxxxxxxxxxxDate: 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 usingprogramminglibraries that wrap native widgets of theplatform. Thesenative widgets generally implement the mainaccessibilityAPI of the platform, much more so than customwidgets.On Windows, native widgets are most likely toimplementMicrosoft Active Accessibility, orincreasingly, UserInterface Automation as it replaces MSAA. OnLinux,the GTK+ widgets that are native to the Gnomedesktopimplement the Assistive Technology ServiceProviderInterface. On the Mac, Cocoa-based widgetsimplement the MacAccessibility Protocol. Thus, a cross-platform library is most likely tocreateaccessible GUIs if it wraps native widgets of eachplatform,rather than defining its own widgets. Adisadvantageof this approach is that the developer needs to beconsciousof small differences in the behavior of widgetsacrossplatforms, even though wrapping code of thelibrary tries tominimize such differences. Besidesaccessibility, anadvantage of this approach is that widgets havethe look andfeel that sighted users are accustomed toexperiencing oneach platform. Sometimes, a GUI library is closely associatedwith aprogramming language that has especially strongsupport forthat library in wrapper functions and designtools. Afew language and library combinations that seem toworkparticularly well for cross-platform, accessibledevelopmentare 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 ofthe MonoFramework http://mono-project.org Note that, in this case, the Microsoft .NETFrameworkshould be used as the runtime environment onWindows inorder to have native widget support. http://msdn.microsoft.com/en-us/netframework/default.aspx If others have further info or ideas on thistopic, pleaseshare. Jamal __________ View the list's information and change yoursettings at //www.freelists.org/list/programmingblind__________ View the list's information and change your settingsat//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
