Say what announces a focused accessibility child - #344
Open
rezabakhshilaktasaraei wants to merge 1 commit into
Open
Say what announces a focused accessibility child#344rezabakhshilaktasaraei wants to merge 1 commit into
rezabakhshilaktasaraei wants to merge 1 commit into
Conversation
The platform raises a focus event when a widget takes keyboard focus and resolves it through focusChild(), so a painted list that also announces its current child from focusInEvent has it read twice - write that down next to accessibilityChildFocused(), where the mistake is made. The one container SetFocus we do handle ourselves is not about announcing: a selection list keeps keyboard focus on its items, so focus has to reach the selected one for the arrow keys and the Tab-stop to work.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two comments, no behaviour change.
A widget taking keyboard focus raises a focus event which the platform resolves through focusChild(), so a painted list that also announces its current child from focusInEvent has it read twice. That is written down now next to accessibilityChildFocused(), which is where the mistake gets made - telegramdesktop/tdesktop#31169 removes five of those announcements.
The other comment was wrong: the container SetFocus we handle in Widget::doAction() is not a workaround for the bridge not redirecting focus. It is there because a selection list keeps keyboard focus on its items - they are real widgets handling the arrow keys and carrying the list's single Tab-stop - so focus has to reach the selected item rather than the container.