Re: Placeholder attribute an accessible name?

Here's the too long, didn't read synopsis of my post.  The primary reason
to remove placeholder attribute values from the Accessible Name Calculation
is to ensure clear communication to the consumers of this algorithm.
Removal serves to instruct accessibility testing software manufacturers and
their customers who use the software that inserting placeholders alone as
form labels will fail a WCAG 2.x assessment.  Focusing on the minutia of
particular issue in accessibility debates, such as with the placeholder
issue, without looking at broader implications leads to bad public policy.
And in this expert's opinion, there's evidence of more bad public policy
than the placeholder problem in WCAG that may have resulted from
constraints on debate that have increasingly become the standard mode of
operation for the Accessibility Guidelines Working Group.

Hi John,

I've made the case for which I'm advocating.  But, I'll provide a bit more
detail from my perspective.  Take placeholders out of the Accessible Name
Calculation to avoid all possibilities of content owners and testing
software makers being confused and making the mistake to pass
placeholder-only implementations as viable form input labels.  Page designs
that employ placeholder-only labeling fail WCAG 2.x - end of story, because
they fail the requirement to provide a persistently visible label under
Success Criterion 3.3.2 Labels or Instructions.  And, that stone cold
failure is the verdict regardless of whether or not placeholders serve
assistive technology users well.

When an accommodation serves one group well but blocks access to others, we
should disallow that technique.  Removing placeholder values from the
Accessible Name Calculation would make it clear to all parties that you
can't use those values in any way shape or form to piece together an
accessible name, as it is defined in WCAG.  Establishing public policy that
serves all covered constituents requires more than technical prowess at
serving a fraction who must be supported by standards.  As standards makers
we have to honestly explore how one group's accommodation might act as a
hurdle to other groups and keep that in mind when we craft a standard that
protects people with disabilities.

I understand your quandary when talk about well-intended folk in the
digital content business who are looking for direction on which entity is
supposed to do what to support the collaborative process of accessibility
support.  There is a lot confusion on this point, without a doubt.  As I'm
sure you are aware, I posted what I think accessibility support entails a
couple weeks ago on this email list.

In my opinion, Content Owners, Users, Wares Manufacturers and Standards
Bodies all have roles to play. A few years ago I thought the W3C would be a
great place to have those cross-industry discussions - but only if all of
the relevant parties are willing to meet in good faith to hammer out
responsibilities of who does what to make digital content accessible by
default. I've posted on this topic for years. If the willingness isn't
there, then I guess we'll have to find another more fertile forum for
honest collaboration if we are to move this cause forward in any
substantive way.

When we are directed by influential leaders to limit the cross talk and get
back to work filing narrowly scoped work to GitHub, we miss opportunities
to rise above the minutia and realize how the isolated component pieces we
are working on will fit (or not fit) into the larger whole of the
standard.

I'm not asking for permission to take a wider view.  I've given myself the
grace to broaden my perspective.

It's hard to recognize patterns that are obvious in the wide view when we
are forced to keep our attention tuned to the micro view of a single
Success Criterion, a single technique, a single word or phrase buried in
the back of a glossary you didn't even know was there.

I've identified some deeply disturbing patterns emerge as I indulge my
self-granted permission to take a broader view.   What I'm becoming aware
of is a pretty clear theme of codifying institutional acceptance of design
and development practices that we know don't serve all constituents of the
disability community in an equivalent way.

Here are a couple of examples for people on this email thread to consider.


   1. Is giving the accessibility OK to flat designs that have the most
   important visual queues stripped from view a good idea in a Success
   Criterion that is supposed to enhance how perceivable/distinguishable a
   page control is?
   2. Is giving the accessibility OK to have 1 pixel by 1 pixel touch
   targets in a "Target Size" Success Criterion a good idea?

In my book that's equivocation. Think we've protected folks with
disabilities with these rules?  If not those people, then who do these
rules protect? Here's a link to a site that has wide range of logical
fallacies you might find helpful as you interact in this an other forums.

https://www.logicalfallacies.org/

There are more examples of bad pubic policy in WCAG than just these two.
And, when taken as a whole, they establish a pattern that is counter to the
reason why I got into this business, which is to help all people with
disabilities live happy, successful and self-directed lives.

Have a Great Week,

Brooks Newton

On Mon, Oct 24, 2022 at 9:49 AM John Foliot <john@foliot.ca> wrote:

> 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"
>