Fix incorrect markup on radio buttons and checkbox components to support accessibility

[laflannery]

Bug Report

• [x] I’ve searched for any related issues and avoided creating a duplicate issue. This is related to the recently closed issue regarding support for Voice control users

What happened

When doing foundational testing, my team noticed that multiple axe errors were being flagged on the radio button component regarding ARIA attributes being used incorrectly - in this case the role and subsequently the aria-checked attributes are not allowed on a <label> tag:

This is also the case on the checkbox component, the same attributes are being used incorrectly here as well.

What I expected to happen

I would expect that no axe errors would be flagged for the component and that ARIA attributes would be used correctly.

However, after investigating the reason for adding the attributes and the various requirements, this was a complex issue and I wanted to propose a solution rather than just stating the issue.

I did some research and I may have a possible solution that is accessible and support voice control: This is the codepen I was working on. It currently just has the radio button example I was working on though I may work on a checkbox one as well.

• Uses the semantic HTML inputs
  • Semantic elements are often the most supported and should be used whenever possible vs. other custom elements
• Style the semantic elements to look like what we currently have on the VA
  • I wanted to make sure if was possible to style the semantic elements in the way that the VA needed so I added the blue selected state, larger elements, darker borders, etc.
  • These styles are supported and display properly on various browsers and devices (tested on Mac browsers and iPhone browser)
• This solution was tested with mouse, keyboard and VO (on Mac and iPhone) and Voice Control (on Mac and Windows by multiple users)

I also was able to briefly change the component to my implemention and test, because I wanted to see how the shadow DOM might impact this. And while Voice Control did work, I am not able to test thoroughly. I still do feel that using the semantic elements (vs the current implementation with the axe errors) is a better option but I would recommend more testing of the component itself.

Urgency

How urgent is this request? Please select the appropriate option below and/or provide details

• [ ] This bug is blocking work currently in progress
• [ ] This bug is affecting work currently in progress but we have a workaround
• [ ] This bug is blocking work planned within the next few sprints
• [ ] This bug is not blocking any work
• [x] Other

Details

While it's not blocking work, the current implementation has incorrect markup and is used quite often throughout the VA.gov site. It would be a great improvement to address this and to pass it along to USWDS

[caw310]

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

[laflannery]

@caw310 @coforma-jamie and I just discovered that the current markup (having the role on the <label>) is causing screen readers to think the number of elements - radio buttons an checkboxes - is duplicated. For example, if there is a question with 5 radio buttons, the screen reader will incorrectly announce "1 of 10" instead of "1 of 5". This will cause confusion for users as they will think they are missing half of the field options. Is there a way this ticket can be looked at sooner rather than later as it is impacting every where these fields are used?

[coforma-jamie]

@caw310, here's a clip of the "number of elements is duplicated" issue using JAWS.

This also happens using NVDA and TalkBack.