On Tue, 25 Jul 2023 12:04:44 GMT, Abhishek Kumar <abhis...@openjdk.org> wrote:
>> That's exactly my concern: in other L&Fs `AccessibleJComboBox` handles the >> scenario yet in Aqua L&F it is handled by a different component which is not >> a problem okay per se. What is a problem is that retrieving the accessible >> name depends on paint: >> * if `AquaComboBoxButton.paint` hasn't been called for whatever reason, >> there's no accessible name; >> * if the value in the combo box is changed, the accessible name isn't >> updated until paint occurs. > >> That's exactly my concern: in other L&Fs `AccessibleJComboBox` handles the >> scenario yet in Aqua L&F it is handled by a different component which is not >> a problem okay per se. What is a problem is that retrieving the accessible >> name depends on paint: >> >> * if `AquaComboBoxButton.paint` hasn't been called for whatever reason, >> there's no accessible name; >> >> * if the value in the combo box is changed, the accessible name isn't >> updated until paint occurs. > > I rechecked again but couldn't find any other way to either set accessible > name or get the current selected item other than `AquaComboBoxButton.paint`. >But for aqua, the accessible component invoked for screen magnifier is an >instance for AquaComboBoxButton, so >it is required to return the accessible >button instance for a11y APIs to get called for retrieving accessible name. Can we inject some code into the AquaComboBoxButton so it will know what name should be used if that button is used "inside" combobox? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1287926418
