JDK-4514331 : Non-editable JTextArea and similar should allow Tab to keyboard - accessibility
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.1
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2001-10-12
  • Updated: 2022-03-04
  • Resolved: 2002-04-27
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.
Other
1.4.1 hopperFixed
Related Reports
Relates :  
Relates :  
Description
JTextArea, JTextPane, etc. swallow the Tab key. This makes sense when editing
is allowed, but when the component is uneditable, it causes unneeded frustration and damages keyboard accessibility.

Forcing the user to type Control+Tab is needlessly complex.

This is a very easy fix:

myTextComponent = new javax.swing.JTextPane {
  //override this so tab is not swallowed by this component
  public boolean isManagingFocus() {
    return false;
  }
};

=========
Test case

--  TextTest.java
import java.awt.event.*;
import javax.swing.*;
import javax.swing.text.*;

public class TextTest {
    static JTextComponent ed;
    public static void main(String[] args) {
        JFrame f = new JFrame("test");
        f.setVisible(true);
        JDialog frame = new JDialog(f,"TextTest");
        JButton button = new JButton("west");
        frame.getContentPane().add(button,BorderLayout.WEST);
        button = new JButton("button");
        frame.getContentPane().add(button,BorderLayout.SOUTH);
        button.addActionListener(
                                 new ActionListener() {
                                     public void actionPerformed(ActionEvent ae) {
                                         System.out.println("button pressed "+ae);
                                         ed.setEditable(!ed.isEditable());
                                     }
                                 });
        frame.getRootPane().setDefaultButton(button);
        JTextComponent editor = new JTextArea("JTextArea");
        ed = editor;
        editor.setEditable(false);
        //editor.disable();
        frame.getContentPane().add(editor,BorderLayout.NORTH);
        editor = new JTextArea("JTextArea");
        editor.setEditable(false);
        //editor.disable();
        frame.getContentPane().add(editor,BorderLayout.CENTER);
        frame.pack();
        frame.setVisible(true);
    }
}
--

Steps to reproduce.
1. run TextTest
2. select textArea by mouse
4. press tab
5. focus should move to next component

###@###.### 2002-04-19

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper VERIFIED IN: hopper-beta
14-06-2004

SUGGESTED FIX The idea of the fix: * removing 'TAB' and 'SHIFT-TAB' from traversalKeysSet in case editor is editable * adding 'TAB' and 'SHIFT-TAB' to traversalKeysSet in case editor is non editable see attached webrev.zip for the details ------ attached updated webrev to the bug ###@###.### 2002-04-24
24-04-2002

EVALUATION Sounds like a good idea ###@###.### 2001-11-13 ========================== Giving a second thought, I do not think that it is such a good idea. What if user wants to select text in noneditable text component? I think that by default text component should be accessible using Tab no matter editable they or not. closing as 'will not fix' ###@###.### 2002-04-03 Let me clarify. Tab is not required for selecting text. It is only useful for typing text, which is not allowed in an uneditable text area. You can allow text selection and yet still not swallow the tab key. ###@###.### 2002-04-03
03-04-2002