You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was requested by @glarose and the accessibility experts at the
University of Michigan. Having aria labels on these radio buttons that
also have labels causes issues with screen readers. It results in the
aria label being read and not the actual label.
It seems to me that this is correct in any case. An input should not
have both a label and an aria label. Those clearly conflict.
Also improve the aria labels for the answers inside the radio buttons
for a `RadioMultiAnswer`. For this the `parserRadioMultiAnswer.pl`
macro has its own generate_aria_label method for now as the
`generate_aria_label` method in `PGbasicmacros.pl` does not work well
for the `parserRadioMultiAnswer.pl` macro.
In addition add some missing `maketext` calls on aria labels, and take
advantage that `maketext` substitutions now work in PG.
We need to find a better way to create aria labels in general. The
`generate_aria_label` method in `PGbasicmacros.pl` is neither versatile
nor extensible. Attempting to construct meaningful labels from PG's
answer name was never a good idea to begin with. By the way, since the
aria label is currently constructed from the answer name, this is yet
another reason to strongly discourage (actually flat out forbid) problem
authors from using hard coded made up answer names in problems instead
of calling `NEW_ANS_NAME` to obtain one.
0 commit comments