On Wed, 5 Jul 2023 13:06:05 GMT, Abhishek Kumar <abhis...@openjdk.org> wrote:
> > This is weird. I expect the accessibility API is called on the JComboBox in > > both cases where it's editable or not. Could this be a bug? Should we fix > > it in a different way? > > AFAIK, I don't think that it is a bug because the arrow button in Aqua LAF is > an instance of AquaComboBoxButton. So, native side invoked a11y API based on > component. Similarly, For non-editable JComboBox, editor is an instance of > JTextField and a11y API invoked on NavigableTextAccessibility. That's the problem: *why* is it called on *the combo button* instead of the combo box itself? It doesn't look right. In case of editable `JComboBox`, it consists of two components: an editor and the button. I assume the implementation of accessible interfaces gets called on the first child of the combo box. It's about right for the editable component: the editor is the main component of the combo box. But it doesn't look right to me that the drop-down button is the main component of the combo box if it's non-editable. The combo box should handle the accessibility request itself in this case. It still uses the same renderer which can't be put into editable state. The renderer is never added into containment hierarchy. Or there could be a *dummy* editor which handles the accessibility. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1253096757
