On the Create account pop-up, custom user fields that are required are marked as required with a *, but the built-in fields that are required do not.
Maybe #ux and not a bug.
If someone could throw me a quick CSS fix for this, that’d be awesome.
1 Like
It was easy enough (even for me!) to turn off the red *s:
// remove * from required user fields until * can be added to the others
.user-field .required {
display: none;
}
I didn’t see an easy way to add them to the built-in fields. The built-in fields are all required, and if the setting that means “require real name” is turned off, then that description gets updated with “optional”.
In case someone else is an inept as I at CSS, here are a few more customizations that may come in handy:
// increase width of user fields
.create-account .user-field input[type=text] {
width: 450px;
}
// increase width of stock fields
.create-account input[type=text] {
width: 450px;
}
// increase width of email field
.create-account input[type=email] {
width: 450px;
}
// increase width of password field
.create-account input[type=password] {
width: 450px;
}
// remove * from required user fields until * can be added to the others
.user-field .required {
display: none;
}
// increase height of create new account modal to make room for additional fields
.modal-body {
max-height: 600px;
}
2 Likes
It’s certainly a bit of a mess right now, we’re just not very consistent.
Currently:
-
We label custom fields required with an *, but not the default fields.
-
We label the default name field as optional, but don’t label optional custom fields
-
Also minor style fixes: custom user field labels are smaller, descriptions might fail on color contrast ratio
At minimum, I’d suggest:
-
If the default options are email, username, password: don’t label anything. A 3-field sign-up form is pretty simple, and I suspect most people would assume it’s all required (and if not, our validation is good).
-
If we’re including and labeling an optional field (name), we should also label the required fields. Don’t make me think about other form fields based on the label of my current field, just tell me what to do as I go.
-
With the introduction of a custom field we should label everything… it’s just so open-ended so who knows how someone’s going to interpret an arbitrary field’s importance (especially if we’re not labeling required).
-
We should add the aria-required/aria-describedby attributes for screen readers.
In terms of labeling, the traditional asterisk is ok and a lot of people understand it… arguably a lot of people are bad at computers and it doesn’t mean anything (but maybe it’s fine for our validation to pick them up).
Worth noting that it’s becoming more common to suggest being literal and spelling out required/optional, because there’s little room for misinterpretation. It’s also a bit more accessible, because some older assistive devices might not support ARIA (at this point an asterisk becomes even more obscure).
We should also consider calling out required fields in some way if someone tries to submit the form before it’s complete. It might not be incredibly clear to everyone that the button is disabled (or why).
8 Likes