[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 #12 from Christophe Strobbe <c_strobbe-fdo at yahoo.co.uk> ---
Apologies for the long "omnibus" comment:

(In reply to Michael Weghorn from comment #8)
> (In reply to sdc.blanco from comment #6)
> > For example:
> > 1. Is Text Alternative and Description only relevant in relation to export
> > (HTML, PDF)?  Or does it have (or is supposed to have) other purposes?
> 
> 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.

The distinction between the (short) text alternative and the long description
applies across document formats: HTML, PDF, LibreOffice Writer, LibreOffice
Impress, ...
(I can only speculate about the reasons why Microsoft Word 2019 removed the
distinction; it might just be because the goal of "Title" versus "Description"
was not clear from the UI and documentation and hence confused authors.)

(In reply to Michael Weghorn from comment #8)
> (In reply to Christophe Strobbe from comment #1)
> > (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.)
> 
> -> "description" is supposed to be used for a more detailed description of
> the image if a "short summary" in the "Text Alternative" field doesn't cover
> all relevant information?

Right. You always fill in the field "Alternative (Text only)" (soon to be
renamed so something better; see Bug 148941 ). If the image is too complex or
contains too much detail, you only describe the most essential information in
"Alternative (Text only)" and add the full details in "Description".

(In reply to sdc.blanco from comment #9)
> I have seen in BZ (but could not find it again) that one person mentioned
> using the Description field for documentation in a corporate setting (maybe
> in/with templates).
> 
> 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?
> 
> And maybe an option in Tools > Options > View to toggle which ones are
> shown?  (It looks like there is just enough room next to Mouse to put the
> controls.)

"Description" is not really related to corporate contexts. However, I can
imagine that companies often use charts and diagrams that are too complex to be
described with a short text alternative and that the description field
therefore becomes more important.

Neither "Alternative Text" nor "Description" are primarily intended for
tooltips and I am wary of recommending exposure as a tooltip for two reasons:
1. Screen reader users don't use a mouse, so tooltips are not exposed to them.
(Just like the "title" attribute in HTML, which is useless to screen reader
users.)
2. Sighted authors might start thinking that those attributes are intended for
tooltips and begin use them for additional information instead of text
alternatives.


(In reply to sdc.blanco from comment #10)
> > > But what can be said about the use/function of Description?
> No strong opinions here -- happy to follow the sensible ideas already being
> proposed/developed here by Christophe and Michael.
> 
> But one question in relation to the help page for the "Description" control.
> Here is the current text:
> 
>    Enter a description text. The long description text can be entered to
>    describe a complex object or group of objects to users with screen reader
>    software. The description is visible as an alternative tag for 
>    accessibility tools.
> 
> 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").

Yes, but how you mention them is important, since most people are not familiar
with them. (See more below.)


> 
> 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.   
> 
> Not trying to promote a particular formulation here -- rather my concern is
> that the description of Description should give adequate and accurate
> information so that users can make informed decisions about what might be
> possible with this field.

I think the guidance on both Title and Description needs a rewrite. I would
suggest the following:

Title

Enter a short text alternative [for the object]. This text alternative should
convey the same information as the object. If you are in doubt about how to
formulate the text description, imagine how you would describe it to someone
over the phone in one or two sentences. The meaning of the document should not
change if the object were replaced by the text alternative. Assistive
technologies, such as screen readers used by blind people, announce the
presence of the image and then read the text alternative.

Description

Enter a long description for the object. Use this field only if the image is
too complex or contains too much detail to be described with a short text
alternative. In that case, the short text alternative contains only the most
essential information and the (long) description contains all the additional
details. Assistive technologies, such as screen readers used by blind people,
should announce the presence of a long description to the user (typically after
reading the short text alternative); the user then decides whether to read it
or not.


Is this too much detail or too technical? It has the benefit of leaving out
HTML support (because I prefer to leave that out until we have fixed the issue
of exporting long descriptions) and gets rid of the formulation "is visible
as", which is not very appropriate for data that are mainly intended for blind
users.

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