yesNoUI description property is not working

[williamphelps13]

Bug Report

• I’ve searched for any related issues and avoided creating a duplicate issue.
  • I searched yesNo and did not find any issues that match yesNo

What happened

The yesNoUI pattern should allow a property of description with a type of string | JSX.Element | React.ReactNode.

This description property is working in the textareaUI:
/vets-website/src/applications/accreditation/21a/pages/06-background-information-chapter/conditionThatAffectsExaminationDetails.js - link

uiSchema: {
    conditionThatAffectsRepresentationDetails: textareaUI({
      title:
        'Describe the condition or impairment and any treatment you receive now or in the past year',
      description: ConditionThatAffectsRepresentationDetailsNote,
    }),
  },

However, the description key is not working in yesNoUI:
/src/applications/accreditation/21a/pages/06-background-information-chapter/index.js - link

uiSchema: {
      [key]: yesNoUI({
        title: question,
        description,
      }),
    },

Note: this code may look a little strange but this is because we made an abstraction to unify our many uses of the yesNo pattern. The standard yesNo use gives the same problem.

Description is not working whether it is a component or if it is a string even though both work in textareaUI.

What I expected to happen

I expected the yesNoUI description to work like the textareaUI example above, and therefore the UI would look similar to our designs:
THIS IS A FIGMA DESIGN (THE UI CANNOT CREATE THIS)

Reproducing

• Formation version: All
• Device: (e.g. iPhone 8, Macbook) All
• Browser: (e.g. Firefox, IE 11) All

Steps to reproduce:

1. Add a description property with a string or a component to a textareaUI pattern
2. Observe the description in localhost
3. Add a description property with a string or a component to a yesNoUI pattern
4. Observe the lack of description in localhost

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

Details

We are currently putting the description below the yesNoUI patterns but this does not link the description to the yesNoUI for screen readers. We also feel it is better for the note about how they should answer the yes/no question be before the yes/no options (but after the question) since it is necessary information for them to answer it.

[caw310]

This is a forms issue so its something for the VFFT to fix.
@tbaker1026

[tbaker-taylor]

@caw310 Opened this issue for Nick to take a look at in our repo

[williamphelps13]

@caw310 @tbaker-taylor In a discussion with @rhasselle-oddball from VFFT, it was noted that the root cause of "yesNoUI description property not working" was because

DST doesn't support a description text for VaRadio, which is the root issue. that ticket will need to be for DST bug report.

Apologies for not including that context previously.

[rhasselle-oddball]

Some additional context:
when we talk about "description" for fields from vets-website side, e.g. the part between the label and the field, we're talking about passing children into the web components and making it show up in that area. Either slotted or non-slotted. When you pass children into VaText, it displays correctly in that area. However with VaRadio, it already has children (list of va-radio-option), so perhaps we need a new slotted spot for a "description".

Here's an example of VaText being passed children https://staging.va.gov/mock-simple-forms-patterns/text-input
However we can't do this with VaRadio https://staging.va.gov/mock-simple-forms-patterns/radio). (compare RJSF (old patterns) vs new web component patterns

A work around you might think is that - VaRadio does support formDescription when used in conjunction with useFormsPattern, however it's not desired to use useFormsPattern for these generic cases, since we don't want our label to turn into the header of the page, but instead a generic description slot we can pass to the component.

[rhasselle-oddball]

update: I did do some testing - there are some things we can do on our side to update this. However it might not be read out by screen readers. But we can add passing the description to children in radio and yesno pattern. it looks like we might not be doing that.

[williamphelps13]

The above merged PR solves the visual part of this issue so that the radio and yesNo description is now visible, however the description is still not being read by the screen reader. I will close this ticket and created a new one that is better focused on this more narrow issue: va-radio description is not being read by screen reader #3059