One major block to accessibility for some programs, including Tom Tom, is that they have a custom user interface layer with which the core code communicates when it wants to put something on the screen. This custom UI layer then talks to "glue" code that is specific to each platform.
Tom Tom seems to run on virtually mobile device I can think of so this approach means that all they need to do is write the "glue" for each platform and they're in business.
The obvious benefit to the TT approach to UI is that they can maintain their very specific look and feel across platforms which maintains the company brand identification. The second reason is that building the "glue" is a lot easier than writing an entire UI from scratch for each platform. Thus the time saved and the trademark look and feel makes this approach very desirable to mainstream companies who want to be on a lot of platforms.
Of course, because the UI is only exposed via the "glue" there is no place to adequately add the accessibility information so it can be communicated to the user. All the iPhone sees is a lot of bitmap and a little text here and there. Some menus might work if TT uses the OS based menu controls (which don't really exist on iPhone) so the user will not get anything useful from VO as it doesn't know what to say.
The write once, run on many notion was promised by Java over a decade ago. It never really happened. As I described in a message earlier the Java Accessibility Bridge on Windows and GNU/Linux is flaky at best. The Macintosh documentation someone posted a link to seems to suggest that VO communicates directly with the Java VM on a Mac and "auto-magically" these programs are accessible. The one caveat to the Java solutions on Mac is that they will only work if they are written using the Swing UI library as it is the only one (to my knowledge at least) that properly communicates accessibility information with the Java VM.
A lot of Java code is written to different UI libraries which do not properly communicate with the Bridge or the OS accessibility API. Oracle has a proprietary Java VM that only talks to an ancient version of the VM and, therefore, the only version of a screen reader that works with it is a really old JAWS.
I think the guy who did the Window-Eyes solution did so using the VM debugger interface which is a really creative solution to a very hard problem. this will eliminate the need for Swing and for the Bridge entirely and can probably be ported to Macintosh and GNU/Linux as it is unlikely to require too much Windows specific code that cannot be replaced by code that will work well on other platforms.
Only on cup number 2, caffeine levels dangerously low... cdh On Aug 27, 2009, at 4:44 PM, JohnyTheHess wrote:
-- John W. Hess & Barclay the WonderLab Good afternoon. I saw a message this morning stating that TomTom was not accessible. Could you give more info? I think this would be of interest to all. Thanks.Click on the link below to go to our homepage. http://www.icanworkthisthing.comManage your subscription by using the web interface on the link below.//www.freelists.org/list/macvoiceover Users can subscribe to this list by sending email to macvoiceover-request@xxxxxxxxxxxxx with 'subscribe' in the Subject field OR by logging into the Web interface at //www.freelists.org/list/macvoiceover
Click on the link below to go to our homepage. http://www.icanworkthisthing.com Manage your subscription by using the web interface on the link below. //www.freelists.org/list/macvoiceoverUsers can subscribe to this list by sending email to macvoiceover-request@xxxxxxxxxxxxx with 'subscribe' in the Subject field OR by logging into the Web interface at //www.freelists.org/list/macvoiceover
