Re: Placeholder attribute an accessible name?

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"