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
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Steve
> Faulkner
> Sent: 09 May 2019 12:03
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
>
> placeholder was added back in to reflect the reality that browsers expose
> placeholder as an accessible name in the absence of other sources for it.
> Whether one agrees or not with its inclusion, if browsers implement
> something and cannot be convinced to change it, we as spec writers document
> what is implemented. there is a related ARIA thread which may be of interest
> https://github.com/w3c/accname/issues/17
>
> As far as what spec to look at, the living spec
> https://w3c.github.io/html-aam/ is probably most accurate and the one to
> file issues on
>
> --
>
> Regards
>
> SteveF
> Accessibility is political[image: ✊]
> Working for the web
> <https://twitter.com/stevefaulkner/status/940835584410574850>,
> anywhere and everywhere [image: 🖖🏽]
>
>
> On Thu, 9 May 2019 at 10:18, Steve Green < <EMAIL REMOVED> >
> wrote:
>
>> The change log at https://w3c.github.io/html-aam/#a-1-change-log shows
>> that placeholder was removed from the computation in 2016 and
>> reintroduced this year. This change does not yet appear on the W3C
>> website, so I guess it's not official yet, but I don't really
>> understand the status of the GitHub website.
>>
>> Steve
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>> glen walker
>> Sent: 09 May 2019 00:22
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
>>
>> Joe, I think you need to finish the sentence from the spec regarding
>> native markup.
>>
>> "Otherwise, if the current node's native markup provides an attribute
>> (e.g.
>> title) or element (e.g. HTML label) **that defines a text
>> alternative**..."
>> (emphasis mine)
>>
>> So, yes, the placeholder attribute is a native markup attribute but it
>> is not an attribute that defines a text alternative. As several have
>> noted, it's hint and not a text alternative so shouldn't be included
>> in the name calculation.
>>
>>
>> On Wed, May 8, 2019 at 2:12 PM < <EMAIL REMOVED> > wrote:
>>
>> >
>> > The Accessible Name and Description Computation 1.2 does not mention
>> > it specifically, but it mentions " Otherwise, if the current node's
>> > native markup provides an attribute (e.g. title)" from Step D.
>> >
>> > The placeholder attribute is a native HTML attribute for <input>
>> elements.
>> >
>> > Thankx,
>> > Joe Humbert
>> >
>> >
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.