WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Placeholder and Accessible Name Computation

for

From: Patrick H. Lauke
Date: May 10, 2019 1:23PM

On 10/05/2019 12:07, Mallory wrote:
[...]
> In this case, there's a handful of regular UX problems with placeholders, like
> their tendency to vanish and be low-contrast OR appear as a pre-filled default
> value. So it seems easier if, regardless if a UA+AT is able to extract an accessible
> name from a placeholder, we could recommend to simply not use them to
> clients, even those who only want to toe the WCAG AA line.

As reliance just on placeholder already fails 2.5.3 Label in Name and
3.3.2 Labels or Instructions (as soon as the placeholder text isn't
visible), and as you mentioned probably 1.4.3 Contrast (in some browsers
anyway), it shouldn't be too hard of a problem to discourage their use.

The fact remains that most (?) modern browsers also use/expose
placeholder text for their accessible name calculation, so matching
reality, I'm not sure why we're so keen on digging our heels in with a
"but the accessible name calculation algorithm doesn't explicitly
mention this" (considering the algo is, to some extent, handwavy about it)

And yes, it's nice when it's crystal clear directly in the specs whether
something is unambiguously a pass or a fail...but what counts is the end
result here, and if in most browser/AT combos placeholder text IS used
as a name of last resort, then why try by hook or crook to say it fails?

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke