[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Rationale for <alt> inside <image>
The alt text has to be property of the image, which means it has to be either an attribute of <image> or a subelement of <image>.
A better model might have been to also have a separate subelement for the image reference(s) as well, but that’s not how it came from IBM and it’s been that way ever since.
<alt> allows <ph> because there’s no justification for constraining that particular content model at the base level and there’s no way in DITA to constrain an element as it occurs in a specific context using normal grammars (although you could, of course, use a Schematron to do it).
Oxygen’s presentation of the alt text in the editor is an appropriate way to do it for authoring—you have to show it somewhere. It’s not how you would normally show it in presentations (where normally the alt text is either not shown or only shown if the image cannot be shown.
There’s no necessary relationship between <image> and <fig>. (Images do not have to be figures and figures don’t necessarily contain images)
That may explain why there is an <alt> instead of @alt, not why <alt> is inside <image> and can itself contain a <ph> which can contain an <image> etc. If <alt> would be part of <fig>, there would not have been any problem with any rendering system, just like there is no problem with <title> at the top of the <fig>, where lots of PDF renderings move the <title> to a caption below the image.
To add to the problem, LwDITA is copying the same situation, with <alt> inside <image>. With <image> essentially being an inline element and <alt> a block element, this implies that mixed content makes its way into a standard that tries to do away with it altogether. Also, there is an irrational mismatch between the semantic markup of <image> and its modern multi-media counterparts <video> and <audio>: those elements have separate child elements for setting various parameters (track, controls, source, loop, etc - none of which have translatable content), where <image> has attributes for all such configuration data plus <alt> as a child element.
A consistent semantic markup for multi-media items would use similar items for similar meanings. If <video>, <audio> and <image> are all seen as part of <fig>, they should all have a similar internal structure and markup.
My suggestion would be:
To comply with various accessibility standards, the <alt> would be made mandatory and would, obviously be required for video and audio as well.
Jang F.M. Graat