No longer set focused state for accessibility for non focused WX list items

[lukaszgo1]

Opened against beta, since this PR fixes a regression from 2024.1 development cycle.

Link to issue number:

Fixes #16280

Summary of the issue:

For not fully accessible WX checkable list boxes / list views, NVDA implements custom wx.Accessible class, which exposes proper roles / states. Since WX list boxes have no method to determine if the given item is focused, it was assumed that selected item is always focused. This is not true when the list box itself has no focus. For a long time this was causing only a minor annoyance - when using object navigation to access the not focused list selected item was reported as having focus. With the introduction of tcheckable list into speech settings panel, this is causing the list of available speech modes to receive focus when user changes the synthesizer. It seems that when the controls are re-created Windows notices that the first list item has a focused state, checks that it has no focus and emits a focus event to "correct" this. As to why this is not a problem when creating this panel I guess that controls are created when it is hidden, and focus events are not emitted for non visible windows.

Description of user facing changes

• Selected checkable list items are no longer reported as focused unless they really have focus
• When changing synthesizer from the speech settings panel list of available speech modes no longer gains accessibility focus

Description of development approach

Focused state is exposed for selected list box item only when the list box itself is focused. I have tried to use Win32 API to retrieve the real focused items from these controls using LB_GETCARETINDEX for the list box and LVM_GETITEMSTATE for the checkable multi columns list, unfortunately these approaches seem to return index of last focused item even when the parent list no longer has focus.

Testing strategy:

Ensured that for checkable list focused state is exposed only when the list has focus. Verified that after changing the synthesizer from the speech panel focus returns to the 'change' button, or to the edit field with the synthesizer name.

Known issues with pull request:

The speech settings panel behaves incorrectly when user is focused on one of the synthesizer controls such as the rate slider and invokes the change synthesizer dialog - in that case after the new synth is selected focus lands in the list of available speech modes list. This is not new behavior - in 2023.3 focus landed in limbo in this case.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[HanaDadfar]

@lukaszgo1 really thanks so much for your work. I confurm this pr fixes the problem that I reported, as expected.
I tryed all possible cases which this problem was exist, and now it's like 2023.4 again. Thanks again!

[lukaszgo1]

@michaelDCurran @seanbudd Can this be added to 2024.1 milestone for tracking purposes?

[seanbudd]

Thanks @lukaszgo1