[QTI] More questions about stringInteractions

[Steve Lay]

Daniel Cassidy wrote:
> 1) Regarding the placeholderText attribute, the spec says:
[snip]
>    The expected behaviour here isn't terribly clear. For example,
>    for an empty text box, normally a screenreader will read
>    something like:
> 
>      "BEGIN INPUT FIELD END INPUT FIELD"

The way placeholder text is handled is implementation dependent.  At the 
time the specification was drafted there was concern that some screen 
reading solutions *don't* voice an empty box.  As a result, it was 
envisaged that some assessment systems designed to work with those 
solutions would use placeholder text in the boxes to ensure that the 
boxes were voiced - presumably with some sort of default word or phrase 
like "text box" rather than special text that indicates the boundaries 
of the box as per your description.

The purpose of the QTI having a placeholder text attribute was to allow 
authors to override the default placeholder text with their own *in 
these cases*.  It was only ever envisaged that it would be used in 
situations where the (assessment) application is taking control of the 
access issue and supplying the placeholder text in the first place.  If 
your system relies on a reliable lower level mechanism to meet this 
particular access requirement then it seems perfectly acceptable to 
ignore the placeholder text given in the QTI.

For web based systems, this is certainly being tackled at the 
presentation layer (i.e., the point at which HTML, Flash or other code 
interacts with the user) rather than the underlying application layer 
(e.g., QTI).  I would therefore expect placeholder text to be used very 
rarely in these apps.

>    Assuming placeholderText="bananas", the spec suggests that this
>    should become one of:
> 
>      "BEGIN INPUT FIELD bananas END INPUT FIELD"
> 
>      "bananas"

Ultimately it is a judgement call.  Support for placeholder text is not 
a requirement.  In the case where the boundary of the box is voiced it 
seems sensible to use an empty box and ignore the placeholder text.  On 
the other hand, if an empty box is voiced with a phrase like "empty box" 
then you might want to consider using the placeholder text instead.

I don't have a great example but a question for which the possible 
answers might be confused with the default voicing might provide one.

>     * If the environment is visual, should the delivery engine
>       place placeholderText in the input box initially?

No.

>     * If the environment is aural, should the delivery engine ignore
>       the placeholderText if it has some other mechanism for
>       representing an input field (such as that described above)?

Yes, IMO.

>    Some examples of correct usage would be appreciated.

Unfortunately, we don't have any good examples here.  The current advice 
I'm getting from accessibility groups suggests that this is no longer 
such a concern for them.

If anybody on the list has a good example I'd be please to hear it or a 
case of practical interest in this problem of voiced/unvoiced input 
boxes I'd encourage them to post to the list.

> 2) Regarding the patternMask attribute, there doesn't seem to be any
>    user-friendly way to feed back to the candidate that their input
>    is not valid.

This is quite a general UI problem as you suggest.  I'll leave it to 
others to suggest implementation solutions here.

>       Some mechanism to provide a custom message to display to the
>       user in the case of invalid input would be immensely helpful
>       here. Even better would be if it were possible to provide
>       several messages, selected based on which part of the input is
>       invalid.

I agree this does sound like a good idea.

>    I notice that the QTI 2.1 draft has introduced additional guidance
>    as follows:
> 
>      "Care is needed to ensure that the format of the required input
>       is clear to the candidate, especially when validity checking of
>       responses is required for progression through a test. This
>       could be done by providing an illustrative sample response in
>       the prompt, for example."

It was envisaged that this prompt would enable the user to recognize the 
form of input required.  For example, you might ask for a credit card 
number in the form "1234 4567 8901 2345" requiring spaces (I've still 
found some forms that request this) as per the layout on the card.

A more complex pattern that is not easily recognized by the candidate 
would create the problems you envisage I'm sure.

>    These facts make me wonder why it is included in QTI at all?

It is common in surveys (more than tests) to use form validation prior 
to progression.  Simple patterns can be shared for common tasks and 
specialist authoring tools might hide them from authors completely!

Steve