RE: Placeholder attribute an accessible name?

I thought this had been worked out a long time ago, but it looks like it hasn’t.
https://github.com/w3c/accname/issues/17


I’ll add this to the agenda again so we can hopefully get a definitive agreement on it.

Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: Adam Cooper <cooperad@bigpond.com>
Sent: Friday, October 21, 2022 4:54 PM
To: 'John Foliot' <john@foliot.ca>; 'Patrick H. Lauke' <redux@splintered.co.uk>
Cc: w3c-wai-ig@w3.org
Subject: RE: Placeholder attribute an accessible name?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

It’s a bit clumsy, really, that there is a disconnect between the HTML specification and accessible name computation algorithm such that ‘hint’ is not really defined in either.

in my mind, a hint is not an accessible name, but more akin to an accessible description … it can only identify a control with the all-too-common and ill-informed practice of replicating a label and placeholder attribute value (eg: search).

An input pattern contained in a placeholder attribute value, for example, is metonymic almost for a street address.

The problem in my view is the tendency to be reductionist in having only an accessible name and an accessible description, the latter of which is merely a category for everything that is not an accessible name in text alternative computations.

For example, the <option> value in a <select> and the placeholder attribute in this case – these are both accessible descriptions  and computed as such, but one is a hint and the other an option.

Should these be treated the same by user agents?



From: John Foliot <john@foliot.ca<mailto:john@foliot.ca>>
Sent: Thursday, October 20, 2022 6:37 AM
To: Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>>
Cc: w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: Re: Placeholder attribute an accessible name?

Hi Patrick,

> E. Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

> where placeholder is "an attribute ... that defines a text alternative".

And this is where I am both confused and disagree with the interpretation: @placeholder is not defining a text alternative, and in fact the HTML 5 spec is explicit that it is only providing a "hint" (whatever that is) and is NOT an "HTML label". But, I also understand the priority of constituents (users over authors over implementers over code purity) - but it sure does feel like a sideways definition of a "text alternative".

> It also seems that currently browsers don't fully agree yet on whether or not placeholder should be exposed as an accName of last resort (from memory, Chrome and Webkit do expose it, while Firefox doesn't).

To which I personally believe that Firefox (like you, from memory) has the correct implementation, but I also refer back to the priority of constituents. Nonetheless, with uneven support and the other known issues with @placeholder, I maintain that using it for labeling the input is 'incorrect', and should be avoided.

JF

On Wed, Oct 19, 2022 at 2:53 PM Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
On 19/10/2022 19:42, John Foliot wrote:

> I was curious about that: the HTML 5 spec is quite clear, and the ARIA
> spec around accessible name calculation is non-specific about that
> particular attribute (the calculation is less clear than it used to be,
> when it specifically listed the attributes in the recursive loop - but I
> still don't see @placeholder mentioned anywhere). I do understand
> however that screen readers are doing this calculation out of necessity,
> but is it standard behavior, or more just due to precedent?

I believe in the accessible name calculation algorithm, this falls under

E. Otherwise, if the current node's native markup provides an attribute
(e.g. alt) or element (e.g. HTML label or SVG title) that defines a text
alternative, return that alternative in the form of a flat string as
defined by the host language, unless the element is marked as
presentational (role="presentation" or role="none").

where placeholder is "an attribute ... that defines a text alternative".

It also seems that currently browsers don't fully agree yet on whether
or not placeholder should be exposed as an accName of last resort (from
memory, Chrome and Webkit do expose it, while Firefox doesn't).

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke

https://flickr.com/photos/redux/ | https://www.deviantart.com/redux

twitter: @patrick_h_lauke | skype: patrick_h_lauke


--
John Foliot |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |
"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"