I've seen a lot of examples which use
getAccessibleContext().setAccessibleDescription(...)
to set some "magic" description.
What is the use of this description? Where can it be seen and
how should it support accessibility?
Why setDescription(...) is not used?
Additionally, what is your opinion / experience with Java accessibility
stuff?
I haven't actually used Swing's accessibility facilities in my applications (and I probably should), but I presume that it will aid in the use of screen readers and other technologies which to improve the accessibility of an application.
From the Accessibility and the Swing Set article:
If an application fully supports the
Java Accessibility API, it can be
compatible with, and friendly toward,
screen readers, screen magnifiers, and
other kinds of assistive technologies.
The linked article goes in to some depth about the accessibility features of Swing and the Accessibily API.
As pointed out the accessible information is used to expose information to assistive technologies such as screen readers (in short as a blind computer user I use a screen reader to gather useful information about what control has focus and other useful things happening in a application and then for it to speak it out to me. Examples of screen readers are NVDA www.nvda-project.org for windows, Orca http://live.gnome.org/Orca for the gnome desktop on unix platforms and voiceover included by default in MacOSX). For a number of standard controls which contain text you may be able to get away without having to explicitly set accessible information (eg. if you have a button with the text word "OK" then this probably will be spoken fine by a screen reader. The importance of setting accessible information comes in when you have no text showing (eg. a button with a graphic label) or when you are developing a custom control (from memory without going back through some of the Java swing docs, I think the accessible name is to identify the control and accessible description is to provide extra information, may be a clue as how to use it if its a custom control).
Now if you wish to see how this works, NVDA and Orca are opensource projects and voiceover is included in MacOSX 10.4 (I think) and higher, so you can try one of these at no cost (unlike some of the commercial offerings which can be very expensive).
Related
I have made a Screen Recorder using Java Swing and Xuggler 5.4. I have developed it in Windows 8 64 bit. It's working excellent for Windows. But at client side on Linux's environment , nothing is working. I have searched thoroughly but not getting any solutions. I have checked this thread , but it didn't work for me.
Then I tried to create simple Transparent window in Linux but it's also not working. I was not able to click through the Resizeable Panel. I have used the same JRE version (1.7) for both. Have I miss understood Java's Cross Platform Support as far as Swing is concerned?
Please Give Me Some Advice...
I have always found logging to be the best debugging tool at your disposal! Many a times, java debuggers take you into APIs where you need not go every time. Logging values of your variables, and generic 'I have reached till this point' statements make life a lot easier.
So, I suppose you have ample logging done in your code. That could give you clues on what's happening on your client's system.
Are the right environment variables set? Are they pointing to the correct Java versions you need.
If there are some specific Screen capturing requirements(plugins / modules / API) your code has, are they available on the Linux m/c?
Like #MadProgrammer said, in the end, Java has to talk with the native graphics APIs to render your screen.
I would try to debug it in this way -
Check whether my main screen loads or no(by disabling the screen capture functions for a while).
if not, dig deeper.
Check whether all necessary components for capturing screen(audio and video) are available.
Check whether the code is being run with appropriate permissions to control the h/w devices you may need.
How do I check (using Java or JavaScript) if a browser has support for blind or partially-sighted people?
If you are looking to determine whether an assistive technology (like JAWS or Window-Eyes) are installed, no, you cannot with Javascript. These technologies use OS-level APIs, and current browsers don't do anything that would cause their presence to be detectable. There is a flash-based hack that can detect newer versions of screen readers see http://webaim.org/techniques/flash/techniques
Perhaps you want to provide a different Flash interface or options if a user is using a screen reader. For instance, you may want to provide additional buttons or turn on self-voicing features when the person watching your movie is using a screen reader. You can detect screen readers using ActionScript. The Accessibility.isActive() function will return "true" if a screen reader that is capable of accessing Flash content is detected (currently only up-to-date versions of Window-Eyes, JAWS, and IBM Home Page Reader). For instance, you might add:
if (Accessibility.isActive()) {
_root.selfVoicing.play();
}
Important
Because there is a slight delay between when your movie begins and when the screen reader is detected, Accessibility.isActive() may incorrectly return false during the first few moments that your movie is playing. The Flash movie must also have focus in order for this to work. This can be solved by associating the ActionScript with a button within the Flash movie.
Finally, this method of detecting a screen reader, will not detect all screen readers. It will only detect the most recent versions of screen readers that support MSAA and have the Flash 6+ player installed.
This method is the only way of automatically detecting screen readers on the web. If you want to provide alternative content for screen reader users, you could use a Flash movie to detect the presence of a screen reader and redirect appropriately. However, this also assumes that the user has the Flash player installed (which most users do). If the user does not have Flash, then the detection will not work and the user might be presented with additional accessibility issues. Care must also be taken in providing alternative content for screen reader users. The alternative content must be kept up-to-date and provide the same information and functionality as the non-screen reader content. Here is the code to redirect based on screen reader presence:
if (Accessibility.isActive()) {
getURL(screenreaderpage.htm);
} else {
getURL(normalpage.htm);
}
The short answer is there's no bulletproof way to do this. While the flash solution may work in some situations it isn't a good solution. I'm a totally blind programmer and since flash is generally so completely inaccessible I don't have it enabled by default in my browser. iPhones are used by a lot of blind individuals and for obvious reasons the flash solution won't work on them either. Even if the browser does support assistive technology that does not mean your site will be accessible. If your entire site is JavaScript or WebGL that draws pictures onto a canvas it doesn’t matter how good the screen reader supporter in a browser is, there’s no way to provide information on dynamically created graphics unless the author provides textual descriptions of what is drawn to the screen. Ideally you would want to code your site in such a way that it can be used by both blind and sited individuals with no changes. If that doesn't work you could always put an invisible link to an alternative version of your site or other invisible content specific to screen readers that won't be displayed to sited users. For a discussion of creating content that is only visible to screen reader users see this link For a general intro to web accessibility see http://webaim.org/intro/
I have a single Swing JFrame which contains a couple JLabels, a few read-only JEditorPanes, and a couple buttons. JAWS users are requesting that the application be read with less user interaction required. Right now, the application starts with a certain element in focus, and the user has to press tab to move focus and continue to the next element. Whereas with a web page, for example, JAWS will just go through and read everything without requiring the user to press tab. Especially annoying for our JAWS users, the read-only JEditorPanes only read one line of text at a time requiring the user to press the up and down arrow keys to move between them.
How can I make this JFrame be read to JAWS version 9 users more fluently?
You may be able to do this but it would require using the Jaws COM api that isn't really supported. Jaws interacts with desktop applications in a much different manner then with websites. Jaws renders web pages into a virtual buffer and does all kinds of magic to make them easier to use. Jaws doesn't do this for desktop applications. I assume part of the reason it doesn't do this is desktop applications don't have all the information available to create an alternative presentation mode that is available with HTML. For what ever it's worth even utilities included with Jaws don't automatically have there read only edit fields spoken. Saying all that if you really need to do this your best bet would probably be to speak the contents of read only edit fields through the jaws api when the user gives them focus. This would require using COM from with in your Java application to access the api. I know there are java libraries that will allow you to use COM in some form but I've never done this. You can find a copy of the api in your standard Jaws installation directory, in my case it's
c:\program files\Freedom Scientific\jaws\jfwapi.dll
You'll have to use your favorite application for looking at COM libraries to determine what methods are available since there's no official documentation that I can find. You may also want to take a look at the following code sample, it's in AutoIt but gives a general idea of how to speak text using multiple screen readers. http://www.scribd.com/doc/19371/speak-with-autoit
Is there a way to display a Flash or Adobe Reader ActiveX control in a Java AWT frame?
I'm porting a large old J++ application to standard Java and it needs to host a certain ActiveX control on an AWT frame.
Is this possible?
I looked at the JACOB (Java to COM Bridge) project and it doesn't appear to support ActiveX objects that draw on the screen.
It looks like this can be done by mixing AWT and SWT.
The Eclipse project has a sample snippet that embeds Microsoft Word into an AWT/SWT mixed app.
It appears that you will need to purchase a proprietary library in order to able to do this, as Java itself doesn't allow access to COM. Another similar question (about just Flash in Java) can be found here and a couple commercial solutions were listed.
I should note that whatever route you end up taking, you should optimally try to find a library that provides access to an Internet Explorer control, as opposed to just Flash or Adobe Reader. That's because, once you have access to an IE element, you can provide it with a URL (even if it's a local file) of either a .swf or .pdf document, and it will automatically load the correct plugin for each (I used this shortcut once for a personal C++ project in which I needed to load several different ActiveX controls). It appears that the EasyJCom library at the above link does provide such access to an embedded IE control.
This is my first post on Stack Overflow and I'm just wondering on the options of making a system tray application. The application would run primary from the system tray while still operating, and could be brought up into a window when clicked on. It is also needed to have some support for global keystroke tracking, to bring up a window.
I'm curious on what options I have available to me, as I'm sure that there are many ways to do this. I'm most familiar with with Java though I have some experience with C++. I'm willing to explore other languages if they have some definite perks to them, though it would be nice to work with what I know in a way.
Thank you
Java 6 has new functionality which allows for the creation of applications which use the system tray.
The New System Tray Functionality in Java SE 6 article goes into the details, and provides some sample code as well.
The newly added SystemTray and TrayIcon classes of the java.awt package can be used to add icons to the system tray. The icons can respond to mouse clicks and use pop up menus as well. However, this new functionality is a part of AWT, so it doesn't do a very good job integrating with Swing components.
Here's an example of a little clock that shows up in the system tray which was made using the SystemTray and TrayIcon classes in Java 6:
(source: coobird.net)
Plain old Winforms would get my vote.
If you are familiar with Java you should have little difficulty using one of the managed languages to create a simple tray app with .NET.
Here is some advice on the correct way to create a tray app.
Be carefully with manged applications and Java here. Tray applications run all the time. So, if they are poorly written then they can use enough system resources to interfere with other things.
There is nothing wrong with manged code or Java in general, but it can be more difficult to keep managed or java apps frugal with memory, I/O and CPU time.
I'm saying this as a dev manger on the Windows perf team - we've seen lots and lots of very piggy tray applications. Yes, some are even windows or MSFT applications.
It may be a better approach to write a very small light weight tray app that launches a richer process when the user needs it. You can write your try app in simple C++ right on top of the low level Win32 APIs. If you don't want to use the Win32 APIs directly, you can use the Windows Template Library.