[CST] Change Notification placement on the files page

[skylerschain]

Value Proposition

As a veteran taking submission actions in CST, I want to see a clear indicator, consistently placed telling me that my action was either successful or not, so that I get the information I need to confirm my task was complete or take the action again.

Background Context

There are a few scenarios where we want to show a notification banner in the claim detail page to confirm (or deny) a user action. They are all on the Files tab:

1. After user successfully uploads a file to a claim in the Files tab
2. After user file upload fails to go through
3. After a user submits a file on the Document Request page (in response to an evidence request)
4. After a user agrees they have submitted all evidence in the Ask for your claim decision (current functionality)
5. After a user agrees they have submitted all evidence in a 5103 Notice (new functionality when flag cst5103UpdateEnabled is true)

Currently this confirmation banner is showing up at the top of the details page for #1, #3, #4 and #5 (see convo about this in this ticket).

2 is showing up within the Files tab under the "Claim files" header and subheader. Note: this is due to the error occurring in that component. (AdditionalEvidencePage.jsx)

We should standardize the behavior of these alerts so that they show up in the same place, have the same dimensions, and our scroll position and focus are set to the same place consistently across all of them.

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

• Add here

Design

The design preference is to place all confirmations where #2 is currently showing up, within the files tab content. This keeps the user focus within the Files tab, where the interaction to add files is taking place. We need to ensure that scroll position and focus are set appropriately so that users will see this banner on all screen sizes.

Another, less optimal, option would be to keep the confirmation banner above the Files tab -- see a reproduction of this in a local environment in the screenshot below:

Enablement team (if needed)

@jstrothman

Engineering

Some things to note about this...

• When we set the notification message object, it is provided to the component FilesPage.jsx. This component then passes the message object to the component ClaimDetailLayout.jsx which then displays the message using the component Notification.jsx which is using the va component va-alert. Its important to note that this va-alert can be and error or success depending on the message.
• Another thing to note is that the #2 example is rendered in a different way from the example above. the component AdditionalEvidencePage.jsx has the component AddFileForms.jsx on it, which has the logic for uploading a file. When a user uploads a file with an error, a message object is sent to the component AdditionalEvidencePage.jsx which then displays the message using the component Notification.jsx which is using the va component va-alert.

Out of scope

• Add here

Open questions

• Are there any a11y considerations to consider? (cc: @davidakennedy)
• We need to ensure our focus position for this experience is consistent for all the notification types, on large and small screen sizes.
• Does it make sense for success/error messages from other pages that are then directed to the CST claim page/ files tab, to be shown under the files tab or should they stay where they are and be shown at the top of the CST claim page?

Tasks

• [ ] Determine the best approach, based on design considerations, engineering effort levels, and a11y input
• [ ] Ensure that our notification component is updated to reflect the new design approach
• [ ] Test the new implementation on different screen sizes to ensure that it "feels right" from a UX perspective and meets a11y needs (esp for screen readers)

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

• [ ] The notification component has been updated to reflect our design and engineering changes
• [ ] The flow of submitting a file and receiving a success or error notification is intuitive and clear
• [ ] The new notification design accommodates current and future use cases for this type of notification

[davidakennedy]

Are there any a11y considerations to consider?

Here are some initial thoughts. There are a few things to consider:

Focus management and announcement of messages

From the looks of the messages within the notifications, these all seem important enough to alert the Veteran right away. So we need to make sure the headings in the notifications get announced to screen readers and other assistive technology. It looks like these notifications come after the Veteran takes an action. Like activating a button, etc. Let me know if I'm wrong there. To accomplish this, as Skylar, points out in the ticket, we can move focus to the headings of the notifications. Doing this will announce the headings in screen readers and other assistive technology.

Location on page

This is the more challenging aspect here since the notifications look like they populate on the page in different locations (according to the screenshots). Some are above the secondary navigation, and some are below it, within the content of the Files menu so to speak. In an ideal world, these would be near the top of the (after h1) because they rise to that level of importance visually, to match how we're shifting focus to the headings for assistive technology. Also, locating the notifications near the top of the page has the added benefit that no information is skipped for assistive technology.

Locating the notifications below the secondary menu, within the content of the Files menu so to speak means that assistive technology users may not realize that content is above where their focus has shifted. That may not be entirely a bad thing, but we should think through whether any content above the notifications would be important for Veterans to easily get at, depending on when the notifications happen in the experience.

Consistency

Ultimately, I'd like to see the location of the notifications be consistent across the experience. That way, it's a more predictable experience for Veterans. Recognizing that might be challenging depending on what the notifications are related to. Would all these notifications be able to fall into the same location, or do they relate to different things?

cc: @skylerschain