Skip to content
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

Fixed accessibility issues in Forms #161

Merged
merged 1 commit into from
Sep 21, 2021

Conversation

Wassaf-Shahzad
Copy link
Contributor

@Wassaf-Shahzad Wassaf-Shahzad commented Sep 8, 2021

Pre-Flight checklist

  • Testing
    • Changes have been manually tested

What are the relevant tickets?

Ticket #153

What's this PR do?

This PR has the following changes

  • Adds relevant id to input tags.
  • Adds role="alert" to the FormError Component
  • Adds property aria-describedby to input tags

How should this be manually tested?

  • By using light house to test accessibility.

Screenshots (if appropriate)

Light house score for local testing
Screenshot 2021-09-09 at 4 14 31 PM

Screenshot 2021-09-10 at 3 28 50 PM

Screenshot 2021-09-10 at 3 03 24 PM

Screenshot 2021-09-10 at 2 58 03 PM

Screenshot 2021-09-10 at 12 28 53 PM

Screenshot 2021-09-10 at 3 51 51 PM

@codecov-commenter
Copy link

codecov-commenter commented Sep 8, 2021

Codecov Report

Merging #161 (9da70dd) into main (4c6a42e) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #161   +/-   ##
=======================================
  Coverage   90.74%   90.74%           
=======================================
  Files         217      217           
  Lines        6301     6302    +1     
  Branches      308      308           
=======================================
+ Hits         5718     5719    +1     
  Misses        496      496           
  Partials       87       87           
Impacted Files Coverage Δ
static/js/components/forms/ChangeEmailForm.js 100.00% <ø> (ø)
static/js/components/forms/ChangePasswordForm.js 100.00% <ø> (ø)
static/js/components/forms/EmailForm.js 100.00% <ø> (ø)
static/js/components/forms/LoginPasswordForm.js 100.00% <ø> (ø)
static/js/components/forms/ProfileFormFields.js 77.41% <ø> (ø)
static/js/components/forms/RegisterEmailForm.js 91.66% <ø> (ø)
static/js/components/forms/ResetPasswordForm.js 87.50% <ø> (ø)
static/js/components/forms/elements/FormError.js 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4c6a42e...9da70dd. Read the comment docs.

@Wassaf-Shahzad Wassaf-Shahzad force-pushed the wassaf/153-accessibility-issues-form branch from ec2a59c to 4852095 Compare September 9, 2021 10:41
@Wassaf-Shahzad Wassaf-Shahzad changed the title added id's to input fields Fixed accessibility issues in Forms Sep 9, 2021
Copy link
Member

@pdpinch pdpinch left a comment

Choose a reason for hiding this comment

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

I had one question, which came up in many, many places.

You should have someone more familiar with react review this as well.

aria-describedby="confirmPasswordError"
/>
<ErrorMessage
name="confirmPassword"
Copy link
Member

Choose a reason for hiding this comment

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

Is it necessary to add a name attribute to the error message component? Does this render as a <div>?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(According to my knowledge)
The name attribute is not passed to our custom component and is used by Formik internally for associating the fields name in Formik state.
The name attribute is also required in case for ErrorMessage component.
Reference: https://formik.org/docs/api/errormessage

aria-describedby="oldPasswordError"
/>
<ErrorMessage
name="oldPassword"

This comment was marked as resolved.

aria-describedby="newPasswordError"
/>
<ErrorMessage
name="newPassword"

This comment was marked as resolved.

aria-describedby="confirmPasswordError"
/>
<ErrorMessage
name="confirmPassword"

This comment was marked as resolved.

