Switch to web-component-pattern using va-date with month year only option

[christinec-fftc]

Issue Description

• Follow up to Toxic Exposure: Gulf War Hazard 1990 Date Ranges #73848 to have month and year (no day field) on the TE details pages as designed in the mocks
• Currently the gulf war 1990 location dates pages are using a web-component-pattern for va-memorable-date. Once va-date supports optional month with month year only option AND pattern is built for va-date, this ticket is to move to the new pattern.
• Platform design system feature request for optional month Allow optional month for va-date when using monthYearOnly #78778

Update 9/9/24 As of 3 weeks ago (this ticket was created 6 months ago) there is now a web component pattern that supports month and year only using va-date component, yay! It's looking like we may be able to move to this pattern with the following caveats

• it currently has the same validation issue as noted in Validation errors setting date fields to null  #90446. I updated Allow optional month for va-date when using monthYearOnly #78778 to ask about it. Open for team discussion, but imo this bug doesn't seem to be a blocker since it's the same behavior for either web component patterns
• check if we need to add validation to prevent entering month only
• update the summary page to make sure it handles appropriate scenarios (see AC below)
• add more robust unit testing to validate valid scenarios and better catch these undesired scenarios
• with this scenario, it would still be possible to get a date without a month e.g. "2020-XX" so we would still want to do the BE clean up for XX's

Goal: Reduce burden of filling out TE date ranges by removing the day since we confirmed with VBA day is not needed.

Front end tasks

• 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

• TE details pages accept the following date formats: 1) year only, 2) year and month, 3) both fields empty
• If month only is entered, validation error displays
• On the summary page, bulleted content supports all 3 of the above formats along with (regression) not sure scenario
• 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]

Going to remove the estimate for this ticket since scope has changed.

[alatempa24]

Looking at the status on the ticket, I do not believe this will be finished before MVP release - moving to the post-MVP epic