Non-editable JTextAreas do not have any visual indication of keyboard focus. This makes it impossible for users to know where the focus has gone. This is particular problematic for keyboard-only users, because the JTextArea swallows Tab and Return. The user must know the focus is on this component in order to figure out they Control-Tab is needed to move out of the component.

This problem violoates the section 508 accessibility guideslines (the first half of the quote below):

"A well-defined on-screen indication of the
  current focus shall be provided that moves
  among interactive interface elements as the
  input focus changes. The focus shall be
  programmatically exposed so that assistive
  technology can track focus and focus
  changes."

Non-editable JTextAreas are often used for instruction text at the top of a dialog box or wizard page. A non-focusable JTextArea could be used instead, but this makes the instruction text unfocusable for screen readers as well. This setup would violate the second part of the 508 rule as quoted above.


  xxxxx@xxxxx   2001-10-12
Note that this affects uneditable JTextFields as well, and possibly other components.

There are multiple work arounds available depending on the route one chooses to take. To show a flashing caret in the component when it has focus, simply add a focus listener to the component to set the caret to visible on focusGained(). This is exactly what DefaultCaret does except that it currently only does so when isEditable() is true.

To take the other approach, which is to paint some type of rectangle around the component, one could extend the component or provide a custom UI class that paints the component differently if it has focus. This is the benefit of pluggable look and feel.
  xxxxx@xxxxx   2001-10-16

This does not fit the merlin show-stopper criteria and is therefore being downgraded in priority. I am also changing it to an RFE because I think we'll need to invent a way to show focus on a non-editable text component.
  xxxxx@xxxxx   2001-10-11

I now beleive the correct way to show focus on a non-editable text component is to show the flashing caret. This will both give a visual indication of focus and allow the user to select text via the keyboard. I am now restoring the priority, changing back to a bug, and attempting to fit this fix into merlin.
  xxxxx@xxxxx   2001-10-15

There are multiple changes that can be made to address this problem. The first suggestion is to draw some type of rectangle within the bounds of the component to give an indication of focus. A couple of things should be said about such a fix. One, it can only be made in the Metal look and feel since the others must match their associated platforms. Two, if it is to be done, it should be done for all JTextComponents. The complication is that some of these components, such as JTextArea, JTextPane, and JEditorPane, exist most of the time inside a JScrollPane. This prevents us from simply adding a custom border around the component itself. It would somehow need to install such a border on the surrounding scrollpane. Whatever the solution, there is no time to put such a change into merlin. This type of change will have to be re-investigated, with input of the User Experience Team, for a later release.

Another partial solution has been investigated for this problem. The fix is to show a flashing caret whenever a JTextComponent has focus. This brings with it multiple benefits. First, it allows all users to move around and select text within a component, editable or not. Second, it gives some type of indication of focus. Some have suggested that a flashing caret in a non-editable text component is misleading. It may be so, but it IS a technique used by Motif and Windows. Unfortunately, we've determined that such a change brings with it complications. JEditorPane is a JTextComponent often used to display HTML in a browser-like way. JavaHelp for instance uses it in this manner. If we were to make this change, all applications that use non-editable JEditorPanes would suddenly have a flashing caret. Such a side effect might be okay if we could provide a mechanism to turn off the caret. Unfortunately, this would require an API change. As a result of this discovery, we've decided that we cannot make this change until a later release.

We have decided that we are unable to provide a good solution for this problem for merlin. This bug should stay open and will be addressed when possible, but for now it must be downgraded in priority per merlin criteria.
  xxxxx@xxxxx   2001-10-16

The fix described above will require API change and will have to wait until Tiger.
  xxxxx@xxxxx   2002-03-01




    Currently the focus traversing behavior of the uneditable text
area is fixed. I.e. pressing Tab is not consumed by the focused
uneditable text area.
    MS Windows indicates the focus of uneditable text component by
displaying a flashing caret. We could make the same thing with
JTextField, JPasswordField, JFormattedTextField and JTextArea.
For Windows LAF we could make this without API changes just by
overriding createCaret() in corresponding UI classes.
    The same thing we could made with Metal LAF by the same way.
Here we may also make the caret visible in uneditable components
but non-flashing.



======================================================================
I am not sure we need to provide such indication by default.
If such indication is needed developer might set caret to visible for example:
textComponent.getCaret().setVisible(true);

closing as "will not fix"
Posted Date : 2005-07-28 15:22:11.0

While showing a caret may not be the solution (although I strongly believe it is after considering other native platforms - it's needed to enable copying text) this remains an accessibility issue that needs to be addressed. Re-opening.
Posted Date : 2005-08-03 14:15:58.0

Also affects JSpinner - see bug 6322745.
Posted Date : 2005-09-12 18:22:03.0