[CST] Update alerts on claim cards so that they don't create misleading impressions about request status

[skylerschain]

Value Statement

As a Veteran I want to understand clearly the status of requests within CST So that I know whether something actually needs my attention and action

---

Background Context

Currently, when the documentsNeeded flag from BGS is set to true (i.e. when a tracked item is open), the "An item needs your attention" alert appears on claim cards.

The yellow alert on the card will be visible in 3 of the following scenarios:

1. 1P (First party) Alert - Veteran has to do the work to fulfill the request
2. 3P (Third party) Alert - VA is doing the work to fulfill the request
3. The Veteran has already submitted documents in responded the first party request, but the tracked item is still open in VBMS

We would need BGS to change their logic for this flag in order for this alert to work as intended. Given that this may take a while, we are exploring alternative solutions.

One idea is to change the yellow alert on the claim card to representing not that the user needs to take action on a request, but that a request is open. That would be accurate for both 1P requests and 3P requests, and regardless of the state until closed.

New Feature

• Why are we doing this work?
• Epic Link

Outcome, Success Measure, KPI(S), and Tracking Link

• We track if our new design solution (new alert message/design) will make people take longer to respond to 1p request

Design

• Figma Design

Enablement team (if needed)

@member of team

Accessibility annotations

Accessibility annotations are located in the "For engineers" section of the Figma file.

Key points:

• For the visual button in the expandable alert that says: "There’s an open request for this claim": This should have an aria-label: "There’s an open request for this claim submitted on [date]"
• For the link in that same expandable alert that says "Find all recent requests for this claim": This should have an aria-label: "Find all recent requests for this claim submitted on [date]"

Engineering

• Add here

Out of scope

• Add here

Open questions

• Do we track or have visibility when Veterans submit supporting documents for a 1P (first-party) request? No, at least not in the API that we use for claim card. Our environment is stateless architecture which means the details page and claim card page doesn't communicate with each other.
• What statuses or notifications can we display on the front-end when Veterans have responded to a request, but the tracked item hasn't been closed yet? None. Going back to the stateless code-base, the pages can not communicate with each other. So there are no session variable or data that we can send between pages.
• Can we track the click through rate to see if maybe changing it to blue made people leave 1p request longer? Yes
• Will all tracked items have development letter?
 NO. not all tracked items will have letters, but all development letters will be associated with a tracked item. 

• Does the tracked item close when evidence is received or complete? Complete. Tracked items closes when the VSR closes the tracked item. Either because it’s reached the suspense date or they received something. But usually it’s when the suspense date is reached.

Additional questions and answers can be found in the google doc, Claim cards - Understanding tracked items

Tasks

• [x] Explore design solutions for the aforementioned goal
• [x] Sync with team to align on the best design solution and discuss feasibility of various approaches
• [x] Create spec for the solution

Definition of Done

• [ ] Meets acceptance criteria
• [ ] Passed E2E testing (90% coverage)
• [ ] Passed unit testing (90% coverage)
• [ ] Passed integration testing (if applicable)
• [ ] Code reviewed (internal)
• [ ] Submitted to staging
• [ ] Team approved production verification process
• [ ] Design performs design QA and verifies the implementation matches the design spec
• [ ] Accessibility specialist performs accessibility review (in code or design)
• [ ] Engineering identifies staging users required to test and shares account and credentials with design and product
• [ ] Product performs functional QA and verifies acceptance criteria was met

Acceptance Criteria

• [ ] Change the language and/or design on the claim card alert so that users understand the link between claim card request and subsequent "action items" in details views.
• [ ] Design helps users understand that there might be a delay in a claim card alert disappearing after they take action (actual technical behavior of tracked items).
• [ ] Design needs to be behind a feature flag

[uxgary]

I've created a section in the Figma file for engineers including notes

[uxgary]

I've created a more robust solution that satisfies the acceptance criteria. However the robust version will likely require a collab cycle. In the interest of mitigating a known issue sooner, I'm creating an interim solution that can be launched with minimal setbacks.

[davidakennedy]

Added accessibility annotations to the ticket.

[skylerschain]

Hey @harshil1793 and @uxgary it looks like this has made it into staging - yay! But I'm seeing a discrepancy in the language between what's in staging and what we landed on in Figma.

From Figma

Currently in staging

[skylerschain]

Design QA: LGTM