Skip to content

Remove aria labels from radio buttons. #1224

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

drgrice1
Copy link
Member

@drgrice1 drgrice1 commented Apr 4, 2025

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.

@dlglin
Copy link
Member

dlglin commented Apr 4, 2025

This may not be the best place for a discussion about hard-coded answer names, but we should be looking at deprecating this. Is it possible to reliably detect when an answer name wasn't generated with NEW_ANS_NAME? If so, can we add a warning for instructors in the upcoming release letting them know that this is no longer supported. Then in a subsequent release we can deprecate it.

@drgrice1
Copy link
Member Author

drgrice1 commented Apr 4, 2025

All answers that come from NEW_ANS_NAME will have the PGcore ANSWER_PREFIX which is defined to be AnSwEr. So at the very least, any answer that doesn't have that certainly didn't come from NEW_ANS_NAME. The converse would not necessarily be true though. Although all of the cases where answer names should be used but are and are using a hard-coded answer name that I have seen don't use something containing AnSwEr.

@pstaabp
Copy link
Member

pstaabp commented Apr 8, 2025

I didn't test it. I think having @glarose test may be the way to go.

I see for radio buttons, that the aria-label is removed and seems that it is added for checkboxes though.

@drgrice1 drgrice1 force-pushed the radio-buttons-no-aria branch from fef3f1f to f28ddb7 Compare April 8, 2025 23:10
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.
@drgrice1 drgrice1 force-pushed the radio-buttons-no-aria branch from f28ddb7 to 65f53dc Compare April 16, 2025 02:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants