An interesting question in QTI history came up in discussion amongst the QTI IPS group recently and I thought I'd answer via my blog rather than email.
In QTI, you may use either the <img> element or the <object> element to include images in questions. But in some cases only <object> will do. In the words of the question put to me:
"The rule appears to be that declaration as img is used where the XHTML is to be passed on to (say) a browser for display, but declaration as an object is used where more complex handling is required."
Why?
Both <object> and <img> are valid ways of including an image in XHTML - during spec development Safari would render them if you just pointed it at the QTI without any processing!
However, at the time of writing <object> was considered the better way to include images with <img> being the legacy method common in HTML files. As with many efforts to regularize practice this hasn't really caught on as much as the HTML working group hoped!
Anyway, as a result of the above, where we wanted to accept an image and nothing else (i.e., in certain graphic interactions where issues like bounding rectangles, click-detection and the like needed to be simple and well defined) we chose the <object> form and not the <img> form.
This doesn't stop you putting images in runs of text in places like simpleChoice where layout is not critical. And the width and height can be put on both <img> and <object> to hint at desired rendering size. In both cases the attributes are optional as most rendering engines can use the default dimensions drawn from the media file itself.
But note that the <img> element has no way to specify the media type, which does place a burden on the rendering engine if it needs to sniff the image size because it will have to use file extension heuristics, magic bytes or similar to determine the type of file before it is able use it. These are the little things that cause bugs: <object> requires the media type so it wins there too.
At first glance, <object> seems to lack the accessibility features of <img> as it has no alt text. But it does provide a fairly rich way of handling platform limitations and accessibility needs, the rule being that the contents of the element should be used as a fallback if the object itself is not suitable. There is an issue here with its use in QTI. We chose <object> because we wanted to force people to use an image, not a text-flow. In graphic questions drag-and-drop style renderings are common and this is much harder with random chunks of HTML. But if the image is of a format that the browser does not support will a rendering agent use the fallback rules and what happens if they end up with a text flow anyway? QTI is silent on this but I would not rely on any fallback content when <object> is used in graphical interactions for one of its special purposes. If a delivery engine can't show the objects in a graphical question it should seek an alternative question, not an alternative rendering, in my opinion.
By the way, in the case of <gapImg> we explicitly added a label attribute alongside the <object> to make it clear that, if a label is given by the author it should be shown to all candidates and not treated as a more accessible alternative. Which brings me on to the issue of alt text in assessment generally...
When I first left university I seriously considered working as a graphic artist, so speaking from this limited experience I feel entitled to say that however much you think of your drawing skills others may not recognize your 'dog', 'cat' or even your 'boa constrictor digesting an elephant' (Google it if you are curious). If in doubt, a label is a good idea for everyone.
