Contents of the artwork 'alt' attribute do not appear in output

[ajeanmahoney]

Describe the issue

The 'alt' attribute of the artwork element (<artwork alt="descriptive text to help readers understand the artwork">) is supposed to let authors provide a description of a figure so that assistive technology apps can in turn provide the description to readers who are visually impaired in a way that is easier to process (e.g., in audio format). However, when text is included in the artwork 'alt' attribute, it does not appear in the HTML or PDF output.

Code of Conduct

• [X] I agree to follow the IETF's Code of Conduct

[martinthomson]

Given that alt text forms a complete alternative to the image, why is this an attribute and not part of <artset>? I realize that you might want different alternative text for a different image format, but it seems to me like the simplest approach is to provide a singular descriptive block, even though that might be limiting.

[JayDaley]

The suggestion from @martinthomson does seem sensible.

[reschke]

The reason is: history. The alt attribute predates the intruction of artset by at least 15 years.

[cabo]

On 2023-11-06, at 11:13, Julian Reschke @.***> wrote:

The reason is: history. The alt attribute predates the intruction of artset by at least 15 years.

… and repeats the most prominent pervasive mistake in RFCXML:

Text doesn’t belong into attributes (because you can’t put markup there).

So like title= became <name, deprecating alt= and using <artset (with a full block mode RFCXML content) seems the way to go.

Grüße, Carsten

[martinthomson]

I like the idea of having descriptive text as an arm of <artset>.

[reschke]

FTR: it just mirrors what HTML has (img/@alt). Over a decade ago, there was an epic WHATWG-W3C war about whether longdesc should be retained; it's gone in WHATWG's HTML5, but there's now a separate W3C spec for it (if I read things correctly).