Missing form fields often do not pass Color Audit
WCAG 1.4.1 Use of Color requirements state:
1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)
Missing form fields are often only communicated by a red border around the respective field, e.g. in GitLab import:
MVC
The MVC for this problem is quite easy: Creating issues for each single one occurrence and adding inline explanations/guidance below the input field, as stated in the Pajamas docs: https://design.gitlab.com/components/forms
In the majority of these cases however, there were a lot of other issues with the form behavior as well and only very few of them currently completely satisfy our Pajamas guidelines.
Most frequent form problems
Error message in tooltip
Most error messages I saw during the audit were placed in tooltips and only popped up after submissing the form.
Multiple error messages in top bar
Submit buttons disabled by default
Even though Pajamas states We don’t disable buttons as a form of validating forms. We default to active buttons in forms and disable them once clicked to avoid the possibility of submitting the form twice., there are a lot of cases currently where this is not the case, especially in some of the most prominent places.
| Writing a comment | Related issues/epics | New issue |
|---|---|---|
 |
 |
 |
Tooltip with error message attached to navbar instead of input field
No error messages at all
One page where this occurs is Bitbucket Server Import. To reproduce the error, leave Bitbucket Server URL blank and fill in anything for username and password. The result is a page reload without any error messages at all.
Validation for empty fields failing on page load before user takes any action
As soon as the user enters a page (e.g. GitLab import), required fields that are empty are highlighted in red.
Long term solution
Taking into account that we are also trying to solve a couple of other fundamental form problems (e.g. the problem of error messages in the top bar not being visible to the user), we should communicate with the frontend team about the order in which to attack these problems. With the new Pajamas guidelines, improved notification patterns and the fact that almost none of our forms completely adhere to the Pajamas docs, it might even be more efficient to solve all these form problems in one big initiative, but I would love to get some other takes on that.