Add ansLabels option to parserMultiAnswer.

[somiaj]

ansLabels is an array ref which is a list of suffixes to append to the end of the aria-label of each answer blank. These can be used to improve the accessibility of the answer blanks when used in more complex answers, such as stating which blank is the left/right hand side of an equation, the different parts of an integral, etc.

I think being able to add to the aria-label of answer boxes could be helpful. For instance stating things like "answer 2 part 1 left hand side" or "answer 3 part 3 upper bound" could be useful with multianswer problems to describe what the different answer blanks are for in more complicated settings.

I thought about allowing custom aria-label but thought knowing what answer/part of the problem is useful as well, so I went with a suffix that is appended to the default aria-label.

I was also looking on how to do this to regular answer blanks (maybe mathObjects specifically), so I setup generate_aria_label to be able to do this for that too, but I couldn't figure out the best way to allow a user to send that information to this method. Was thinking using cmp_options, but didn't see a proper way to do this so leaving that for now. This can be extended to other answer blanks depending on what others thing of this feature.

[Alex-Jordan]

Could you provide a sample problem that uses this, for testing?

[somiaj]

I had to use the inspector to see the labels actually being generated.

DOCUMENT();
loadMacros(qw(
    PGstandard.pl
    PGML.pl
    parserMultiAnswer.pl
    PGcourse.pl
));
$ma = MultiAnswer("x + 2", "2x - 3")->with(
    singleResult => 1,
    ansLabels    => [ 'left hand side', 'right hand side' ]
);

BEGIN_PGML
[_]{$ma} [`=`] [_]*{$ma}
END_PGML
ENDDOCUMENT();

[somiaj]

Note, without #1486 the labels won't be transferred over and only be on the hidden inputs.

[somiaj]

rebased and retargeted develop.

[somiaj]

After a comment in the meeting about just a way to 'label' answer boxes, I decided to just call the option ansLabels and describe them as a label not a suffix.

[Alex-Jordan]

I think what this makes me realize, is that we should have something like the following supported by PGML:

[_]{answer}{width}{name}{label}

Or at least like:

[_]{answer}{label => my_label}

Not just for parserMultiAnswer (where of course it probably helps most) but to give authors a way to do this any time. Not sure if the aria label should jsut be what would be specified here, or appended to the usual "answer 1" and so on.

[somiaj]

@Alex-Jordan agreed, I want this to be for all answers, but wasn't sure the best way to add it and retrieve the data when creating the answer boxes and was hoping someone who understands the code better could help with that.

I just started here because I could see how to do it and this macro is used in cases it would be the most useful.

[dpvc]

The proposal from @Alex-Jordan suggests that the original problem could be written as

DOCUMENT();
loadMacros(qw(
    PGstandard.pl
    PGML.pl
    parserMultiAnswer.pl
    PGcourse.pl
));
$ma = MultiAnswer("x + 2", "2x - 3")->with(singleResult => 1);

BEGIN_PGML
[_]{$ma}{5}{'left-hand side'} [`=`] [_]*{$ma}{5}{'right-hand side'}
END_PGML
ENDDOCUMENT();

or

DOCUMENT();
loadMacros(qw(
    PGstandard.pl
    PGML.pl
    parserMultiAnswer.pl
    PGcourse.pl
));
$ma = MultiAnswer("x + 2", "2x - 3")->with(singleResult => 1);

BEGIN_PGML
[_]{$ma}{label => 'left-hand side'} [`=`] [_]*{$ma}{label => 'right-hand side'}
END_PGML
ENDDOCUMENT();

I like this because it puts the data at the location where it is used rather than having it at some earlier place where it is more detached. Of course, the original form could also be allowed. I'm just noting the possibilities.

[drgrice1]

Now that the initial value of $self->{part} is being saved to a local variable, this should be

Suggested change

	my $part = $self->{part};
	my $data = $self->{data}[$part];
	my $name = $self->ANS_NAME($self->{part}++);
	my $label = $self->generate_aria_label($name, $part);
	my $part = $self->{part}++;
	my $data = $self->{data}[$part];
	my $name = $self->ANS_NAME($part);
	my $label = $self->generate_aria_label($name, $part);

So the current value of $self->{part} is saved to $part and then $self->{part} is incremented and not used again in the method.

The same change should be made in the ans_array method.

[drgrice1]

assoicated -> associated

[drgrice1]

appeneded -> appended

[drgrice1]

accessiblity -> accessibility

[drgrice1]

It seems a bit confusing that you changed suffix to ansLabels, but yet in the aria label it is still a suffix. In your example problem I see the aria labels answer 1 part 1 left hand side and answer 1 part 2 right hand side .

I also agree with @Alex-Jordan and @dpvc that a PGML way of setting this would be nice, and that this should be extended to all answers. Perhaps that is for another pull request though.

[drgrice1]

I also think that the option name should contain something indication which label it affects. Something like ariaLabels instead of ansLabels (or ariaLabelSuffixes). This could easily be confused with the PG answer rule name set by NAMED_ANS (which also has the alias LABELED_ANS). There are also actual input labels which are actual labels in HTML (although general answer in PG lack these).

[dlglin]

I also think that the option name should contain something indication which label it affects. Something like ariaLabels instead of ansLabels (or ariaLabelSuffixes). This could easily be confused with the PG answer rule name set by NAMED_ANS (which also has the alias LABELED_ANS). There are also actual input labels which are actual labels in HTML (although general answer in PG lack these).

I agree that ansLabels could lead to confusion with named/labeled answers. My concern with using ariaLabels is whether a problem author would know what an aria label is. How about accessibilityLabels?

[somiaj]

Looking closer I think I see how to do this in a more general way. But before I do that, I have a question.

Do we want to allow users to write the full aria-label? Do we want to go the method I used here of just having a suffix (i.e. do we want labels like "right hand side", "answer X right hand side", "answer X part Y right hand side"), or do we want to allow both options? I think having the answer and part as part of the label will be useful which is why I went with that approach originally, but before I make this more general figured I'd see what others think.