JDK-8258786 : Problem with JAWS accessible tool, if editable JComboBox is used
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.accessibility
  • Affected Version: 8u261
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • Submitted: 2020-12-21
  • Updated: 2021-01-15
  • Resolved: 2021-01-15
Related Reports
Duplicate :  
JDK-8249278 - Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList
Relates :  
JDK-8226253 - JAWS reports wrong number of radio buttons when buttons are hidden
Description
FULL PRODUCT VERSION :
JDK 8u261 b33

ADDITIONAL OS VERSION INFORMATION :
MS Windows 10 OS

A DESCRIPTION OF THE PROBLEM :
The screen reader software JAWS 2020.2006.50 calls a type of an editable "javax.swing.JComboBox" component as a type of a regular non-editable "JComboBox", what makes a user think that the component in focus is a regular "JComboBox" instead of an editable "JComboBox". Since the functionality of editable and non-editable "JComboBox" components is different, the user does know that they opportunity to type a text in the component and think that they can only select values. As a result the user is stuck during entering of the required data in the application. This issue was introduced in JDK 8u261 and is not reproducible with JDK 8u251.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Install 64-bit JAWS screen reader software.
2. Install 64-bit JRE to be tested and enable Java Access Bridge in this JRE by the next command:

"<JRE_HOME_DIR>\bin\jabswitch.exe -enable"

3. Copy the file "<JRE_HOME_DIR>\bin\WindowsAccessBridge-64.dll" to "C:\Windows\System32" directory.
4. Start the screen reader software JAWS.
5. Compile the attached test case "EditableCombobox.java" and run it with the tested JRE.
6. Listen carefully how JAWS screen reader calls the editable and non-editable "JComboBox" components in the window of the test case.
Comments
Closing the issue as a duplicate of JDK-8249278.
15-01-2021
Verified on MS Windows 10 OS with the screen reader software JAWS 2020.2012.13 using the attached test case that: - the issue is reproducible in JAWS; - the issue was indeed introduced in JDK 8u261 b01; - the issue indeed became resolved in JDK 8u271 b02 and stays not reproducible with JDK 8u271 b09. Transcriptions of phrases spoken by the screen reader JAWS during the experiments which demonstrate the issue are following: RESULTS SET 1: Phrases spoken by the screen reader with JDK 8u271 b09, JDK 8u271 b02, JDK 8u251 b08: For editable "JComboBox" - "edit combo closed, Cat 1 of 3, to set a value use the arrow keys or type the value" For non-editable "JComboBox" - "combo box closed, Cat 1 of 3, to change the selection use the arrow keys" RESULTS SET 2: Phrases spoken by the screen reader with JDK 8u271 b01, JDK 8u261 b12, JDK 8u261 b01: For editable "JComboBox" - "combo box open, Cat 1 of 3, to change the selection use the arrow keys" For non-editable "JComboBox" - "combo box closed, Cat 1 of 3, to change the selection use the arrow keys" Hence the specified above results confirm the specified in the previous comment assumption and let to conclude that this issue was caused by the fix JDK-8226253 and is already resolved starting from JDK 8u271 by the fix JDK-8249278.
15-01-2021
The test case "EditableCombobox.java" was attached to the issue. Using the test case and Java Monkey testing tool it was defined that in JDK 8u261 b01 the next behavior change was introduced. The change consists in the fact that starting from that build "javax.accessibility.AccessibleContext" instances of the accessible objects corresponding to both editable and non-editable combo boxes do not have popup menus in the accessible children of those accessible objects. This behavior change is caused by the fix for the bug JDK-8226253. It was practically proved that reversion of this fix from the source code of JDK 8u261 b12 eliminates this behavior change in JDK 8u261 b12. Perhaps the screen reader software JAWS became influenced by the described above behavior change which was introduced in JDK 8u261 b01 by the fix for JDK-8226253. However this fix caused a regression and was completely rolled back in JDK 8u271 b02 by the fix for JDK-8249278. Thus in JDK 8u271 the described above behavior is already returned to the state at which it was in JDK 8u251. Therefore it is necessary to check the issue in the screen reader JAWS, because it is possible that it may be already not reproducible with JDK 8u271.
15-01-2021