search

department-of-veterans-affairs / vets-design-system-documentation

Repository for design.va.gov website
https://design.va.gov
37 stars 57 forks source link

Experimental Design Update - Input Message #1646

Open andaleliz opened 1 year ago

andaleliz commented 1 year ago

What

I'd like to propose some updates to the input message component:

Purpose

This update improves the accessibility of the pattern, by making it more easily distinguished from adjacent inputs, and eliminating a false trail that a person using magnification tools could follow.

Usage

The usage is the same as what is described on the input message component page.

Behavior

The behavior is the same as what is described on the input message component page.

Examples

The examples are the same as what is described on the input message component page. Additional examples from the notification settings page of the VA.gov profile are here:

Accessibility

We're recommending these improvements based on observations of person with cognitive considerations and low vision using magnification tools. They were confused by the checkmark circle icon being stacked with checkmark inputs; it took them several seconds to figure out what was what. They also scrolled horizontally along the green background, thinking it was leading them somewhere and were frustrated to find it was not. "What a waste of my energy and vision time". For reference, here's the prototype they used when we observed these problems.

I don't usually recommend changes based on one person's experience, but I believe it's worth doing in this case because:

Guidance

The guidance is the same as what is described on the input message component page.

Research (optional)

caw310 commented 1 year ago

Will be discussed at 4.7 DSC meeting. Feedback will be async as requested.

andaleliz commented 1 year ago

@caw310 I saw the decision in notes doc you shared is "They can use it but it isn’t the right interaction design"

Is there any more feedback on what the "right" interaction design is? I feel uncomfortable moving forward with something that is "wrong". I don't get a sense from the notes that the existing documentation and use case were thoroughly considered.

andaleliz commented 1 year ago

Hi @caw310 just checking back on my question from earlier this week. Thank you.

cc @BerniXiongA6 FYI

caw310 commented 1 year ago

@andaleliz I don't recall specifics other than what was in the notes.

andaleliz commented 1 year ago

@caw310 ok, thank you.

For async feedback reviews, does the DSC typically send a link to the notes as a final response? I expected a more formal, detailed response to come out of the review. As far as I know, I only get those notes because I requested to I receive them regularly on behalf of a larger design team.

@rtwell @humancompanion-usds and @davidakennedy from the notes, I believe the conversation was between the three of you and would love to get more details if possible. I saw the decision in notes doc is "They (profile team) can use it but it isn’t the right interaction design"

Do you have any more feedback on what the "right" interaction design is from your perspective? That wasn't captured in the notes, and I feel uncomfortable moving forward with something that is "wrong". I don't get a sense from the notes that the existing documentation about the component and use case were part of the conversation, so maybe more information was needed.

cc @mtcA6 and @clantosswett for awareness

caw310 commented 1 year ago

@andaleliz usually, i include follow up action items and next steps. I'd say that in general, the feedback is either go ahead with this, this will be added to DST backlog, or go do research on this etc. Generally it's just action items that are the most relevant to include but I do include some specific feedback when necessary as part of final decision.

humancompanion-usds commented 1 year ago

@andaleliz - Apologies for the delay and lack of detail in the notes. We were talking in shorthand and a bunch back and forth which is difficult to capture in notes.

"They (profile team) can use it but it isn’t the right interaction design"

The conclusion we came to was that the pattern of immediate user feedback on a page where Create, Update, Read, and Delete (CRUD) all happen on one page may be adequate in some instances, but we don't have solid guidance for teams on how to setup this pattern to work elsewhere. Also, we worried that, if implemented poorly, could create problems that we've documented in other patterns that caused us to deprecate those patterns: https://design.va.gov/patterns/wizards#accessibility-defects

To back up a bit, that was within a discussion, if I recall correctly, of whether to move this component up the maturity scale. To be clear, there are no reservations about any of the changes you outlined in this issue. There are just questions around whether we should extend this component to other areas of the site. Thus a few questions:

andaleliz commented 1 year ago

@humancompanion-usds no problem, and thank you for this detailed response! This really helps to clear things up. Also CRUD made me laugh, so thank you for that too 😆

I worked closely with accessibility specialists when we came up with this component, and we've tested it multiple times with screen reader users, so at the very least we can feel confident this isn't re-introducing those issues we saw in other patterns.

Are you aware of other teams using this component?

I'm not. I think it could be useful for other teams who have similar uses cases/technical constraints where an auto-save functionality is the best way to go, but as far as I know, that doesn't exist anywhere else on the site. I personally don't think it has a lot of utility across teams and was hesitant to propose it as an experimental component when we initially launched it.

Is this component componentized in code? If so, are there plans to contribute it back as a web-component?

It is not.