https://bugs.documentfoundation.org/show_bug.cgi?id=149013
--- Comment #15 from Michael Weghorn <[email protected]> --- (In reply to sdc.blanco from comment #9) > (In reply to Michael Weghorn from comment #8) > > I think that it can also be helpful when using LO itself get a text > > description, just the same as it can be used with HTML or PDF. > iiuc, you imagine that hovering the mouse over an object would show the > "Alternative Text" and/or "Description"? (sounds good!) > How would you display the data if both fields are used? I didn't think of any specific way on how to show this to the user. It was more a general "That information is available, so can be accessed, e.g. by people with screen readers". What would be the best way to represent this would be a separate question (and IMHO a bit out of the scope of this ticket, which is about HTML export). The obvious way that would already work by now (but is complicated) is by opening the dialog where the description can be edited and move the cursor to that field to have the screen reader speak the text. One thought was that ideally, there would be some way to expose this via existing attributes/methods in the corresponding a11y interfaces for the different platforms, and could then e.g. be queried by the screen reader on demand, like e.g. Orca's "What's this" functionality (s. https://help.gnome.org/users/orca/stable/howto_whereami.html.en) that queries different information depending on what kind of object is selected. Update: While looking into what the NVDA commit mentioned by Christophe does, his comment 14 came in... (In reply to Christophe Strobbe from comment #14) > IAccessible2 is a platform-independent Accessibility API (unlike Gnome's > ATK/AT-SPI, MS Windows's UI Automation and Apple's accessibility APIs). The > NVDA issue I referenced in my previous comment (see > https://github.com/nvaccess/nvda/issues/809 ) contains a link to a commit at > https://github.com/nvaccess/nvda/commit/ > 0ac840a8a14ebe18f25b7392d13077b8391f97e8 that uses IAccessible2 to query the > browser for the presence of a long description. More specifically, it uses > the IAccessibleAction Interface documented at > https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/ > interface_i_accessible_action.html . > I imagine LibreOffice would do something similar. That's really helpful, thanks a lot! I didn't test it, but reading the IAccessibleAction interface doc, the interesting question would then probably be what to do if the "long_description" action (or whatever it's called) is performed. From initial reading, IAccessibleAction doesn't seem to be meant to be used to just get a textual representation of something in the first place, but to execute some action. I could imagine that Firefox e.g. opens the corresponding page linked there, but I haven't actually tried. There is IAccessibleAction::description (s. https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_action.html#a7c8d49908df62d2ca14794b7ee2977d5 ), but that's rather meant to return a description of what *the action does*, so *I think* it wouldn't just return the text set as description for the image. (?) (In reply to sdc.blanco from comment #10) > Notice the mention about screen reader software and accessibility tools. Two > questions. > > 1. Should the help page mention these topics at all? (I am assuming "yes"). > > 2. But if yes, then presumably there are some standards (e.g., alt tag) > that are used to support screen readers and other tools. But I get the > impression (from the links that Christophe has sent) that "description" is > not so standardized. So maybe it is necessary to simply explain clearly > what gets exported to PDF and HTML (are there other exports?) -- without > making these generic/vague claims about screen reader software, etc. Maybe > something like: > > Whether the Description tag is used by other software depends on the > software's implementation. As Christophe mentions, I think it makes sense to have a description independent of potential export formats and I like Christophe's suggestion from comment 12 for the descriptions of the meaning. For ODF itself, the corresponding attribute is "svg:desc", described as: "The <svg:desc> element specifies a prose description of a graphic object that may be used to support accessibility. See appendix D." ( https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1415840_253892949 ) Back to HTML export: @Christophe: Comment 11 and comment 12 are very helpful, thanks! But to be honest, after reading those, I don't know what would be a proper way of handling "Description" on HTML export. Any suggestion? (In reply to Christophe Strobbe from comment #11) > The longdesc attribute has a long history of being rather poorly supported > by screen readers and has been removed from HTML5, so that is not a good > solution. That seems to rule out "longdesc", which otherwise looks like it would be quite equivalent from a semantic perspective. (In reply to Christophe Strobbe from comment #11) > A caption is no replacement for a text alternative or a long description, > since the caption is also presented to sighted users and can be used in LO > to generated a "Table of Figures" for the entire document. As I understand it, "the caption is also presented to sighted users" also applies for the "figcaption" in HTML, so exporting the description to that would generate visible output in the HTML page. My general expectation would be that the description would generally not be visible in an exported document by default, since it isn't visible in Writer either. So, with my limited background knowledge, that doesn't really sound like a perfect match either. Reading https://www.w3.org/WAI/tutorials/images/complex/ more or less gives me the impression that using an image caption instead of the "Description" would maybe be a better way to create accessible documents that are meant to be exported to HTML in the first place... > Until version 2016, MS Word had two separate fields: Title and Description. > Since Word 2019, there is only the Alt Text field. Regarding the described situation, merging "Alternative (Text only)" and "Description" and put the resulting text into the "alt" attribute on HTML export also sounds like a somewhat interesting idea, but also far from perfect. It would fulfill the expectation that the text is not visible by default, but more of a "tag"/annotation for the image. However, having all of the text in the "alt" attribute also doesn't really sound great, since it's meant to be used for a short summary only... I really don't know what the best solution here would be. I can think of reasons to argue for any of these: 1) It already "works as designed": Since there is no real equivalent for the image description in HTML (other than "longdesc", which is obsolete and wasn't properly supported by screen readers anyway), not exporting it is "correct". If something should show up as a caption in HTML, it should be added as such in Writer. 2) Use "figcaption" in some way. (How?) https://www.w3.org/WAI/tutorials/images/complex/ describes it as a way for providing long descriptions. 3) on HTML export, merge "Alternative (Text only)" and "Description" into the "alt" attribute, since that is meant to be used to provide an alternative description. > I wanted to show that there are many techniques for long descriptions in > HTML instead of just one "canonical" one, so if you want to use LibO as an > HTML editor, you will at some point encounter a method that is not supported > by LibO. That would be different if LibO only exported HTML, just like it > only exports PDF without enabling PDF editing as such. That's an additional aspect. Since this ticket is about HTML export, that was what my comments were referring to. -- You are receiving this mail because: You are the assignee for the bug.
