This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 133434 - Missing voice guide for code autocompletion
Summary: Missing voice guide for code autocompletion
Status: RESOLVED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: Completion & Templates (show other bugs)
Version: 6.x
Hardware: Other Windows XP
: P3 blocker with 1 vote (vote)
Assignee: Dusan Balek
URL: http://www.netbeans.org/kb/60/java/qu...
Keywords: A11Y
: 133354 133382 133404 133412 133417 133438 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-21 11:49 UTC by bernar1
Modified: 2011-01-29 05:25 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bernar1 2008-04-21 11:49:45 UTC
I think that code autocompletion is very useful tool, but I couldnt find any way how to read it by JAWS.
Comment 1 Jaromir Uhrik 2008-05-12 12:22:34 UTC
*** Issue 133354 has been marked as a duplicate of this issue. ***
Comment 2 Jaromir Uhrik 2008-05-12 13:03:41 UTC
*** Issue 133382 has been marked as a duplicate of this issue. ***
Comment 3 Jaromir Uhrik 2008-05-12 13:18:55 UTC
*** Issue 133404 has been marked as a duplicate of this issue. ***
Comment 4 Jaromir Uhrik 2008-05-12 13:40:41 UTC
*** Issue 133412 has been marked as a duplicate of this issue. ***
Comment 5 Jaromir Uhrik 2008-05-12 13:56:59 UTC
*** Issue 133417 has been marked as a duplicate of this issue. ***
Comment 6 Jaromir Uhrik 2008-05-12 16:00:30 UTC
*** Issue 133438 has been marked as a duplicate of this issue. ***
Comment 7 Vitezslav Stejskal 2008-05-18 17:53:36 UTC
I have no idea what's wrong, but trust you guys when you say that this is broken.
Comment 8 David Strupl 2009-10-27 15:20:29 UTC
Jaro, can you please explain what is missing or what should be changed in our code? What does JAWS need so it can read it?
Comment 9 draikes 2010-12-02 17:24:04 UTC
As i see it, the code completion is in a popup menu similar to those used for context menus, so there should be no reason the code completions couldn't be read by JAWs as long as their accessibleName properties are set correctly.

I also understand that not only is there a popup menu with the code completion choices in it, but also a window with the associated javadoc. If there were a keystroke (say f6) to switch to the javadoc window to enable the user to read it, and then (shift+f6) to switch back to the popup menu this would be outstanding.  However, I am not sure this is entirely necessary.  I have used code completion in JDeveloper, and usually know what I am looking for in general, so it simply speeds up my coding process. I am not trying to learn the javadoc specifics of a class or method.  This is where javadoc help comes in and that is quite accessible already.
Comment 10 stefika 2011-01-20 17:52:06 UTC
My team at Southern Illinois University has looked into this problem and would offer some advice. One reason why JAWS and other screen readers cannot access auto-completion information is because, to our knowledge, no property/focus/other events are fired down the AWT listener chain when these messages occur.

The way screen readers, on windows at least, work, is basically like this:

1. Some kind of event fires (e.g., a focus listener event), which tells the screen reader that something is going on on the screen. 

2. These events are usually sent through the Java access bridge, if it is installed (this ONLY works on windows 32-bit, and is hit or miss). If the access bridge is not installed, or the user is on a non-supported operating system, the screen reader will literally do nothing, making NetBeans, in a very real and literal sense, 100% broken --- completely and totally non-accessible to people with disabilities.

3. If the bridge is installed, or a cross-platform alternative (e.g., see the Sodbeans project), the event type is analyzed (e.g., oh, you're on a button named Close, output "Close button" to the user)

For most things, this sort of procedure generally works fine, but there are several classes of NetBeans related items where this approach fails. Specifically, there are certain user interactions in NetBeans that, so far as we are able to ascertain, do not fire events, of any kind. These include much more than code-completion, like the following:

1. Editor hints (e.g., little yellow lightbulbs)

2. Code completion

3. Visual features and enhancements in an editor (e.g., visual brace matching)

amongst others.

Now, consider for a moment why this is the case. For code completion, for example, NetBeans is CORRECTLY not firing focus events, because code completion does not, and should not, change the focus, as this would be a major usability problem (e.g., you could not continue typing in the editor uninterrupted). But, since no alternative event type is fired up the AWT chain, perhaps something that could be made up new, like an EditorPopupEvent, a screen reader, or other similar utilities, have no way of detecting that something happened.

So, what's the tangible effect for a blind person using such a tool? Suppose you have the following lines of code:

public int leg_computer(Animal animal) {
   return animal.
}

If a sighted person is typing at the "dot," or if they press control space, they would immediately see a window popup with the functions and such of type Animal, whatever they are. If that user presses the "up" key on the keyboard, it would scroll up the code completion window, but not change the line of code.

For a blind person, the user would, when pressing the up key, and since no events are fired, a screen reader would typically say something like, "return animal." over and over again. The user has no way of determining what is going on, because there is no way for a screen reader to know that an additional window has appeared.

Finally, here are my concrete suggestions:

1. When code completion or editor hints windows appear, the system somehow needs to fire an event saying what is happening.

2. The events fired should NOT be focus events (unless they change the focus), and would probably be better off being either generic property events (e.g., a window in an editor popped up), or a new kind of event.

3. These events, and this is critically important, must give a sufficient amount of information to allow a screen reader to read the information. For example, such events should at least have information on which code completion popup is currently highlighted (e.g., Animal.getNumLegs()).

That's a lot of detail, and this is a complicated issue, but I hope that helps.
Comment 11 Dusan Balek 2011-01-27 15:11:21 UTC
The problem with the code completion window is that it never gets focus. When the code completion window is displayed, focus stays in editor and that's IMHO the reason why the code completion window is ignored by screen readers even though its 'accessibleName' property is correctly set.
Trying to workaround this by firing fake events (other than focus events) up the accessible components hierarchy.

http://hg.netbeans.org/jet-main/rev/3f0ffb464e59

Seems to work fine when tested on Linux with Orca.
Comment 12 Quality Engineering 2011-01-29 05:25:59 UTC
Integrated into 'main-golden', will be available in build *201101290000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/3f0ffb464e59
User: Dusan Balek <dbalek@netbeans.org>
Log: Issue #133434: Missing voice guide for code completion added