On Wed, 5 Jul 2023 13:06:05 GMT, Abhishek Kumar 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
On Wed, 5 Jul 2023 12:37:23 GMT, Alexey Ivanov 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 butto
On Wed, 5 Jul 2023 09:43:12 GMT, Abhishek Kumar wrote:
>>> And this seems to be the problem. The getAccessibleName method should be on
>>> JComboBox, or its editor, which should return the result of
>>> getAccessibleName of the renderer component.
>>
>> Since the a11y APIs are called upon the
On Wed, 5 Jul 2023 04:58:12 GMT, Abhishek Kumar wrote:
>>> But in case of JComboBox, a11y API invokes the `getAccessibleName` method
>>> for `AccessibleJButton` and that returns an empty string.
>>
>> And this seems to be the problem. The `getAccessibleName` method should be
>> on JComboBox, o
> The issue exist only for non-editable combobox and the root cause is
> accessible object is not created due to incorrect index returned from
> component class which results in no a11y API invoked.
>
> Proposed solution is to return the correct accessible child from
> getAccessibleChild method