-
Notifications
You must be signed in to change notification settings - Fork 31
[FE-112] Boundary Enterprise a11y audit- User details form #2977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this 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
a40d4ac
to
334e7d6
Compare
@enableEditText={{t 'resources.user.actions.edit-details.button.text'}} | ||
aria-label={{t 'resources.user.actions.edit-details.button.aria-label'}} |
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
aria-label={{if this.isIconOnly this.text null}}
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
There was a problem hiding this 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
There was a problem hiding this 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!
Description
This updates the input fields on the User details page so that they are
readonly
instead ofdisabled
. Additionally it updates the form submit button so that it is more descriptive and also includes an aria-label.🎟️ FE-112
Screenshots (if appropriate)
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
a11y-tests
label to run a11y audit tests if neededPCI review checklist
Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.