[Other - Accessibility] Single-click destructive action. (00.00.5)

[shiragoodman]

General Information

VFS team name

Benefits Non-Disability

VFS product name

Pension 527EZ Digital Form

VFS feature name

Form Reactivation

Point of Contact/Reviewers

Brian DeConinck - @briandeconinck - Accessibility

*For more information on how to interpret this ticket, please refer to the Anatomy of a Staging Review issue ticket guidance on Platform Website.

---

Platform Issue

No VA.gov Experience Standard for the issue found.

Issue Details

On Other service names, the Remove button removes the entry you're working on with a single click and no check to verify that the action is intended. There's also no confirmation message presented to screen reader users that the action has taken place, the only indication that it's happened is the fields disappearing from the screen.

This is not technically a violation of WCAG 3.3.2, since you get the opportunity for review.

But it's definitely introducing an opportunity for users accidentally losing data --- and for assistive technology users, losing data and maybe not even realizing it happened.

This issue also occurs on:

• VA medical centers
• Federal medical facilities
• Current employment
• Spouse’s former marriage
• Dependent children
• Gross monthly income
• Add an unreimbursed care expense
• Add a medical or other unreimbursed expense

Link, screenshot or steps to recreate

VA.gov Experience Standard

Category Number 00, Issue Number 00

Other References

Platform Recommendation

Two recommended changes:

1. Some kind of status message that receives focus when an issue has been removed, similar to the background-only alerts in use when changing contact information. If a visible status message isn't practical, at least some aria-live update should be announced to screen reader users.
2. Some kind of intermediate confirmation step between a user clicking Remove and the issue actually being removed. I believe the team working on the Supplemental Claims Form 20-0995 is exploring using a modal and intends to contribute back to the pattern in the design system.

See #56082 for how another team addressed this.

---

VFS Guidance

• Close the ticket when the issue has been resolved or validated by your Product Owner
• If your team has additional questions or needs Platform help validating the issue, please comment on the ticket
• Some feedback provided may be out of scope for your iteration of the product, however, Platform's OCTO leadership has stated that all identified issues need to be documented and it is still your responsibility to resolve the issue.
• If you do not believe that this Staging Review issue ticket is the responsibility of your team, comment below providing an explanation and who you believe is responsible. Please tag the Point of Contact/Reviewers. Governance team will research and will follow up.

[katherine-fung]

I'm drafting content for the confirmation messages for the team to use when it addresses this issue.

[katherine-fung]

When the team addresses this issue, please use this copy for the confirmation messages. Please bold the dynamic content in the confirmation messages as shown below. Thank you!

[Please note that we only need confirmation messages when a user is trying to remove an item that they've saved.

If a user wants to remove an unsaved item, we don't need the confirmation message (i.e. they're in the middle of adding a new item and filled in the fields partway and wants to stop filling in the rest of the fields, they select "Remove" because they changed their mind about adding the item). We don't need to show a confirmation message here because they're not losing any data. They've just decided they don't want to add the item after all.

I'm not sure how this works with auto save, but I believe this should apply if the team changes the design of the multiple response pages to follow VADS.]

Screenshot:

Copy recommendations for confirmation messages

• [ ] Other service names

[header] Remove this name?

We'll remove [First name] [Middle name] [Last name] [Suffix].

[BUTTON] Yes, remove this [BUTTON] No, keep this

• [ ] VA medical centers

[header] Remove this VA medical center?

We'll remove [name of VA medical center].

[BUTTON] Yes, remove this [BUTTON] No, keep this

• [ ] Federal medical facilities

[header] Remove this federal medical facility?

We'll remove [name of federal medical facility].

[BUTTON] Yes, remove this [BUTTON] No, keep this

• [ ] Current employment

[header] Remove this job?

We'll remove [job title] from your current jobs.

[BUTTON] Yes, remove this [BUTTON] No, keep this

• [ ] Spouse’s former marriage

[header] Remove this former marriage?

We'll remove [name of former spouse] as a former spouse of [name of current spouse].

[BUTTON] Yes, remove them [BUTTON] No, keep them

Dependent children

[header] Remove this dependent?

We'll remove [name of child] from your dependents.

[BUTTON] Yes, remove them [BUTTON] No, keep them

• [ ] Gross monthly income

[header] Remove this source of income?

We'll remove [income type] from [who pays this income field].

[BUTTON] Yes, remove this [BUTTON] No, keep this

• [ ] Add an unreimbursed care expense

[header] Remove this care expense?

We'll remove the expense for [name of care provider].

[BUTTON] Yes, remove this [BUTTON] No, keep this

• [ ] Add a medical or other unreimbursed expense

[header] Remove this medical or other unreimbursed expense?

We'll remove the expense for [who receives this payment field].

[BUTTON] Yes, remove this [BUTTON] No, keep this

Here's a reference for the visual style of the confirmation message:

[vbellissimo]

@ToddWebDev is this new confirmation message recently applied to the form a design system component? If so, do you know if applying @katherine-fung 's recommendations above would deviate from this?

cc @mayacoforma @gmaciolek

[katherine-fung]

I'm following up on Vicky's question above. If we can't implement the copy recommendations in my comment on January 26, can we use a confirmation message component that tells the user which item they're removing? Otherwise, it will be hard for assistive technology users to know exactly which item they're removing.

This is the current confirmation message format in staging:

versus the example in the design system, that identifies the item in body copy

[vbellissimo]

@gmaciolek @ToddWebDev do you have any insight on the comments above?

[gmaciolek]

@aplatt-coforma I suggest we hold off on this one until we've updated our implementation of the multi-response pattern in case that addresses this comment from Katherine:

[Please note that we only need confirmation messages when a user is trying to remove an item that they've saved.

If a user wants to remove an unsaved item, we don't need the confirmation message (i.e. they're in the middle of adding a new item and filled in the fields partway and wants to stop filling in the rest of the fields, they select "Remove" because they changed their mind about adding the item). We don't need to show a confirmation message here because they're not losing any data. They've just decided they don't want to add the item after all.