Re: Placeholder attribute an accessible name?

I'd fail a placeholder that disappears on focus or on input every time
under SC 3.3.2 Labels or Instructions (A).  To pass this Success Criterion,
"Labels or instructions are provided when content requires user input."

Notice the rule doesn't say "labels or instructions are provided, except
that they are allowed to disappear from the screen when users need them the
most - when they're filling out a form input."

To me, that's pretty straightforward.

Brooks Newton



On Thu, Oct 20, 2022 at 7:43 AM Jonathan Avila <jon.avila@levelaccess.com>
wrote:

> The HTML Accessiblity API Mappings 1.0
> <https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-number-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element>
> does list that placeholder can be used to calculate the accessible name –
> but I’d tend to agree with John that the incomplete accessiblity support of
> it and the primary purpose of placeholder to act as a hint and not as an
> accessible name leads me to believe it is an unsafe way to meet WCAG
> conformance.
>
>
>
> Jonathan
>
>
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* Wednesday, October 19, 2022 3:37 PM
> *To:* 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.
>
>
>
> 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>
> 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"
>