@Wassaf-Shahzad Wassaf-Shahzad linked an issue Sep 10, 2021 that may be closed by this pull request
4 tasks
@gsidebo gsidebo self-assigned this Sep 10, 2021
@@ -123,7 +123,7 @@ export class AccountSettingsPage extends React.Component<Props> {
>
<div className="container auth-page account-settings-page">
<div className="auth-header">
<h1>User Settings</h1>
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this change is necessary, and I have an open PR that updates this page layout anyway (#185). I think you can revert this change

className="form-control"
autoComplete="given-name"
aria-describedby="legal_address.first_nameError"
Copy link
Contributor

Choose a reason for hiding this comment

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

Our original mistake here was naming these form fields in a way that matches the API results, instead of giving them camel case names like our other forms and mapping the API results to those fields. This field should have name="firstName" and the error should have id="firstNameError". That issue existed long before this PR though, so you definitely don't need to change all of these values here. In the meantime, this mixture of snake case and camel case is awkward. Can you change the naming scheme so that this value is legal_address.first_name.error or legal_address.first_name_error, whichever one you prefer? After that, please apply the same naming scheme to these other attributes that were added in this PR.

Copy link
Member

@pdpinch pdpinch left a comment

Choose a reason for hiding this comment

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

I saw that we didn't get 100 on the profile and user settings forms. Can we improve those scores?

@Wassaf-Shahzad
Copy link
Contributor Author

Wassaf-Shahzad commented Sep 14, 2021

I saw that we didn't get 100 on the profile and user settings forms. Can we improve those scores?

Regarding the User settings, I believe @gsidebo PR #185 will improve the score
and Incase of Profile form @arslanashraf7 PR #168 will improve the score.

Issues in Profile Settings

  • ARIA ID's are not unique

Screenshot 2021-09-14 at 5 42 10 PM

This issue is handled by Arslan's header PR,

Issue in User Settings

  • ARIA ID's are not unique
  • Heading Elements are not in sequential order

Screenshot 2021-09-14 at 5 45 50 PM

This will be handled in Gavin's PR

name="confirmPassword"
className="form-control"
component={PasswordInput}
aria-describedby="confirm_password_error"
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, I don't think I was clear enough in my last review. I was suggesting that only the fields that already have the anti-pattern snake case attribute values (like name="profile.job_title") should have ids that are also snake case. I know it seems weird to have different patterns for the same attributes in different files, but eventually we're going to refactor those snake case attribute values (#186) and the id's/aria attributes can be updated as well. If you notice here, confirm_password_error introduces three different conventions for attribute values in a single component. We have camel case for id and name, lowercase + dashes for className, and now snake case for aria-describedby. Dashes in CSS class names are already an understood convention that is specific to CSS. For other attributes, we should try to stick to camel case. So for example:

  • aria-describedby="confirm_password_error" --> aria-describedby="confirmPasswordError"
  • aria-describedby="email_error" --> aria-describedby="emailError"

Please apply that logic to all id and aria-describedby attributes in this PR except for the ones that are associated with a field that already has snake case attribute values (like legal_address.first_name)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was my first thought as well However please apply the same naming scheme to these other attributes that were added in this PR. this line threw me off a bit and I assumed I had to apply the style to all attributes to maintain consistency.
I should have consulted you before hand, that was an oversight on my end and as requested above I have completed the required change.

@Wassaf-Shahzad Wassaf-Shahzad force-pushed the wassaf/153-accessibility-issues-form branch 2 times, most recently from 9da70dd to ae47141 Compare September 20, 2021 08:33
Copy link
Contributor

@gsidebo gsidebo left a comment

Choose a reason for hiding this comment

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

Looks great! 👍

@Wassaf-Shahzad Wassaf-Shahzad force-pushed the wassaf/153-accessibility-issues-form branch from ae47141 to d31363e Compare September 20, 2021 13:15
@Wassaf-Shahzad Wassaf-Shahzad force-pushed the wassaf/153-accessibility-issues-form branch from d31363e to 9b5e049 Compare September 21, 2021 06:53
@Wassaf-Shahzad Wassaf-Shahzad force-pushed the wassaf/153-accessibility-issues-form branch from 9b5e049 to 14fc69b Compare September 21, 2021 06:55
@Wassaf-Shahzad Wassaf-Shahzad merged commit 7c1eade into main Sep 21, 2021
@Wassaf-Shahzad Wassaf-Shahzad mentioned this pull request Sep 24, 2021
4 tasks
@rhysyngsun rhysyngsun deleted the wassaf/153-accessibility-issues-form branch July 20, 2022 20:40
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.

Fix accessibility issues in the forms
4 participants