WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Placeholder and Accessible Name Computation

for

From: Birkir R. Gunnarsson
Date: May 9, 2019 6:34AM

Why can't the placeholder be mapped to an accessible description
instead of an accessible name?
Its definition and recommended use case are not to provide a name for
the field, I mean, "01/01/2000" is not a sufficient accessible name
for "Send on date".
What happens when the placeholder text has been replaced by an actual
value, is it still going to be announced if there is another source of
accessible name? What if not?
I mean "01/01/2000" "04/09/2019" (place holder / value" is downright
nonsensical to a user, much worse than having no accessible name at
all.

I think allowing the placeholder attribute as a source of an
accessible name for an input field is a dangerous path that is bad for
accessibility.
It makes accessibility auditing tools less effective (they can check
for the presence of what they believe to be an author intended
accessible name, but they cannot validate the content of that source".
It is bad for the users, placeholder text is not intended to be an
accessible name, but either an example input or interaction
instruction.
It creates further confusion if it is always announced whether it is
visible or not. when it is not visible it is usually because its
excessive, excessive verbosity it bad for screen reader usability.
It's confusing for developers. The biggest problems I run into working
with developers is how aria-labelledby and aria-describedby do not
respect visibility settings.

Maybe the browsers expose it, but it doesn't mean it should be
legitimized as accessible (passing WCAG 4.1.2), especially not as the
accessible name.
I think this is very close to legitimizing the name of the source file
of an image as its alt text, or at least the <figcaption> element as
the accessible name of an image in a figure.
Both are bad for accessibility.




On 5/9/19, Steve Green < <EMAIL REMOVED> > wrote:
> Thanks for the explanation for the change. However, it is still not at all
> clear how anyone is supposed to know which is the definitive version of the
> spec when there are similar, but different, versions with the same version
> number on different websites. I would have thought that the W3C website
> contains the definitive version but apparently not.
>
> This really does need to be made very clear because when we conduct WCAG
> audits we make recommendations for changes that cost time and money to
> implement, not to mention the political cost of persuading stakeholders that
> the changes are necessary. This is made all the more difficult if people
> opposed to the changes can point to documents that appear to contradict us.
>
> Steve
>
>
>