[Libreoffice-ux-advise] [Bug 149013] Description of images, OLE objects and shapes is not exported to HTML

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=149013

--- Comment #11 from Christophe Strobbe <c_strobbe-fdo at yahoo.co.uk> ---
(In reply to Michael Weghorn from comment #7)
> (In reply to Christophe Strobbe from comment #1)
> > The "Title" matches the alt attribute for images in HTML.
> > The "Description" would match the "long description" for images in HTML and
> > there are various ways of doing this in HTML. The Web Accessibility
> > Initiative's tutorial on complex images describes a few ways of doing this:
> > https://www.w3.org/WAI/tutorials/images/complex/ .
> 
> Thanks, that's very informative.
> What about just setting the description in the "longdesc" attribute using a
> "data:" URI, like this example from
> https://www.w3schools.com/tags/att_img_longdesc.asp ?

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.
(Please note that W3Schools is not related to the W3C and that their tutorials
have no higher authority than anybody else's.)

> 
> > <!-- The description is included in a data:URI -->
> > <img src="w3html.gif" alt="W3Schools.com" width="100" height="132" longdesc="data:text/html;charset=utf-8;,%3C!DOCTYPE%20html%3E%3Chtml%3E%3Chead%3E%3Ctitle%3EDescription%20of%20the%20Logo%3C/title%3E%3C/head%3E%3Cbody%3E%3Cp%3ESome%20description%20goes%20here%3C/body%3E%3C/html%3E">
> 
> Not having much experience with either HTML or a11y, that looks to me like
> it might be a rather straightforward way. 

Longdesc had fairly poor support in browsers and screen readers when used
correctly (using a regular URL or URL fragment). I have never seen the data:URI
version in the wild, nor tested it.

> 
> > A technique not described in the above tutorial is using the details and
> > summary elements inside the figcaption element below the image (img and
> > figcaption being both wrapped in the figure element), so the long
> > description is available through a disclosure widgets. This works both for
> > screen reader users and other keyboard users. (An example in German can be
> > found at
> > https://digitalisierung.hdm-stuttgart.de/barrierefreiheit/gesetze-und-
> > richtlinien/ .)
> 
> LO provides the possibility to insert a caption to the image (right click ->
> "Insert Caption"), which seems to be what "figcaption" is for semantically
> in the first place (at a quick glance, but I'm not very experienced with
> either HTML or a11y) so I'm wondering whether using "figcaption" for
> something else wouldn't somehow "conflict" with that concept?

I hope I haven't caused any confusion with the example from HdM Stuttgart. 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.
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.

> 
> > (Note also that "Description" should only be filled in for images that are
> > too complex to be described using only an alt attribute. The alt attribute
> > is always read; the long description is presented through a mechanism that a
> > screenreader user can chose to ignore or skip. In many cases, this is a
> > link.)
> 
> Do I understand correctly that this is something that the user decides, so
> should be mentioned in the documentation?

If a long description is available, its availability should be announced to the
user (based on the appropriate API call between LibO and the screen reader), at
which point the user decides whether to read it or not. (This is how NVDA
implemented it in 2012, for example:
https://github.com/nvaccess/nvda/issues/809 .)


> 
> Interestingly, Word (or its ODT import functionality) doesn't seem to use
> the concept of separate fields for title and description. When opening the
> sample file in Word, right-clicking the image and selection "Edit alt text",
> an "Alt Text" box shows up that has the content of both fields merged
> together:
> 
> > This is the text alternative
> > 
> > This is the description // where does this appear?
> 
> and it is exported to HTML like this:
> 
> > <img width=166 height=314
> > src="Description%20Test%20file_files/image002.gif" align=left hspace=12
> > alt="Title: This is the text alternative - Description: This is the description > // where does this appear?"
> > v:shapes="Image1">

Until version 2016, MS Word had two separate fields: Title and Description.
Since Word 2019, there is only the Alt Text field. (Word 2019 also introduced
the "Mark as decorative" textbox.) Some people are still using Word 2016,
especially those who don't want to move to a subscription-based model for
desktop software.

-- 
You are receiving this mail because:
You are on the CC list for the bug.