* What led up to the situation? On Writer, when one works on a document with other people, anyone can add comments. Moreover, it's possible to enable the "changes log", to follow the changes. It results that when anyone adds, removes, dhanges something, the change is not done, but colorized differently. To do it, the user needs accept, but can refuse the change. * What exactly did you do (or not do) that was effective (or ineffective)? Orca reads the text, even removed, without mentioning its status. To read comments, we need the XML release to see <!-- tag. * What was the outcome of this action? Orca is unable to read the changes related to revision change log. * What outcome did you expect instead? Orca should say, while the focus is on a text, if it's added, removed, by which user. It should also speak the comments.
Setting to NEW.
Migrating Whiteboard tags to Keywords: (a11y -> accessibility)
I assume Orca is some kind of screen reader. So, is this a matter of Writer not properly "exposing" something to Orca? Or is it that Orca is trying to parse the rendered LibreOffice window and there's nothing screen-reader-specific in Writer?
(In reply to Eyal Rozenberg from comment #3) > I assume Orca is some kind of screen reader. Correct: https://gitlab.gnome.org/GNOME/orca/ > So, is this a matter of Writer not properly "exposing" something to Orca? Or > is it that Orca is trying to parse the rendered LibreOffice window and > there's nothing screen-reader-specific in Writer? The former. LibreOffice needs to expose information on the accessibility layer (AT-SPI2 for Linux) and then the screen reader needs to process that information. Most likely, changes in both, LO and Orca will be needed. I'm not aware of an existing spec of how exactly to expose that information, so that might be something that needs to be agreed on first (e.g. whether to expose information via object/text attributes, embedded objects,... on the a11y layer). See also tdf#96487.