Item view item data for various roles are relevant for the properties and states reported for the corresponding accessible objects on the accessibility layer, see the a11y implementation in QAccessibleTableCell. Therefore, changes to the relevant role data should also be reported as corresponding state/property changes on the a11y layer. Implement sending corresponding accessibility events from QAbstractItemView::dataChanged. While the roles param in the QAbstractItemModel::dataChanged signal that this slot is connected to is optional, only handle roles that are explicitly passed for now, which covers the case of interactively modifying items. Properly handling the case of an empty list of roles indicating that all roles should be considered as (potentially) having been modified would require to keep track of previous values to be able to only send notifications about those that actually changed. (One way to do that for the current item could be to remember the values in QAbstractItemView::currentChanged and then compare whether those have changed in the meantime.) Always sending accessibility events even if no change actually occured would be incorrect and could e.g. result in confusing/misleading screen reader announcements. For now, in order to avoid potential negative performance implications when doing that for all items, restrict this to the case where (only) the current item's data has changed, which in particular covers the case where a user interactively modifies that item. (If the need arises, this can be further extended as needed in the future.) This e.g. makes the Orca screen reader on Linux announce changes to the checkbox state for the QTBUG-141856 sample program when toggling it using the space key, and results in the state getting updated as expected in Accerciser [1]. The accessible name shown in Accerciser also gets updated as expected when modifying an item's text, and Orca announces the new name. [1] https://gitlab.gnome.org/GNOME/accerciser Task-number: QTBUG-141856 Change-Id: Ic1592f4c639c29ab4144ae8b768f26c63f8878dc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>