Add ansLabels option to parserMultiAnswer. - #1489
Conversation
|
Could you provide a sample problem that uses this, for testing? |
|
I had to use the inspector to see the labels actually being generated. |
|
Note, without #1486 the labels won't be transferred over and only be on the hidden inputs. |
206f501 to
e590119
Compare
e590119 to
7849451
Compare
|
rebased and retargeted develop. |
`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.
7849451 to
24c8c78
Compare
somiaj
changed the title
|
After a comment in the meeting about just a way to 'label' answer boxes, I decided to just call the option |
|
I think what this makes me realize, is that we should have something like the following supported by PGML: Or at least like: Not just for |
|
@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. |
|
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. |
| my $part = $self->{part}; | ||
| my $data = $self->{data}[$part]; | ||
| my $name = $self->ANS_NAME($self->{part}++); | ||
| my $label = $self->generate_aria_label($name, $part); |
There was a problem hiding this comment.
Now that the initial value of $self->{part} is being saved to a local variable, this should be
| 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.
|
|
||
| =head2 ansLabels | ||
|
|
||
| An array reference of labels to be added to the assoicated answer box. By default answer boxes are |
|
|
||
| An array reference of labels to be added to the assoicated answer box. By default answer boxes are | ||
| labeled (C<aria-label>) with "answer X" or "answer X part Y" if C<singleResult> is used. These labels | ||
| are appeneded to the default label, e.g. "answer X part Y custom label", and can be used to improve |
| An array reference of labels to be added to the assoicated answer box. By default answer boxes are | ||
| labeled (C<aria-label>) with "answer X" or "answer X part Y" if C<singleResult> is used. These labels | ||
| are appeneded to the default label, e.g. "answer X part Y custom label", and can be used to improve | ||
| the accessiblity. For example stating the side of the equation or part of an integral the answer |
|
It seems a bit confusing that you changed 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. |
|
I also think that the option name should contain something indication which label it affects. Something like |
I agree that |
|
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 |
I am fine with it being called something that is indicative of it being for accessibility. I am not fine with it being called just a "label" as I have already said with valid justification. That is unless this is for an actual html label, and not an aria label. |
You could probably do something like allow |
5 participants
ansLabelsis an array ref which is a list of suffixes to append to the end of thearia-labelof 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-labelof 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-labelbut thought knowing what answer/part of the problem is useful as well, so I went with a suffix that is appended to the defaultaria-label.I was also looking on how to do this to regular answer blanks (maybe mathObjects specifically), so I setup
generate_aria_labelto 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 usingcmp_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.