[qt/qt/qtbase]: Summary of bulk changes made

Git repository change summary for qt/qt/qtbase
Pushed by mirror-service into branch '6.11'.
Changed from 3b8988dd0cd5474b3dca50bf3969d53951639920 to 4d4ab82cde1897910bb72fe9a2971f290a05ed9a
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit 4d4ab82cde1897910bb72fe9a2971f290a05ed9a by Qt Cherry-pick Bot (on behalf of Jeff Heller) on 17/07/2026 at 05:00..
Android a11y: announce text edits so screen readers echo typing

With a screen reader enabled, typing or deleting characters in a Qt text
field produced no spoken feedback, and the field's label was not announced
— making edit controls very hard to use.

Several gaps caused this:

- Qt Quick text items emit a QAccessible text-change event only from the
  programmatic setText() path, never from input-method or key-event edits,
  so nothing reached the Android accessibility bridge while typing.
  Generate the events at the platform chokepoints instead:
  QAndroidInputContext::endBatchEdit() announces IME edits (with mid-batch
  changes deferred via a pending flag so unmarked mutations such as
  finishComposingText()'s commit are covered), and update() announces edits
  that bypass the IME entirely (KEYCODE_DEL backspace, hardware keys,
  programmatic changes). The changed span is a prefix/suffix diff of the
  field text, kept on code-point boundaries. Announcing only from these
  chokepoints (not also from the QAccessible::TextInserted/Removed/Updated
  path) avoids double-announcing programmatic changes, which update()
  reports too.

- QtAccessibilityDelegate.notifyTextChanged() fires the two events a real
  editable view fires on each keystroke, sourced from the input-focused
  node: TYPE_VIEW_TEXT_CHANGED (what changed) and a companion
  TYPE_VIEW_TEXT_SELECTION_CHANGED (the new caret position). The selection
  event matters because a screen reader echoes typing from the input-focused
  editable; the text-changed event alone is not honored when accessibility
  focus is on the soft keyboard rather than the field.

- Editable nodes exposed their content only via setContentDescription().
  A screen reader reads an editable's text to track the caret and echo
  edits, and reads its label from the hint; with neither set the field was
  treated as empty and unlabeled. populateNode() now also sets text,
  inputType (TYPE_CLASS_TEXT) and hintText (the accessible name) for
  editable nodes.

Confirmed on a Samsung Galaxy Tab A9 (Android 16) by a blind user: with the
single text-changed event, a screen-reader update stopped speaking it during
typing (its source is not the accessibility-focused node while the keyboard
is open); adding the caret/selection companion — matching how a standard
editable view drives typing echo — restored spoken feedback for typing and
deletion.

Task-number: QTBUG-118858
Change-Id: I51589fc3891b7c42fcfbf0163545fad3666ac3dc
Reviewed-by: Oliver Eftevaag <[email protected]>
(cherry picked from commit 66acbeda7c59cf05cd300a4a36cd748c74fb78fe)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
(cherry picked from commit 505853d02184a35a5c3bd4f7e810b04c3a81da1c)
https://invent.kde.org/qt/qt/qtbase/-/commit/4d4ab82cde1897910bb72fe9a2971f290a05ed9a