Update radio buttons to use web components

christinec-fftc commented 7 months ago

Issue Description

Timeboxed story since there are so many radio buttons on 526.
Do a first pass to try and upgrade some radio buttons from widgets to web components. yesNoPattern may be a good place to start.
Make sure to use prop uswds=false. We will enable v3 on all radio buttons at a later time for UI/UX consistency.
Verify unit tests and e2e tests are still successful. Update as needed.

Scope of this ticket is to complete one set of radio buttons on one page.

From Platform Design Team - https://dsva.slack.com/archives/C03R5SBELQM/p1708966195201799 We made the decision last week to delay the V3 opt out due to vets-website CI/CD stability issues. Now that things have normalized a little more, we will be proceeding with our plan to make V3 web components opt out only. The switch will occur on March 4th. On March 4th, all web components in vets-website and content build will render their V3 variants. Additionally, the design system team originally targeted 4/19 as the date to officially retire and remove V1 components completely. In light of the impact recent CI/CD issues introduced for VFS teams, the retirement and removal date for v1 components has been moved to May 3 (5/3).

Front end tasks

Create a list of all pages with radio buttons that need to be upgraded
Ensure the page is styled according to design spec.
~Ensure the back end data from API is displayed in local and review instance~
Ensure unit tests are available.
Ensure your code changes are covered by E2E tests
Run axe checks using the Chrome or Firefox browser plugin
Test for color contrast and color blindness issues
Zoom layouts to 400% at 1280px width
Test with 1 or 2 screen readers
Navigate using the keyboard only

Acceptance Criteria

[ ] Create a ticket for the rest of the radio buttons upgrade for team 2
[ ] Designer comments on this issue to approve page styling
[ ] Unit tests pass
[ ] E2E tests cover current code and regression
[ ] End-to-end tests show 0 violations.
[ ] The data returned matches API response (for given user or scenario)
[ ] All axe checks pass
[ ] All color contrast checks pass
[ ] All zoom testing passes
[ ] All keyboard checks pass
[ ] All screenreader checks pass

Appendix

Ensure your code changes are covered by E2E tests (expand)

- Add E2E tests if none exist for this addition/change. - Update existing E2E tests if this code will change functionality. - Include axe checks, including hidden content

Run axe checks using the Chrome or Firefox browser plugin (expand)

- Ensure no heading levels are skipped. - Ensure all buttons and labeled inputs use semantic HTML elements. - Ensure all buttons, labeled elements and images are identified using HTML semantic markers or ARIA roles. - Ensure form fields have clearly defined boundaries or outlines. - Ensure form fields do not use placeholder text. - Ensure form fields have highly visible and specific error states.

Test for color contrast and color blindness issues (expand)

- All text has appropriate contrast.

Zoom layouts to 400% at 1280px width (expand)

- Ensure readability and usability are supported when zoomed up to 400% at 1280px browser width - Ensure no content gets focused offscreen or is hidden from view.

Test with 1 or 2 screen readers (expand)

- Ensure the page includes a skip navigation link. - Ensure all links are properly descriptive. - Ensure screen reader users can hear the text equivalent for each image conveying information. - Ensure screen reader users can hear the text equivalent for each image button. - Ensure screen reader users can hear labels and instructions for inputs. - Ensure purely decorative images are not announced by the screenreader.

Navigate using the keyboard only (expand)

- Ensure all links (navigation, text and/or image), form controls and page functions can be reached with the tab key in a logical order. - Ensure all links (navigation, text and/or image), form controls and page functions can be triggered with the spacebar, enter key, or arrow keys. - Ensure all interactive elements can be reached with the tab key in a logical order - Ensure all interactive elements can be triggered with the spacebar, enter key, or arrow keys. - Ensure focus is always visible and appears in logical order. - Ensure each interactive element has visible focus state which appears in logical order.

How to configure this issue

[ ] Attached to a Milestone (when will this be completed?)
[ ] Attached to an Epic (what body of work is this a part of?)
[ ] Labeled with Team (product support, analytics-insights, operations, service-design, Console-Services, tools-fe)
[ ] Labeled with Practice Area (backend, frontend, devops, design, research, product, ia, qa, analytics, contact center, research, accessibility, content)
[ ] Labeled with Type (bug, request, discovery, documentation, etc.)

christinec-fftc commented 6 months ago

Sheet for tracking and notes

michael-wojcik commented 5 months ago

Notes regarding unit testing for V3 web components:

Shadow DOM is not accessible using React Testing Library (See: https://github.com/department-of-veterans-affairs/vets-website/blob/2f07dd766cabc93c9cb2c1dddd8789afa79ed6a2/src/platform/utilities/tests/ui/webComponents.unit.spec.jsx#L46-L49)

Attempted using a new library shadow-dom-testing-library - npm to access the Shadow DOM via React Testing Library, but was still unsuccessful

Blocker: We cannot fully implement one-to-one translations of our previous Enzyme unit tests into React Testing Library unit tests

MJ's Suggestion: Look into implementing Cypress Component Testing in addition to our Cypress E2E tests, as Cypress does allow access to Shadow DOM during testing (See shadow | Cypress Documentation)

@christinec-fftc Can you please weigh in on this? I want to make sure I'm not mistaken regarding the above

christinec-fftc commented 5 months ago

Not radio buttons, but here's an example using a web component with error validation. Let's look into what other apps are doing using the existing tooling/conventions. Happy to pair on this.

christinec-fftc commented 5 months ago

@michael-wojcik let's setup some pairing time tomorrow to unit test the radio buttons you're currently working on. in the meantime, try doing a search in the repo for other folks that have unit tests with va-radio and see if there are any working examples 🙂

michael-wojcik commented 5 months ago

PR for review: https://github.com/department-of-veterans-affairs/vets-website/pull/29199

@christinec-fftc I might need some input in case I'm missing anything on the PR itself

christinec-fftc commented 5 months ago

@michael-wojcik sure thing! happy to help :)

department-of-veterans-affairs / va.gov-team