2011-06-17

Getting ready for HTML5: Accessibility in QTI, img and alt text

Last night I was playing around with David McKain and co's excellent MathAssessEngine site.

I tripped over an interesting error with some test data produced by the QTI migration tool.  I was converting a basic MCQ with four images used as the choices.  On loading my content package into MathAssessEngine I got four errors like this:

Error: Required attribute is not defined: alt

I went off in search of a bug in my XML generation code from the migration tool but discovered that what MathAssessEngine is really complaining about is an empty string being used as the alt text for an image.  Actually, empty alt text is allowed by the specification (my QTI v2 files validate) and it is also allowed by HTML4 so I think it is more a bug in the MathAssessEngine, but it did force me to go and check current thinking on this issue because it is so important for accessibility.

According to the current editor's draft of HTML5 the alt attribute "must be specified and its value must not be empty" so it looks like QTI-based tools will need to address this issue in the near future.

The problem with the QTI migration tool is that it only has old scrappy content to work with.  There isn't even the facility to put an alt attribute on QTI version 1.x's matimage which, incidentally, is another reason why the community should be moving to QTI version 2.

So is there any way to set the alt text automatically when migrating version 1 content?

One possibility is to use the label attribute on matimage as the alt text for the img element when converting to version 2.  The description of the label attribute in QTI version 1 is a 'content label' used for editing and searching.  This might be quite close to the purpose of alt for matimage because a text string used to find an image in a search might be a sensible string for use when the image cannot be displayed.  However,  editing sounds like something only the author would do so there is a risk that the label would be inappropriate for the candidate.  There is always the risk of spoiling the question, for example, if the label on an image contained the word "correct" then candidates that experienced the alt text instead of the image would be at a significant advantage!

Another common way to auto-generate alt text is to use the file name of the image, this is less likely to leak information as authors are more likely to figure that the file name might be visible to the candidate anyway.  Unfortunately, image file names are typically meaningless so it would be text for the sake of it and it might even confuse the candidate - especially if the names contained letters or numbers that might get confused with the controls: just imagine a speech interface reading a shuffled MCQ: "option A image B; option B image C;  option C image A" - now our poor alt text user is at a serious disadvantage.

Finally, adding a general word like 'image' is perhaps the safest thing and something I might experiment with in the future for the QTI Migration tool but clearly the word 'image' needs to be localized to the language used in the context of the image tag, otherwise it might also be distracting.  I don't have a suitable look-up table to hand.

So in conclusion, content converted from version 1 is always likely to need review for accessibility.  Also, my experience with the migration tool reaffirms my belief that developers of QTI 2 authoring tools should start enforcing the non-empty constraint on alt for compatibility now to get ready for HTML5.