Issue 1- JTables, JLists, and NonEditable JTextAreas
do not always allow users to Cltr+Tab out of them -- modal dialog boxes
Description
Users should be able to tab to all the controls of a dialog box. However,
when the focus is in a component like the JTextArea, where the TAB key
has a specific meaning - users should be able to use Ctrl+Tab to move
focus to the next component. Many Dialog Boxes in the IDE do not exhibit
this behavior Dialog boxes built using the IDE do allow users to use Ctrl+Tab
to move focus out of JTextAreas. This problem becomes even more serious
in the case of non editable text boxes where the focus is not visible.
Bug Tracking
This is a netbeans bug. JTextAreas used in non-NetBeans components do
accept Ctrl+Tab to move focus to the next component.
Filed in Issuezilla #15139
and looks like FIXED
Examples in the IDE
JTextAreas are used for the "instruction" text in NetBeans wizards.
These are focusable so that a screenreader can read the instruction text.
Apparently, this problem only occurs with modal dialog boxes, but that
covers all wizards and property editors.
What needs to be done once the bug is fixed
No engineering task expected. Testing required.
Issue 2- SWING components that swallow Tab when
not necessary - Uneditable JTextAreas
Description
Lots of components swallow tab. In many cases, this is because tab is
a valid character for that component. In such cases, the user enters Control-Tab
to move to the next component. In some cases, though, tab makes sense
for an editable component, but not a non-editable one. Keyboard accessibility
in the IDE would be improved if components didn't bind the Tab key except
when absolutely necessary.
Check if a problem also with empty JTable.
Bug Tracking
4514331
Examples in the IDE
Transparent Persistence wizards (in Forte for Java).
What needs to be done once the bug is fixed
No engineering task expected. Testing required.
Issue 3- SWING components that swallow Enter
- Combo boxes, HTML Editor kits, Menus, Tables, Text areas , Text fields.
Description
If the keyboard focus is on a component that swallows the enter key,
the user cannot easily access the default button for the dialog box. It
would be nice if components that don't really need enter (disabled components,
JTextFields, etc.) would not swallow it. Users can guarantee that the
default button will be hit by using Control+Enter, but it would be nice
if they didn't have to use this when not necessary.
JTextField swallows return, and doesn't need to. No binding for return
in JLF.
Closed JComboBoxes swallow return. JLF only specifies binding for open
ones.
Non-editable JTextArea swallows return. Editable ones need to do so.
Check if a problem for empty JTable.
Bug Tracking
TextField/TextArea: 4515750
ComboBox: 4515752,
4337071
Mostly fixed in Merlin Beta
Issue 4- JTextAreas that are not editable do not
provide any visual indication of focus.
Description
Non-editable JTextAreas can receive the keyboard focus, but there is
no visible indication of where the focus is. This is especially a problem
because the user needs to know to Control+Tab out, but they don't know
where focus is.
In the mean time, module developers should set the initial focus on wizards/dialog
boxes to some component other than the non-editable text area. This is
not a workaround, but is good practice in general. Put the initial focus
on the first component the user will need to edit. For more information,
there are some guidelines here.
Bug Tracking
There is a JDK issue filed to provide a visible indicator: 4512626
An alternative is to make these not focusable and put something special
in for screenreaders: 4456078
Examples in the IDE
Instructions on wizard pages.
What needs to be done once the bug is fixed
No engineering task expected. Testing required. Some workarounds may need
to be removed.
Issue 5: Combo Boxes as Cell Renderers/Editors in
JTables
Description
When JComboBox is used as a cell renderer/editor in a JTable, it does
not behave the same way as a JComboBox by itself does. It is not keyboard
accessible. The combobox menu doesn't post, or if it posts, arrow keys
don't work.
Bug Tracking
JDK issue 4109871
Examples in the IDE
In Transparent Persistence, Database Explorer, WebApps.
What needs to be done once the bug is fixed
No engineering task expected. Testing required.
Note
A custom cell renderer is available that solves this problem. This cell
renderer can be made available to other teams that wants it. However,
the current policy is not to provide workarounds to JDK problems, so this
may not be appropriate.
Issue 6: JTree - Return key toggles open.
Description
Hitting return when focus is on a JTree node toggles the node. This does
not follow JLF guidelines. The JTree should pass the keystroke to its
container.
Bug Tracking
JDK bug. 4408233.
Fixed in merlin-beta.
Examples in IDE
Template choose in File->New.
What needs to be done once the bug is fixed
No engineering task expected. Testing required.
Issue 7: Picking up system fonts and sizes from within
an application is not possible / easy.
Description
Not sure about this one -- would like clarification from whomever contributed
this issue in the first place. A couple of possibilities are that:
In the form editor, the font shown in the font property is not always
accurate. It is sometimes easy to accidentally hard code a font. Also,
because of the value showing for the font property, it is not easy to
know whether the font is hardcoded or not.
Could be just that it is hard for the user to know how to change the
IDE's fonts. This requires a command line switch at IDE startup.
Also, there are problems in the JDK that does not let the IDE pick up
the system fonts automatically: 4419964,
4419975.
Issue 8: We cannot provide mnemonics on tabs
Description
Tabs don't get mnemonics.
Bug Tracking
JDK issue: 4415678.
Fixed in Merlin-beta
Examples in the IDE
Explorer window.
What needs to be done once the bug is fixed
Mnemonics would have to be added.
Issue 9: Escape in a combo box
Description
Open a combo box menu and use arrow keys to change the selection. Hit
escape. Should undo the change, but it doesn't.
Bug Tracking
JDK issue: 4281840
Related bug: 4199622
Examples in the IDE
Right click on a Fields node, choose New Field... There are some combo
boxes in there.
What needs to be done once the bug is fixed
No engineering task expected. Testing required.
Issue 10: Combo Boxes in properties sheets
Description
Combo boxes in properties sheets are not keyboard accessible. Arrow keys
don't work, escape doesn't work, enter doesn't work.
Bug Tracking
NetBeans problem but appears to be fixed in 3.3.
Examples in the IDE
"Template" property on any filesystem node.
What needs to be done once the bug is fixed
No engineering task expected. Testing required.
Issue 11: Font with JTextArea must be hardcoded
today
Description
It is a NetBeans policy to never hard code any fonts. This way, if the
user needs to change fonts (like to make it bigger for easier reading)
all fonts will change to the new, user-configured setting. However, JTextAreas
use non-proportional fonts by default. So if no font is hard-coded, the
font that will appear is different from the font used elsewhere in the
same dialog box. Buttons, JLabels, etc. default to proportional fonts.
Bug Tracking
None known, but this appears to be fixed now (in 3.2 and later). However,
many hardcoded fonts remain.
Examples in the IDE
Wizard help text.
What needs to be done once the bug is fixed
Remove all hardcoded fonts. Test.
Issue 12: JTables do not respond to arrow keys
on sparc systems
Description
Cannot use non-numeric arrow keys to move around a JTable on Sparc.
Bug Tracking
JDK/Solaris bug 4178701.
Closed as Not a Bug.
Workaround
If the DtKeyBindings section of the CDE configuration file ${HOME}/.dt/en_US/dtwmrc,
binds the arrow keys then swing classes will not be able to use arrow
keys in a bug free manner. Commenting these bindings out makes the errors
disappear.
# Down root f.circle_down
# Up root f.circle_up > # Right root f.next_workspace
# Left root f.prev_workspace
With the key bindings commented out, JTables respond to the non-numeric
arrow keys.
Examples in the IDE
Any JTable.
What needs to be done once the bug is fixed
Remove workarounds.
Issue 13: Duplicate menu mnemonics don't work. Cannot
use mnemonics in context menus
Description
When the same mnemonic is used more than once in a menu, the user should
be able to access the second item with that mnemonic by typing the mnemonic
letter twice. However, there is a bug in the JDK which prevents this from
working. The second item is not accessible via the mnemonic.
This is especially a problem in context menus. Since these are so dynamic,
mnemonic clashes are very likely. Therefore, the IDE has avoided placing
any mnemonics in context menus.
Bug Tracking
IssueZilla 16150
JDK bug 4235456.
Closed as will not fixed. App designer is told to avoid assigning duplicate
mnemonics.
Filed new bug 4515762
Examples in the IDE
The main Tools menu, all context menus
What needs to be done once the bug is fixed
Add mnemonics to context menus. Note that our desired behavior not expected
to be implemented for JDK 1.4. No mnemonics should be added to context
menus for the forseeable future.
Document for user how to deal with mnemonic clashes
Issue 14: Can't make discontiguous selection in JLists
with the keyboard
Description
JList components don't let the user make a discontiguous selection using
the keyboard alone, even when this is allowed using the mouse.
Bug Tracking
JDK bug 4303294
Examples in the IDE
File->Open dialog box
Curiously, discontiguous selection with the keyboard does work in the
"Override Inherited Methods" panel of the new class wizard.
Use Control+arrow to move, Control+Space to select.
What needs to be done once the bug is fixed
No engineering fix expected, although there may be JDK API changes
Issue 15: Netbeans/Modules need way to move, resize, show/hide columns
in JTable
Description
Moving, resizing, sorting by, and showing and hiding columns in a JTable
do not have keyboard equivalents in Java Look and Feel. Developers must
implement some way to do this for each table. The Forte Developer teams
have solved this by creating menu items to do some of the functions.
Bug Tracking
None filed. May require a general Netbeans solution to be implemented,
or some guidelines to be written.
What needs to be done
Deliberate design and implementation of menu-driven controls for each
JTable or set of JTables.
Issue 16: JSplitpanes and Nested JSplitpanes
Description
Nested JSplitPanes are not easy to navigate around. Making the issue more
complex, some of the standard JLF keys used for this (F6 and F8) are used
for more common operations in the IDE. NetBeans has replaced F8 with Alt-F12.
Not sure about F6.
Bug Tracking
JDK bug 4514858
deals with the special problem of nested splitpanes.
May need an additional NetBeans bug to cover the F6 issue.
What needs to be done
Developer may need to deliberately unmap the F6/F8 key bindings.
Issue 17: JOptionPane not accessible
Description
JOptionPane has problems with accessible description and accessible name,
and not-focusable text. However, if NetBeans developers use NetBeans components,
there should be no problem. Use NetBeans NotifyDescriptor and DialogDescriptor.
If you must use JOptionPane or JFrame directly (not recommended) you may
have to work around these problems yourself. See the a11y FAQ for more
information.
Bug Tracking
JDK: 4515027
Issue 18: Top-level menu mnemonics cannot be reused on menu items
Description
Mnemonics used for menus cannot be reused for menu items anywhere in the
menu bar
Bug Tracking
JDK bug: 4213634
Fixed in 1.4 beta
Issue 19: Non-editable things swallow escape -- JTable
Description
Non-editable JTable cells empty swallow the Escape key, making it more
difficult for the keyboard user to access the Cancel button on a dialog
box.
Bug Tracking
no bug filed
What developers should do
This should be implemented as part of a custom cell renderer/editor, if
needed. Making it the default behavior for all tables is risky because
users could accidently cancel all edits in a dialog box if they are unsure
whether a cell is editable.
Issue 20: Context menus not accessible
Description
Context menus should open with Shift-F10, and be navigable by keyboard.
This doesn't work by default.
Bug Tracking
JDK issue: 4510358
Related NetBeans issues: 16150,
16188,
16959
Examples in IDE
Some workarounds are in place, but not everywhere, so behavior is inconsistent.
The explorer nodes in 3.2.1 work correctly. In the editor, the menu posts
but the arrow keys won't navigate. In other cases, the menu doesn't even
post.
Issue 21: JFileChooser has non-accessible components
Description
JFileChooser has components missing accessible names and descriptions
Bug Tracking
JDK issue: 4515031
|
