Re: Placeholder attribute an accessible name?

John,

I'm not going to get into a spitting contest with you on this or any other
issue. That'd be gross, I'm sure.  But, I think there's just a little bit
of value left in participating in this conversation, so I'll say this and
give it a rest from my end.

You misrepresented my logic for removing placeholder values from the
Accessible Name Calculation by using the Strawman fallacy
<https://www.logicalfallacies.org/strawman.html>.  Seatbelts and no cell
phone use in your argument are not parallel to semantic labeling and visual
labeling with the placeholder attribute in my argument. And that difference
makes it easy to deceive readers who may not dig to deep on your claims.
You say wearing seatbelts and not using a cell phone are separate things?
With the placeholder attribute under the current system, the value provides
both a semantically meaningful name and a temporary visual label.   That's
a two-for-one deal right there! This logical relationship between semantics
and visual labeling is distinctly different from your seatbelts and cell
phone example.

To the work-a-day developer who's got all he or she can handle the to-do
list, getting a pass for a form input labeled with a placeholder-only in
automated testing is all of the affirmation needed to pass the labeling
requirements for that input.  I mean after all, there is a visible label
right there in the middle of the text input, right? Here's how I imagine it
working for the vast majority of amatuer testers in the wild: Run the
automated test for SC 4.1.2. Pass.  Look to see if there's a label on the
page. Pass.  No problem.

This is not an ivory tower run-through of concepts I'm drawing on as an
authority, but a real-world exercises in haste and ignorance.  That's real
life, and that's the way it plays out in the trenches, as well you know,
working with production teams who are taxed to the limit trying to meet
ever-shifting demands while learning about accessibility on the go.  Giving
a pass to the only test that is likely to be performed on placeholder
inputs will let a lot of inaccessible content through.  That will
necessarily impact users with cognitive disabilities disproportionately,
and that's why my recommendation is to remove placeholder values from the
Accessible Name Calculation altogether.  That's my logic.  It's pretty
straightforward.  I'm not here to say that placeholder text doesn't satisfy
SC 4.1.2, I'm just here to say that passing SC 4.1.2 and being accessible
are two different concepts that pop up over and over again throughout WCAG
2.x, including this placeholder example.

John, you pulled into the discussion many and varied arguments to overwhelm
the reader <https://www.logicalfallacies.org/shotgun-argumentation.html>.
These arguments are irrelevant to this discussion
<https://www.logicalfallacies.org/red-herring.html>.  I'm not trying to
hurt anyone's feelings, I'm just being honest about issues that are holding
up progress in our field.  Again, I know I'm not alone in this
understanding.

Over and Out,

Brooks Newton
- All opinions are mine alone. And, I reserve the right to change my
opinion through what I learn in this and other forums.

On Mon, Oct 24, 2022 at 2:59 PM John Foliot <john@foliot.ca> wrote:

