Remove aria labels from radio buttons.#1224
Merged
pstaabp merged 1 commit intoopenwebwork:PG-2.20from May 6, 2025
Merged
Conversation
Member
|
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 |
Member
Author
|
All answers that come from |
Member
|
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. |
somiaj
approved these changes
Apr 8, 2025
drgrice1
force-pushed
the
radio-buttons-no-aria
branch
from
fef3f1f to
f28ddb7
Compare
somiaj
approved these changes
Apr 15, 2025
drgrice1
force-pushed
the
radio-buttons-no-aria
branch
from
f28ddb7 to
65f53dc
Compare
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
force-pushed
the
radio-buttons-no-aria
branch
from
65f53dc to
c7b44e7
Compare
pstaabp
approved these changes
May 6, 2025
drgrice1
added a commit
to drgrice1/pg
that referenced
this pull request
May 10, 2025
…bwork#1224. Since that is outside of the safe compartment the `maketext` method can not be called directly. Instead it needs to be called via `pgCall`.
drgrice1
added a commit
to drgrice1/pg
that referenced
this pull request
May 10, 2025
…bwork#1224. Since that is outside of the safe compartment the `maketext` method can not be called directly. Instead it needs to be called via `pgCall`. This fixes issue openwebwork#1234.
pstaabp
added a commit
that referenced
this pull request
May 13, 2025
Fix the maketext call added to `lib/Value/AnswerChecker.pm` in #1224.
drgrice1
added a commit
that referenced
this pull request
May 13, 2025
Since that is outside of the safe compartment the `maketext` method can not be called directly. Instead it needs to be called via `pgCall`. This fixes issue #1234.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 theparserRadioMultiAnswer.plmacro has its own generate_aria_label method for now as thegenerate_aria_labelmethod inPGbasicmacros.pldoes not work well for theparserRadioMultiAnswer.plmacro.In addition add some missing
maketextcalls on aria labels, and take advantage thatmaketextsubstitutions now work in PG.We need to find a better way to create aria labels in general. The
generate_aria_labelmethod inPGbasicmacros.plis 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 callingNEW_ANS_NAMEto obtain one.