Thanks for clarifying that Jamal. I'm not familiar with IA2 but is there a
reason why Apple hasn't implemented it out of interest? Does MacOS provide
native accessibility APIs for UIs?
Also, in the helpful list of language/technology combinations you listed,
you include .NET desktop apps that leverage the standard
System.Windows.Forms classes. As you say, .NET apps require MONO to be
installed on Linux and I guess also the Mac since this runs under some
flavour of Unix, to run and on Windows, this takes advantage of native
accessibility features. A couple of questions spring to mind:
1. How accessible are these apps when run under Mono?
2. Does Mono leverage the native accessibility features of both Linux and
Mac OS? I'm not really familiar with any native accessibility support on
Linux or Mac OS for that matter so this question may not make sense.
3. Microsoft are moving (have moved?) to XAML to provide UIs. I've seen a
couple of threads on this forum regarding developing such apps in VS, but
would be interested to know how accessible the applications are and in
particular, whether this is supported under Mono and/or Silverlight? I
believe XAML uses new libraries to "draw" screen widgets and so would
require AT to support new APIs in much the same way as Swing and Java Access
Bridge? This would need to extend to Silverlight apps also. Is this
currently possible?
Cheers
Ian
-----Original Message-----
From: Jamal Mazrui [mailto:empower@xxxxxxxxx]
Sent: 13 June 2010 16:43
To: programmingblind
Cc: Ian Sharpe
Subject: Re: [program-l] Re: Developing cross-platform, accessible apps
Excellent points, Ian -- thanks. The XUL framework uses the
IAccessible2 API, developed by Mozilla and IBM, and reflected in apps
such as Firefox and Thunderbird. It is certainly intended to be
cross-platform though by means of custom widgets that implement IA2,
rather than native widgets of the platform. XUL apps can provide good
accessibility on Windows and Linux, though not on the Mac,
unfortunately, because Apple has not supported IA2.
Jamal
On 6/13/2010 11:22 AM, Ian Sharpe wrote:
Hi Jamal
I'm afraid I'm not sure on how accessible this is on the various platforms
but XUL provides the GUI for Mozilla (and guess this includes Firefox?).
When I looked at this way back now, it looked like a cross-platform XML
based UI technology but never had enough time to investigate it properly.
I
certainly found Mozilla very accessible on Windows using custom colour
schemes and screen magnification but suspect it was also accessible for
screen reader users since I believe this browser was used by many blind
people. I could be wrong but I got the impression XUL utilized the native
capabilities of whichever platform the app was running on in much the way
you describe.
The other point I'd make is that just because your talking about a desktop
scenario, there's no reason why you still can't use HTML to produce the UI
which can be extremely accessible on all platforms if designed well and
appropriate markup used. If I were asked to produce a cross platform
accessible desktop app now, I'd probably use this approach but that maybe
simply because it's because I very familiar with designing accessible web
applications and wouldn't have to worry about platform specific
implementations of native widgets as you say.
Cheers
Ian
-----Original Message-----
From: program-l-bounce@xxxxxxxxxxxxx
[mailto:program-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Jamal Mazrui
Sent: 12 June 2010 15:57
To: programmingblind; program-l@xxxxxxxxxxxxx
Subject: [program-l] Developing cross-platform, accessible apps
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
** To leave the list, click on the immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** program-l-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to
** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
** To leave the list, click on the immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** program-l-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to
** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