> Hi Brooks,
>
> You are, of course, free to hold whatever opinion you wish, but your
> dismissive response to the work done by the W3C also exposes (at least to
> me) gaps in your understanding.
>
> 1) the W3C is a technical standards consortium - they produce technical
> standards (and NOT legislation) - end of story. How those standards are
> then taken up is beyond the control of the W3C. Those standards are
> developed for the consortium members, based upon the work they are doing,
> and through a broad consensus building process that weighs all points of
> view to the best of the Working Group's - any Working Group's - ability.
> This also means that different working groups have to also work with each
> other across multiple goals. Case in point: CSS. The CSS standards are
> developed by the CSS WG, and more than once that WG has emerged with a
> "neat idea" that may not be accessible. While the W3C has a process that
> tries very hard to avoid that, if industry and the CSS working group want
> "flex box" (warts and all), then we'll get flex box - the end. The W3C is
> not in the "forbidding" role - it's not their job, nor their mandate.
>
>
> 2) per the existing WCAG conformance model, failing *any* of the A or AA
> Success Criteria means you have not met WCAG 2.x at A (or AA if that is
> where the failure is) - so I am not sure why you feel that passing SC 4.1.2
> but failing SC 3.3.2 makes the content "accessible" - it isn't, not
> broadly. However, from a purely technical perspective today, if you
> use @placeholder (erroneously) to label a form input, the AccName
> calculation provides for that possibility, and you "pass" SC 4.1.2 because
> the control has an accessible name (the *sole* requirement needed to pass
> that SC - but ONLY that SC). You still haven't passed SC 3.3.2 however, so
> you are no more conformant than had you "failed" both.
>
>
> As Patrick Lauke also notes, "...the accessible name computation algorithm
> includes language that can be interpreted as saying that placeholder can be
> used by the browser (as a measure of last resort) as an attribute that
> provides an accessible name." Knowing the history of HTML's development and
> advancement is an important piece here as well: there is a reason why the
> browser vendors pushed back (hard!) at "XML-ization" of HTML (i.e. XHTML
> 1.1) primarily due to draconian fail - a requirement for XML. In fact, the
> bulk of the work done in HTML 5 was not "new" attributes or elements
> (although there were a few new entries - notably Landmark elements), but
> no, the bulk of the work behind the scenes on HTML 5 was consistent author
> error handling by the browsers.
>
> > 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.
>
> First, I'll posit you are making assumptions with no basis in actual fact,
> as even IF you successfully meet SC 4.1.2, that ONLY means you've provided
> a Name, Role and Value programmatically.
>
> But let's take your line of reasoning further... let's say that the form
> input *IS* programmatically linked to the label using the tried and true
> <label> element... but the visible label is dove gray on white, with a
> color contrast far below 4.5:1. Congratulations, you've now met 2 WCAG 2.x
> SC, but STILL are not fully conformant to WCAG 2.x.
>
> > When an accommodation serves one group well but blocks access to others,
> we should disallow that technique.
>
> So, should we fail the "use the <label> technique" as in my strawman
> instance, it's serving one group, but blocking another (low vision users
> who cannot discern the dove gray)? Or do we instead rightly "evaluate" that
> yes, you've used a technique that allows you to meet the requirement of SC
> 3.3.2, but *your* implementation of that technique is still failing another
> Success Criteria. (Q: where do you draw the line here, as I can come up
> with other conflict possibilities within WCAG today?)
>
> I'm suggesting then that while individual SC test for specific items and
> requirements, meeting WCAG 2.x today is and always has been a more holistic
> requirement, and one that at times (IMHO) has to accept a bit of water with
> its wine. The solution to the quandary you are referencing is, as you
> correctly summarize, an educational one; it requires both the ability to
> empathize, but also the ability to share that empathy to designers and
> developers who are more often than not unaware of some of the unintended
> consequences of design choices. And there, as my grandmother used to say,
> is where "catching flies with honey is more effective than with vinegar" -
> don't beat on them, lift them up with education.
>
> > There are more examples of bad public policy in WCAG than just these two.
>
> Again, respectfully, you are misunderstanding the role of WCAG 2.x - it is
> a technical standard, and NOT "public policy" - never was, never was
> intended to be. At best, it is a technical standard that helps drive public
> policy - a job it has more often succeeded at than failed.
>
> I understand the desire to link the two, but it does a dis-service to both
> when you attempt to do so, as you are using WCAG  for the wrong reason - it
> is not a "bully stick" to force development and design teams into doing
> some things the way *you* want it done, it is instead a technical
> specification that outlines what happens when you deploy a specific
> technique in your code development.
>
> This "bully stick" concern I have is very real. I cringe whenever I see an
> "expert" fail a site on SC 1.3.1 because the site does not have landmark
> regions (this one really bugs me), as the SC does not mandate techniques,
> only outcomes. Even the quickest of checks can confirm that neither ARIA
> landmark roles nor HTML5 landmark elements even existed when that Success
> Criteria was first authored. But well-meaning evaluators, ones who take a
> similar position as you, enforce their opinion as fact, when in fact
> nothing could be further from the truth. Does providing landmarks in a
> web-page make inter-page navigation easier/better? Without a doubt - and
> THAT is the justification for why a site should include landmarks (and not
> "...because otherwise you fail SC 1.3.1").
>
> And so, the real reason why form inputs shouldn't use @landmark as a
> "label" (despite the fact that it passes SC 4.1.2) is that the technique
> fails other users (SC 3.3.2, SC 1.4.3), and there are better ways to do
> what the designers want to do (preserve screen real-estate).
>
> JF
>
> On Mon, Oct 24, 2022 at 1:37 PM Brooks Newton <brooksallennewton@gmail.com>
> wrote:
>
>> 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"
>>>
>>
>
> --
> *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"
>