Staging Review - Accessibility Feedback - Design System converted components Radio button, Checkbox and Checkbox group

[briandeconinck]

VFS actions

• [ ] Assign this ticket to the team member(s) responsible for addressing feedback provided by Platform.
• [ ] Comment on this ticket:
  • [ ] If the Platform reviewer has any Thoughts/Questions that require responses.
  • [ ] When Must feedback has been incorporated. As appropriate, link to any other GitHub issues or PRs related to this feedback.
  • [ ] When Should/Consider feedback has been incorporated, or if any feedback will not be addressed. As appropriate, link to any other GitHub issues or PRs related to this feedback.
• [ ] Close the ticket when all feedback has been addressed.

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).

• Must: For both the radio button and checkbox group components (not the single checkbox), the hint text and error messages aren't reliably announced across all screen readers when tabbing into the fieldset. Per an article from Tenon, support across screen reader/browser combinations is messy. The option that tested best in Tenon's review is to add hint and error text to the 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 using aria-describedby on the fieldset, 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 the legend --- 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 the aria-describedby attribute is on the description span and references the ID of the option label --- meaning, we're telling screen readers that the description is described by the label. Instead, the aria-describedby should be on the input and it should reference the ID of the description span --- meaning, the input is described by the description. It's definitely confusing since it's backwards from how the label uses for to reference the input. 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:

  • There may be situations where its useful for a user to know that an option would be available under different circumstances but is disabled right now. The current opacity doesn't provide enough contrast for low vision users to reliably read the label.
  • The only visible indication that an option is disabled is with color, which is an accessibility anti-pattern. While changing the control to light gray is a pretty well-established design convention, that convention breaks down in certain situations --- eg. Windows High Contrast Mode, where the high contrast black theme shows the disabled option in lime green (not a color I would associate with an option being disabled).

  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.

[jeana-adhoc]

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.

https://github.com/department-of-veterans-affairs/va.gov-team/assets/117098918/aa7ea18c-f4a2-413f-a7e5-d049b8844a05

[caw310]

Hey team! Please add your planning poker estimate with Zenhub @Andrew565 @ataker @harshil1793 @it-harrison @jamigibbs @micahchiang @nickjg231 @powellkerry @rmessina1010

[caw310]

We will work on the Musts outlined in this ticket.

[caw310]

Please add your planning poker estimate with Zenhub @rsmithadhoc

[caw310]

@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]

@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:

• Fix the Must feedback as the component is right now. But we'd have to undo that when we get to the forms team's work.
• 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.

[caw310]

Will hold off based on Ryan's comments until we find a solution with forms team.

[rsmithadhoc]

• 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.