At a recent conference, multiple instructors shared concerns about finding problems that were both “good and accessible” in a convenient manner. Frequently, the sheer number of marginally different problems and the lack of a clear label of which problems met accessibility guidelines led them to consider new platforms.
In an effort to encourage new and existing authors to make their content accessible from the start, should a label component be autocompleted whenever someone types in the answer component? The author could change to a short description when appropriate, but having something autopopulated will go a long way towards changing my behavior.
Interesting idea. It would equally well apply to inputs like <mathInput>, <textInput>, <choiceInput>.
That’s taking the new “snippets” feature further, i.e., by making a snippet that replaces the original component autocomplete rather than adding a new one with a different label.
I’m not sure that getting rid of the original answer autocomplete is a good idea because the behavior would have to be completely different. Normally, when one types <an and autocompletes to answer, the result is that the text <answer would be inserted in the document. If we wanted to auto-add a child, we need to
- close the opening
<answer> tag,
- add the
<label>child, and
- add the closing
</answer> tag.
This means, after selecting the auto-complete the text inserted would be
<answer>
<label></label>
</answer>
I worry that would be disorienting if only a few components behaved like that.
But, if rather than having answer autocomplete to that, we had answer-with-label autocomplete, does that defeat the purpose of nudging authors in the right direction?
I think there’s a more compelling case for always labeling inputs than not. If the label component is pre-populated, then there is nothing additional one needs to do as an author - the ‘question’ just goes inside the label. I liken it to how a lot more people created retirement accounts when they were already opted in vs when they had to act to opt in.
Right. I don’t disagree. I just don’t feel confident about how to best accomplish this. Let’s keep the conversation going and see if we can come up with some consensus.
Can I get a brief summary of what the label is for in this application and why having one on input boxes increases accessibility? Maybe a best practices example or two?
I checked the documentation under the label tag, and I see examples which are labels on graph elements or on buttons which do things. There is an example with a label on a text input on a graph, but not on the answer just before the graph.
I have noticed the warnings in doenet beta and have been thus far ignoring them because I don’t understand why (or how) to use a label in this way. 
Yes, it appears the documentation is lagging behind on accessibility issues.
We’re about to release some new accessibility features and get something written about them by tomorrow’s workshop!
Here’s a work in progress on some pointers. Hopefully, it will be more complete by tomorrow.
@Anurag_Katyal also suggested having a table succinctly that gives accessibility code snippets for certain tasks.
Any suggestions on how to best communicate accessibility features are always appreciated!
With the release of version 0.7.8, I added a answer-labeled snippet that adds the label as suggested.
With that, I think the debate is whether or not just the plain answer snippet should behave like answer-labeled.