Re: Placeholder attribute an accessible name?

Brooks writes:

> there can be no conversation about placeholder values satisfying the WCAG
requirement for SC 4.1.2 Name, Role, Value without there being a strong
rebuff of the practice of using placeholders as form labels for sighted
non-AT users, a violation of SC 3.3.2 Labels or Instructions.

I'm a bit confused here... where I live, there are laws that state you must
always wear a seat-belt when driving a car, and other laws that also
mandate against using a cell phone while driving: both are about driving
safely, but both are also about completely different things.

SC 4.1.2 is about ensuring that AT gets the required 'semantic' information
about a control so that non-sighted users can interact with it. The visible
labeling requirement is for sighted users: i.e. seatbelts and hands-free
driving. I have no issue with a site (or page) passing SC 4.1.2 (if it
meets those mandated requirements), and yet failing the same page
against SC 3.3.2 if it fails *those* requirements. At the end of the day,
failing either means they are non-conformant.

> take placeholder values out of the accessible name computation.

Respectfully, that will not solve any problem, only make the current
problem worse.

Just because there is something in "the spec" does not in any way force
vendors to adhere to the spec - in fact initially the @placeholder
attribute WAS NOT part of the accessible name calculation, which left
vendors of screen reading tech in a lurch: do they support the spec, or
support their users? At the end of the day, they (correctly) chose to
support their end-users, because most daily SR users are NOT techno-geeks
who worry about minutiae of web development - they just want the page to
"work", and expect their software to deliver on that.

Some of you may know that I was part of a small group that fought to
retain @longdesc into HTML5 - and we succeeded there. However Apple decided
that they would not support that attribute in their browser or screen
reading software - even though it is *in the spec* and so today, despite
being 'legal', it is functionally non-useful. So, to best serve all their
constituents, the specs generally reflect reality on the ground, rather
than attempt to re-write it.

JF

On Sat, Oct 22, 2022 at 11:08 AM Brooks Newton <brooksallennewton@gmail.com>
wrote:

> +1 to Sailesh.
>
> My thought is that when we artificially limit conversations to the narrow
> confines of what someone in the group feels is the appropriate scope of a
> conversation, we miss out on opportunities to better understand unintended
> consequences of our policy decisions.
>
> In my opinion, there can be no conversation about placeholder values
> satisfying the WCAG requirement for SC 4.1.2 Name, Role, Value without
> there being a strong rebuff of the practice of using placeholders as form
> labels for sighted non-AT users, a violation of SC 3.3.2 Labels or
> Instructions.
>
> Accessibility testers may think that having a placeholder value is all
> that needs to happen for the form input to pass accessibility testing, when
> it comes to having a "name" or "label" for the input.  It's easy to let a
> machine tell you what's right or wrong and not give another thought to that
> page element.  I know this because I've trained thousands of production
> staff across numerous enterprise teams and have watched them rely on
> automated results only. That "easy button" approach to accessibility
> testing sets up a significantly disparate experience for assistive
> technology users, and for users with cognitive disabilities who do not use
> the same technology.
>
> There's a lot of this same type of siloed logic in WCAG.  And this, I
> believe, has led to the current state of the standard where we support some
> people with disabilities at the expense of setting up hurdles to access for
> others with different types of disabilities.
>
> I'll say it plainly: take placeholder values out of the accessible name
> computation. That programmatic indication is better positioned as something
> software vendors can use as a heuristic hook to glean the content creators'
> intent in the absence of proper markup of relevant form inputs.
>
> Brooks Newton
>
> On Sat, Oct 22, 2022 at 9:52 AM Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> On 22/10/2022 14:19, John Foliot wrote:
>> > Sailesh writes:
>> >
>> >      > Developers tasked with making content accessible  should not
>> >     ordinarily delve into the depths of  the accessible name computation
>> >     algorithm and rely on  less preferred fallback mechanisms to
>> compute a
>> >     name for an element.
>>
>> The question isn't though if developers should or shouldn't. It's
>> whether or not the behaviour of browsers to use the fallback (documented
>> in the accessible name computation algorithm) to expose an accessible
>> name counts as passing 4.1.2 Name, Role, Value. Nominally, I'd say it
>> does. Whether it's good or bad practice is a separate discussion.
>>
>> 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"