Skip to content

Conversation

venusang
Copy link

Description

This updates the input fields on the User details page so that they are readonly instead of disabled. Additionally it updates the form submit button so that it is more descriptive and also includes an aria-label.

🎟️ FE-112

Screenshots (if appropriate)

fe-112-before-after

How to Test

Navigate to a User in the Users list. Verify that the input fields are readonly (you should be able to highlight the text with your mouse) and that the submit button reflects the text changes shown in the after screenshot.

Checklist

  • I have added before and after screenshots for UI changes
  • I have added JSON response output for API changes
  • I have added steps to reproduce and test for bug fixes in the description
  • I have commented on my code, particularly in hard-to-understand areas
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have added a11y-tests label to run a11y audit tests if needed

PCI review checklist

  • I have documented a clear reason for, and description of, the change I am making.
  • If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
  • If applicable, I've documented the impact of any changes to security controls.
    Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

@venusang venusang requested a review from a team as a code owner August 28, 2025 15:35
Copy link

vercel bot commented Aug 28, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
boundary-ui Ready Ready Preview Comment Aug 29, 2025 3:27pm
boundary-ui-desktop Ready Ready Preview Comment Aug 29, 2025 3:27pm

cameronperera
cameronperera previously approved these changes Aug 28, 2025
Copy link
Collaborator

@cameronperera cameronperera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

This adds edit user details translations so the User detail form submit
button is a11y compliant

✅ Closes: FE-112
Per a11y audit, this changes the input fields to readonly instead of
disabled. It also updates the submit button text so that it is context
based and has an aria-label for screenreaders.

✅ Closes: FE-112
This moves the User detail action translation to resources/en-us.yaml
since it is specific to the user resource and is not a generic form
action.

✅ Closes: FE-112
Comment on lines 55 to 56
@enableEditText={{t 'resources.user.actions.edit-details.button.text'}}
aria-label={{t 'resources.user.actions.edit-details.button.aria-label'}}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just curious, do we need both these changes? It seems like it would be one or the other since a screen reader reads both now?

Also, the aria-label is attaching to the HDS::ButtonSet instead of the actual button it looks like.

<Hds::ButtonSet class='rose-form-actions' ...attributes>

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I implemented this based on the recommendations outlined in the ticket here.

8.2 “Edit Form” button text
Issue: Due to the structure of the page content, it was really difficult to tell what form I would be editing while using only a screen reader to navigate the page. I would consider adding the form name to the button so that it would be more informative for the user. Suggest adding an aria-label attribute to the button, where the value is “edit form: users”. Note that the visible button label matches the first part of the aria-label attribute value, conforming to WCAG Success Criterion 2.5.3 Label In Name.

Copy link
Author

@venusang venusang Aug 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hit enter too soon! But you bring up a good point wrt to the aria-label not being applied to the actual submit button. I will try and update this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, it turns out <Hds::Button /> only allows us to set the aria-label on a button if isIconOnly is true. So with that said, I went ahead and refactored this so that we are only updating the button text.

https://github.com/hashicorp/design-system/blob/main/packages/components/src/components/hds/button/index.hbs#L16C3-L17C2

aria-label={{if this.isIconOnly this.text null}}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took the ticket to mean to add an aria-label to make the existing Edit form button more descriptive for screen readers such that Edit form: users now properly describes the existing button. I also assume just changing the text of the button without an aria label would have accomplished that but it sounds like the recommendation is to add the label.

But either way reading the linked WCAG success criteria it seems like this change would now violate it:

Accessible name matches visible label: The accessible name and visible label of a control match.
Accessible name starts with visible label: The accessible name "Search for a value" begins with the text of the visible label, "Search".

Since the text is now Edit user details and the label is Edit form: users, they don't match and the accessible name doesn't start with the visible label (as opposed to Edit form: users just being a more descriptive match of the original text).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should be okay now that the button is more descriptive and not have an aria-label. For some reason I thought the ticket was suggesting to do both (descriptive and aria-label). But as mentioned, turns out we cannot update the aria-label anyway since this is not an iconOnly button 🤷‍♀️ , but if we could, I understand your point wrt the aria-label being a mismatch if we used edit form:users. I put a comment in the JIRA ticket and I'll confirm with Melanie if updating the button to be more descriptive is enough in this case.

This was not sending the aria-label down to the Edit Users detail button.
However, taking a look further at Hds::Button, this component
does not allow aria-label to be set unless it is an icon only button.
With that said, this cleans up the translation structure and removes the
aria-label translation and mark-up.

✅ Closes: FE-112
Copy link
Collaborator

@ZedLi ZedLi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thanks for the update

Copy link
Collaborator

@hashicc hashicc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for helping us with our a11y!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants