JDK-4512626 : Non-editable JTextArea provides no visual indication of keyboard focus
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.0,1.3.1,1.4.0,5.0,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2001-10-09
  • Updated: 2024-11-25
  • Resolved: 2022-12-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 20 JDK 21
20 b29Fixed 21Fixed
Related Reports
Duplicate :  
JDK-4703291 - NON-EDITABLE TEXT FIELDS SHOULD SHOW CARET
Duplicate :  
JDK-4514256 - When using Java Help system the arrow keys respond slowly
Duplicate :  
JDK-6322745 - No focus indicator in non-editable JSpinner
Duplicate :  
JDK-5100939 - JNLP Descriptor window Horizontal and Vertical scrollbar is not working as expec
Duplicate :  
JDK-4991606 - Non-editable text fields should show caret
Relates :  
JDK-8299123 - [BACKOUT] 4512626 Non-editable JTextArea provides no visual indication of keyboard focus
Relates :  
JDK-8298602 - Provide a way to specify text caret based on the text component state
Relates :  
JDK-8333846 - Non-editable JEditorPane displays caret
Relates :  
JDK-8299077 - [REDO] JDK-4512626 Non-editable JTextArea provides no visual indication of keyboard focus
Description
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.


###@###.### 2001-10-12
Note that this affects uneditable JTextFields as well, and possibly other components.
Comments copied from http://bugs.openjdk.java.net/show_bug.cgi?id=100229

Description From Dietmar Hechensteiner 2012-02-21 05:49:23 PDT

Created an attachment (id=257) [details]
Patch against openjdk7/jdk

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4512626

Summary:
Non-editable text components do not have any visual indication of keyboard
focus. This makes it impossible for users to know where the focus has gone. 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.

Description of the change:
Instead of binding the caret visibility to "enabled && editable" only "enabled"
was choosen, as it provides a visual indication of the focus.

Comment #1 From Tim Bell 2012-07-11 15:40:00 PDT

Closing.  This is SUNBUG 4512626.  The information here will be transferred to
that report.
Comments
This fix was backed out using: JDK-8299123 [BACKOUT] 4512626 Non-editable JTextArea provides no visual indication of keyboard focus
20-12-2022
Changeset: 3e17e3c1 Author: Alexander Zuev <kizune@openjdk.org> Date: 2022-12-19 22:16:56 +0000 URL: https://git.openjdk.org/jdk20/commit/3e17e3c1c12d71461213bf15cdb72d4d93c88460
19-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk20/pull/21 Date: 2022-12-12 22:33:51 +0000
12-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11408 Date: 2022-11-29 07:30:32 +0000
29-11-2022
he unfocused non-editable JTextArea can not be distinguished from the focused one. In addition the cared while being invisible remain functional - one can use it with the arrow keys or mouse and use appropriate shortcuts to select text around the caret. So not only it violates the a11y rules by not displaying the focus status in any way but also an inconvenient related to the selecting text and using arrow keys to scroll text within the scroll area - without having the visual clue on the caret position it is unclear when text will start scrolling instead of moving the invisible caret to the corresponding border of the text area. The proposed fix is to make caret visible but non-blinking, indicating by that that the editing is not possible. The blink rate is to be preserved in case of the custom blink rate on the component that has its editable state changed in runtime.
29-11-2022
Some thoughts on the above commentary: - In some cases static text, i.e. JLabel, should be used by the application developer, not a non-editable text field or text area. Screen readers have means to read static text. Static text does not need to be focusable. - One valid scenario is when the text area/field can change state (read only vs editable) depending on other controls. In this case then the proper solution would be to have a focus highlight around the control and a flashing caret (and the ability to use the keyboard to select and copy text).
31-05-2016
SUGGESTED FIX See attached patch from OpenJDK bugzilla.
23-07-2012
EVALUATION Also affects JSpinner - see bug 6322745.
12-09-2005
EVALUATION 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.
03-08-2005
EVALUATION 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"
28-07-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
30-09-2004
EVALUATION 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. ###@###.### 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. ###@###.### 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. ###@###.### 2001-10-16 The fix described above will require API change and will have to wait until Tiger. ###@###.### 2002-03-01 Name: anR10225 Date: 02/27/2004 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. ======================================================================
30-09-2004
WORK AROUND 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. ###@###.### 2001-10-16
16-10-2001