@cathybaptista Thank you for flagging!

This stems from the usa-form max-width styles. Once the viewport is beyond the mobile-lg token width, the form gets a max width of our mobile token (which by default is 20rem). Since the max width is lower than the breakpoint that enables it, you see the snap back to the mobile width.

.usa-form {
  ...
  @include at-media("mobile-lg") {
    max-width: units("mobile");
  }
}

This behavior is outside of the scope of this work and can be viewed without the error states enabled in any form that uses the usa-form class (without the usa-form--large class), such as the Reset Password pattern on the develop branch!

Because of this, we shouldn't have to worry about it as being part of this work

I think we should consider using a different visual indicator (i.e. icon) instead of the bar. To me, it stands out better than the vertical bar and doesn't have the content shift issue. It's also an expected and familiar convention used for errors in forms.

I worry that the vertical bar is not noticeable, and see your point about the content shift possibly bringing needed attention to it. My initial instinct is that a content shift might not be a big deal usability- or accessibility-wise, but it's hard to know without testing or more research.

There's a really good article on form error messages and it does mention layout shifts can be "noisy" but doesn't say it's a deal-breaker, FWIW.

1. The spacing between the form elements and the error bar is very tight. It doesn't feel consistent with the other spacing in our components.
2. The bar exists in the negative margin, outside of the expected content region. This feels a bit risky to me. If users have a color shift at the edge of the content, or have split their layout at all, it might cause some unintended negative consequences.

No issues from me, but I agree it looks tight. Increasing the spacing will cause it to break out even more or be even closer to the label.

Changing the error style is a possible alternative, but higher LOE. We'd need to spike to find alternative error styles.

Possible solutions:

1. I wonder if we can consider allowing the error state to shift the content, like it currently does at narrower window widths. In USWDS - Character count: Enhance visual cue when limit is exceeded #5908, I actually found the content shift helpful because it drew my attention more to the error (Preview). We would have to investigate if there are any accessibility or usability concerns with a content shift like this, but my immediate instinct is that content shift might not necessarily be a bad thing.

I mentioned in our meeting about layout shift, but according to this Smashing Magazine article, Core Web Vital's don't count shifts caused by user interaction.¹.

@amyleadem are you suggesting we leave the form elements as-is if we decide not proceed with removing the layout shift?

2. If we decide we must prevent any content shift and are comfortable living in the negative margins, maybe we can use $theme-site-margins-width to help inform the spacing. For example, if the site margins are at least >= 4 units, then move the bar -2 or -2.5 units. If the site margins are <4 units, move the bar to -1.5 units (or something). This might be fairly limited in thinking though — it might not address forms nested inside of components, etc. Alternatively, maybe we can create a setting that allows users to control the position of the error bar?

Allowing users to control the position of the error bar seems like a good idea. I'd avoid $theme-site-margins-width because that setting has caused issues with other components.

3. Consider using icon or other visual indicator instead of the vertical bar to visually indicate an error state (this is probably better as a follow-on task)

This would require a spike for research and re-work that would increase the LOE. Not saying we shouldn't do it, but we should make these decisions much earlier to avoid scrapping work.

My recommendation

1. Give users the option to control border spacing
2. Go back to previous method
3. Re-do error styles ²

I agree that choosing new error style (Option 3) would be a large LOE that would require more research, discussion, and prototyping than this issue/release would allow.

In my opinion, the cleanest option is to just extend the current mobile styles (that have a content shift) to the desktop state (Option 1). But this might be informed too heavily by personal visual preference.

@jaclinec, have we done any testing of error states in the "mobile" view? Curious if we have heard any complaints about the current content shift in error states there.

1. The spacing between the form elements and the error bar is very tight. It doesn't feel consistent with the other spacing in our components.

2. The bar exists in the negative margin, outside of the expected content region. This feels a bit risky to me. If users have a color shift at the edge of the content, or have split their layout at all, it might cause some unintended negative consequences.

I agree that it's very tight and not ideal. The original styles work as long as enough margin is added to the container. The original styles push the bar further towards / out of the edge of the content.

	Old error styles	New error styles
Padding: 2rem
Padding: 1rem

It does feel like the safest option might be to remove the negative margins/placement and allow the content to shift with the border.

Would there be any benefit to adding a slight delay to error styles being added? Maybe like a 500ms delay after the user stops typing?

I agree that choosing new error style (Option 3) would be a large LOE that would require more research, discussion, and prototyping than this issue/release would allow.

In my opinion, the cleanest option is to just extend the current mobile styles (that have a content shift) to the desktop state (Option 1). But this might be informed too heavily by personal visual preference.

@jaclinec, have we done any testing of error states in the "mobile" view? Curious if we have heard any complaints about the current content shift in error states there.

We tested some error handling in the zebra batch testing, but it was error handling from the browser so it looked different:

Update Sept 12

I've updated the styles to reflect our discussion from dev sync (🔒). The PR description, testing instructions, and changelog have also been updated to match this new approach.

• Error border has been restored in place of psuedo-element change
• Calculation is updated to match new spacing values discussed
• Added sandbox example to help showcase change + testing purposes (Thanks for the base @amyleadem !)

@thisisdano @heymatthenry @annepetersen

This PR is approved from a technical standpoint, but we need your decision about if we should proceed with this change. We discussed in previous meetings that we might not want to release this until we have some data or feedback to back up the need for it. Curious what you think!

Correct me if I’m wrong, but I thought the decision we made in the last meeting when we discussed this was not to release it for now

Closing in favor of #6204