The reasons why use of the
placeholder attribute as the only means of providing a user readable prompt for a form control is deficient UX, are voluminous. It is frustrating having to rehash this discussion endlessly.
⚠️ Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the controls label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.
Unfortunately for some, the obvious and oft-stated usability/accessibility crapness of
placeholder as label is not reason enough to avoid using it as a label.
“Show us the fail” they ask:
🤔To conform to 3.3.2 Labels or Instructions (WCAG 2.1 A) does a label have to be present regardless of the state of a control? /cc @patrick_h_lauke
— Steve Faulkner (@stevefaulkner) February 19, 2019
Unless the state means that it does not require user-input, or there are instructions instead of / as well as a label.
— Alastair Campbell (@alastc) February 19, 2019
placeholder as the only visible label for a control that requires user input fails Success Criterion 3.3.2 Labels or Instructions
At the time of user input there is no visible label, the input purpose is mystery meat.
once the user starts typing something in, the label/instructions are not visible anymore. or if the form is shown back to the user already filled in, those fields won’t have a visible label/instruction either. in both cases, this then fails 3.3.2
— patrick h. lauke #toryScum #clapForFlagWankers (@patrick_h_lauke) May 23, 2019