Open briandeconinck opened 1 year ago
In my team's foundational a11y testing of the new v3 components, I documented another issue with the radio buttons in our implementation.
Here is what I found:
Radio Group
When I tab to a radio group the screen reader does not announce how many items are in the group. I believe va-radio-option
is missing role="radio"
In the v2 components, the group would announce how many options were available and it had the va-radio-option
attribute. It is not announced in the v3 components.
Hey team! Please add your planning poker estimate with Zenhub @Andrew565 @ataker @harshil1793 @it-harrison @jamigibbs @micahchiang @nickjg231 @powellkerry @rmessina1010
We will work on the Musts outlined in this ticket.
Please add your planning poker estimate with Zenhub @rsmithadhoc
@rsmithadhoc , would you provide your thoughts on the Musts listed above? SInce you are the a11y specialist on DST and are aware of the impact of changes on the forms library, would like to get your opinion before we move forward on any updates.
@rsmithadhoc , would you provide your thoughts on the Musts listed above? SInce you are the a11y specialist on DST and are aware of the impact of changes on the forms library, would like to get your opinion before we move forward on any updates.
If we fixed the Must feedback with the component as-is, it wouldn't address what the forms team needs, so it would still require rework.
I think we can either:
Will hold off based on Ryan's comments until we find a solution with forms team.
- Hold off on fixing the Must feedback, determine what we want to do for the forms team solution, then implement that. That solution would address the Must feedback at the same time.
We have implemented a solution for the forms team, but opted to have it be a separate flow outside of the standard component. Because of that, we should still review and fix these in the default configuration.
VFS actions
Thoughts/questions
-
Feedback
Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).
legend
, and my ad hoc testing so far matches their findings across all the scenarios they tested. I'll note that GOV.UK tries to solve for this by usingaria-describedby
on thefieldset
, but my testing matches Tenon's finding that support for this is inconsistent across screen reader/browser combinations. My best recommendation is to follow the Tenon suggestion to insert text directly into thelegend
--- but I'm happy to talk through this more if that's not a desirable solution. I had never realized how messy this pattern is.Must: When a tile option (both radio and checkbox) has description text,
aria-describedby
is being misused. Right now thearia-describedby
attribute is on the descriptionspan
and references the ID of the optionlabel
--- meaning, we're telling screen readers that the description is described by the label. Instead, thearia-describedby
should be on theinput
and it should reference the ID of the descriptionspan
--- meaning, the input is described by the description. It's definitely confusing since it's backwards from how thelabel
usesfor
to reference theinput
. Fun quirks of HTML.I didn't mention this one in the meeting because I didn't notice it until just now. It actually seems to be announced without any issue as currently coded in the screen reader/browser combinations that I tried! But this should still be fixed because there's some assistive technology out there somewhere that will get stuck on this.
Should: When an option is disabled (both radio and checkbox), both the button circle and its label have their opacity set to 0.3. WCAG excludes disabled controls from its contrast requirements so this is likely not a WCAG violation. But if we're aiming higher, this leads to a couple of potential accessibility issues:
In general, we should probably be avoiding disabled controls entirely. But in situations that the USWDS may want to support where it's important to allow for disabled controls, I would recommend keeping the label text at 100% opacity and explore some other visible indicator to show that the option is disabled.