JDK-8226253 : JAWS reports wrong number of radio buttons when buttons are hidden
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.accessibility
  • Affected Version: 8u40,11,12,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-06-17
  • Updated: 2022-06-27
  • Resolved: 2020-03-16
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 11 JDK 13 JDK 15 JDK 8 Other
11.0.8-oracleFixed 13.0.4Fixed 15 b16Fixed 8u261Fixed openjdk8u262Fixed
Related Reports
Relates :  
JDK-8258786 - Problem with JAWS accessible tool, if editable JComboBox is used
Relates :  
JDK-8249278 - Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList
Description
JAWS screen reader reports radio buttons.. ie. 1 of 2.   
But it isn't ignoring invisible menu items. 

When a radio button is selected, it states 
    "Radio button unchecked, 1 of 2" 

However, if there is 2 visible radio buttons and 
    one invisible, it is reporting "1 of 3" 

Screen readers should ignore hidden radio buttons, 
   just as they are ignored by sighted users. 

Using java 1.8.0_211, Windows 7 64 bit, with JAWS 2019.1906.10 ILM
Comments
Fix request (13u) Requesting backport to 13u for parity with 11u, applies cleanly.
04-06-2020
As this patch did not apply cleanly (due to the copyright change you mention), this should really have gone out to review before making a fix request. I've reviewed it in sponsoring the patch, and the change is trivial, but please follow the correct process in future.
02-04-2020
Fix Request (8u) Backport to 8u requested because it is a part of 8u261-oracle. Backport applies cleanly after changing paths and copyright years. Exported 8u changeset with original attribution: http://cr.openjdk.java.net/~akasko/jdk8u/8226253/8226253_8u.patch Tested it with JAWS and a manual testcase from this email: https://mail.openjdk.java.net/pipermail/awt-dev/2020-March/015752.html
31-03-2020
I am working on 8u backport and also tested 11u version (works fine, +1 to the 11u backport). Will add 8u fix request once 11u is pushed.
27-03-2020
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.8-oracle. Applies clean except for Copyright.
27-03-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/3ea8a0c5c264 User: psadhukhan Date: 2020-03-22 11:49:29 +0000
22-03-2020
URL: https://hg.openjdk.java.net/jdk/client/rev/3ea8a0c5c264 User: arapte Date: 2020-03-14 19:14:40 +0000
18-03-2020
URL: http://hg.openjdk.java.net/jdk/client/rev/3ea8a0c5c264 User: arapte Date: Sun, 15 Mar 2020
16-03-2020
Fix is on review
06-03-2020
The fix suggested in http://cr.openjdk.java.net/~arapte/a11y/8226253/webrev.01/ causes a regression. The fix depends on AccessibleState.SHOWING to identify if a component is shown on screen or not. If a component is not AccessibleState.SHOWING then it will not be considered in children count or to access the component. In case of ComboBox, Consider a scenario where an item of ComboBox is not currently visible on screen but it can become visible on up/down key press. This item will not be read after the suggested fix. This seems to be more important regression than the issue reported in this bug. Currently AccessibleState has no state to identify the ComboBox scenario. We might have to introduce a new AccessibleState to identify the ComboBox scenario and then update this fix. Deferring this issue to 15 for now.
05-12-2019
Found an important regression from the webrev.01 fix: JAWS fails to read a ComboBox item which is not shown on screen but will be shown and selected on pressing up or down key. Working to solve the regression: Current AccessibleStateSet does not have any property to identify this scenario of ComboBox item.
11-11-2019
Fix Webrev: http://cr.openjdk.java.net/~arapte/a11y/8226253/webrev.01/ Issue: AccessibleContext.getAccessibleChildrenCount() returns number of all Accessible children, but does not take visibility of a child component in consideration. Fix: Do not consider children that are not showing when providing accessible children count and when providing an accessible child of the component to screen reader. This change is needed for both AccessibleContext and AccessibleRelationSet. The newly added methods do not result in creating the AccessibleContext of children components earlier than before the fix. The AccessibleContext gets created in AccessibilityEventMonitor.AccessibilityEventListener.installListeners(AccessibleContext) method, which occurs before the newly added methods get executed. Verification: Tested the fix with JList with a custom AccessibleContext(custom ListModel) to hide non visible components, JRadioButton, JCheckBox, JToggleButton, JRadioButtonMenuItem, JCheckBoxMenuItem, JComboBox and SwingSet2. Did not find any misbehavior with the fix. Some pointers provided by Sergey in offline discussion: 1. Fix the issue on Java Access Bridge side. => http://cr.openjdk.java.net/~arapte/a11y/8226253/webrev.01/ 2. Confirm that the fix does not create the AccessibleContext of children earlier than before the fix. => Does not happen 3. Test JList with a custom AccessibleContext. => Tested by adding a custom ListModel to JList. JList.AccessibleJList uses the ListModel for getAccessibleChildrenCount() and getAccessibleChild()
10-09-2019
[~arapte] is it ready for review or still in progress and too early for review?
06-09-2019
Fix to review: http://cr.openjdk.java.net/~arapte/a11y/8226253/webrev.01/
29-08-2019
Does it affect 11? 13?
19-06-2019