Expose the content of text inputs to assistive technologies - #12750
Open
DataTriny wants to merge 3 commits into
Open
Expose the content of text inputs to assistive technologies#12750DataTriny wants to merge 3 commits into
DataTriny wants to merge 3 commits into
Conversation
DataTriny
force-pushed
the
accesskit-text
branch
from
August 2, 2026 13:13
58bd874 to
5a9edb3
Compare
Adds an `accessibility-text` feature on `i-slint-core` that turns on parley's `accesskit` feature plus the `accesskit` crate dependency. Winit's existing `accessibility` feature propagates it.
Describes a `TextInput`'s content to an assistive technology per character rather than as one opaque value: `RendererSealed::visit_text_input_layout` lends the accessibility pass the very layout the renderer draws with, and `sharedparley::accessibility` turns it into AccessKit TextRun children, keeping `LayoutAccessibility` across passes so NodeIds survive an edit. A renderer with no parley layout to lend -- the software renderer with bitmap fonts, or with `SLINT_SOFTWARE_RENDERER_PARLEY_DISABLED` set -- reports so, and the value is still published; only the caret and selection go unreported, since a `TextSelection` names TextRun nodes that don't exist. ChangeLog: Exposed the content of text inputs to assistive technologies.
`decode_selection` resolves an incoming `SetTextSelection` against the layout, so its offsets index the text the input displays. `set-selection-offsets` indexes the text it holds. For a password field those are different strings: the mask character is three bytes in UTF-8 where the characters it stands in for are usually one, so selecting anything past the first character landed the anchor and cursor in the wrong place. Convert on the way out, the way `map_byte_offset_from_visual_text_to_actual_text` does for hit-testing.
DataTriny
force-pushed
the
accesskit-text
branch
from
August 2, 2026 14:22
5a9edb3 to
c176214
Compare
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.
Closes #2895
Allows assistive technologies to see the textual content of text inputs, navigate it, do hit testing, inspect the selection and manipulate it.
This will later need to be generalized to rich/styled text and Markdown content, but I feel like the current parley API is not flexible enough. I have filed linebender/parley#716 but I have no idea how it will turn out.
Part of AccessKit/accesskit#565