[ ] 10-10EZ - Facility Selection: Insurance question | Design Updates (Accessibility concerns)

[SKasimow]

User Story

As a Veteran, I need to clearly and accurately answer the questions about my Insurance, in order to complete my application for VA Health Care.

Currently, the research shows that this question causes confusion, and people are having to guess what information to input. This can result in inaccurate information being submitted.

Acceptance Criteria

• [ ] Split "Are you covered by health insurance?" and "Name of provider" into separate pages
• [ ] Insurance page is displayed properly in review page
• [ ] Check to see if possible to not show the Provider page title on review page
• [ ] Check to see if possible to focus on Name of Insurance Provider input element after pressing add another
• [ ] Check to see if possible to add text to Remove button, on 2nd or more insurance providers, to denote what is being removed
• [ ] Error state of input fields should not show immediately on add another
• [ ] Verify Unit test passing
• [ ] Verify end-to-end test passing
• [ ] Verify accessibility test passing
• [ ] Insurance page - copy and design is updated in RI
• [ ] Insurance detail page - copy and design is updated in RI
• [ ] Designer checkoff via Review Instance in SOCKS (before merging)
• [ ] The data for the form submission remains consistent with original design
• [ ] Everything is live in prod

[SKasimow]

@lzapson - is there a platform ticket that we can use to show this ticket is blocked?

[markfallows]

Potential accessibility issue. Insurance page adds additional elements to fill out based on data input on the page itself.

Changing the UX to split the questions onto two pages identified an issue where displaying the information on the Review page was not working correctly.

Changes made to the Household Section may provide workflows and ideas to help address this issue.

[davidakennedy]

I wanted to weigh in here and provide more detail on the accessibility issue highlighted above.

I made a note of this when working on the overall accessibility review for the 1010EZ, but didn't come back to it for additional testing. The current pattern has some challenges for accessibility, many of which are located in the Wizard accessibility documentation on the design system site. We're not using the Wizard pattern here, but the use of progressive disclosure open the door to the same set of accessibility challenges. They are:

• New inputs or conditional text added to the DOM based on user interaction with radio buttons, checkboxes, or select menus need to be announced to screen readers so users have context that new information is available. We don't do this currently.
• The good news is that the page only changes below the input, which makes it harder to miss additional content, but a screen reader user may still miss things if they've skimmed the page ahead of selecting any choices. They may think the page is shorter than it really turns out to be.
• We'd harder to manage focus when a user makes a choice in a radio button. It would violate current WCAG standards to to that.

The best path to remediating this would be to separate the insurance choice and information into two screens. There's some downside to separating the question from the data entry, but I think we can solve that with good content.