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.
Hi Steve. Thanks for pointing out this issue.
ReplyDeleteThe "Error: Required attribute is not defined: alt" message comes from the underlying JQTI library's validation code. This validation code checks for things that can't be expressed within the schema, and is usually an invaluable help. On looking at the relevant part of this code, it appears that empty attributes (e.g alt="") are handled in the same way as missing attributes, which explains the (erroneous) error message you get.
Related to this, the code in JQTI that writes XML back out (e.g for rendering) exhibits the same kind of logic, so your attribute disappears during the rendering process, which is clearly not satisfactory.
I will have to take a look at this part of the code in more detail as I wasn't aware that it did this. My naïve fix (which would be made to the fork of JQTI that underpins MathAssessEngine) would be to treat empty attributes as distinct from missing attributes, but I can't help thinking there might have been a reason for making it behave like this in the first place. Aside from the "empty == NULL" convention for string baseTypes, can you think of any reason why this convention should be applied to all attributes in QTI?
Well I did notice at least one occasion which helped me refine my implementation. The view attribute is sometimes required and sometimes optional. However, in v2 it takes a list of value "Candidate Proctor " etc. But the list may be empty! So sometimes you must write view="" and other times you can leave it out as optional. In the places where it is required the intention in the spec was clearly to insist on at least one view (i.e., rubricBlock) but the schema has not been done correctly to implement this constraint and will allow an empty list.
ReplyDelete