Description: After trying to export the file with the extension .doc a warning appears in the PDF/UA when accessibility issues are detected. Clicking on the "Investigate issues" button opens the "Accessibility check" panel. When trying to correct errors in the absence of alternative text, some of them do not disappear. Consequently, accessibility issues cannot be resolved. The problem seems to be that the pictures in the attached file with the ".doc" extension do not contain a name. When image with some name using here, then problem is not reproduced Steps to Reproduce: 1. Open the attached document 2. Export to PDF/UA 3. Click on "Investigate issues" 4. Fix accessibility issues Actual Results: Not all accessibility issues are fixed. Expected Results: All accessibility issues are fixed. Reproducible: Always User Profile Reset: No Additional Info: Repro on: Version: 25.8.0.0.alpha1 (X86_64) / LibreOffice Community Build ID: a2896e060b54ce6ce36e3e29218fac40d2919c74 CPU threads: 12; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+xcb) Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: CL threaded Also repro at least on: Version: 7.6.0.0.alpha1 (X86_64) / LibreOffice Community Build ID: 9366f83c88fc93d40ea0c0035508f24ad5dcb144 CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: CL threaded
Created attachment 201157 [details] Export Settings
Created attachment 201159 [details] Problematic document Enough to reproduce
Also, this reproducing without export, if open the "Accessibility check" tab and try to fix accessibility issues. This is most likely already the task of importing .doc.
Michael, could you please write here your opinion about the problem? Thanks
It is very hard to pass over "Missing alternative and description text". All the others are solved quickly. Maybe the length expected for these fields is too long.
(In reply to Roman Kuznetsov from comment #4) > Michael, could you please write here your opinion about the problem? Thanks At first glance, it looks to me as if clicking any of the "Fix" buttons for the "Missing alternative or description text" issues in the Accessibility Check sidebar always opens the "Alt Text" dialog for the second graphic/line, while one of them should presumably select the first line and open the dialog for that one. If I manually select the first line, open the context menu, select the "Alt Text" context menu entry and enter something for both, "Text" and "Alt Text", the accessibility check warning disappears after a while (e.g. after resaving). Does that describe the issue you're encountering?
(In reply to Michael Weghorn from comment #6) > (In reply to Roman Kuznetsov from comment #4) > > Michael, could you please write here your opinion about the problem? Thanks > > At first glance, it looks to me as if clicking any of the "Fix" buttons for > the "Missing alternative or description text" issues in the Accessibility > Check sidebar always opens the "Alt Text" dialog for the second > graphic/line, while one of them should presumably select the first line and > open the dialog for that one. > > If I manually select the first line, open the context menu, select the "Alt > Text" context menu entry and enter something for both, "Text" and "Alt > Text", the accessibility check warning disappears after a while (e.g. after > resaving). > > Does that describe the issue you're encountering? Hi Michael, For me it looks like the accesibility sidebar and also the navigator bar do not like if we have the same name for an object. In case of this example doc we have two shape without any unique name (which in general should not happen, not at import or runtime). For example when we are trying to rename an object to a same name which is already exists e.g rename "Shape 1"
It looks like the other half of the comment just disappeared... :D > For me it looks like the accesibility sidebar and also the navigator bar do > not like if we have the same name for an object. In case of this example doc > we have two shape without any unique name (which in general should not > happen, not at import or runtime). For example when we are trying to rename > an object to a same name which is already exists e.g rename "Shape 1" to "Shape 2" but we already have a "Shape 2" object, then the original one will not be possible to set back to "Shape 1" name. I can see two issue here, first the doc import where we should not allow the same name for different objects (i think we doing something similar at docx import), the second one, if we would still have somehow objects with the same name, we should do not show those duplicated a11y issues on the a11y sidebar.
(In reply to Balázs Varga (allotropia) from comment #8) > > For me it looks like the accesibility sidebar and also the navigator bar do > > not like if we have the same name for an object. In case of this example doc > > we have two shape without any unique name (which in general should not > > happen, not at import or runtime). For example when we are trying to rename > > an object to a same name which is already exists e.g rename "Shape 1" > > to "Shape 2" but we already have a "Shape 2" object, then the original one > will not be possible to set back to "Shape 1" name. Good catch, I hadn't noticed that. > I can see two issue here, first the doc import where we should not allow the > same name for different objects (i think we doing something similar at docx > import the second one, if we would still have somehow objects with the > same name, we should do not show those duplicated a11y issues on the a11y > sidebar. 1) definitely sounds plausible to me. When I save the unmodified .doc as .odt and reopen, those objects also get different names and the problem doesn't occur.