Re: Bug: Firefox Accessibility Inspector reports placeholder attribute as eligible for accessible name

Alastair,

Would it be possible to bring up this question on the next AGWG agenda?
Reason I'm dealing with the question right now...we are assessing client
sites for WCAG 2.1 SC 2.5.3 Label in Name https://www.w3.org/TR/
WCAG21/#label-in-name

I think it is important, that a11y experts be able to agree on whether the
following code snippet minimally passes:

WCAG 2.1 SC 1.3.1 Info and Relationships
WCAG 2.1 SC 2.5.3 Label in Name

Code snippet: <input type="text"  name="first"  placeholder="First Name"
id="first">
Sample of code to test: https://codepen.io/goodwitch/pen/OwEmEw
Firefox Accessibility Inspector reports this field as having an accessible
name of “First Name”

I believe it fails both

   - 1.3.1 Info and Relationships
      - (based on F68 https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-
      20161007/F68)
      - 2.5.3 Label in Name
      - because the placeholder text fails to be the accessible name based
      on F68

In the interest of helping people with disabilities...I am starting to see
what Jamie Teh is saying about placeholder being like title.  And I'm about
to say something super controversial...do we need to update Failure
Technique 68.

Peace out,
Glenda


*glenda sims* <glenda.sims@deque.com>, cpacc
<http://www.accessibilityassociation.org/certification>   | team a11y lead
| 512.963.3773

        deque systems <http://www.deque.com>  accessibility for good

On Wed, Aug 8, 2018 at 1:01 AM, Schnabel, Stefan <stefan.schnabel@sap.com>
wrote:

> Should this be exposed by the browser to the accessibility API as "foo" or
> not, if there's nothing else giving the input a programmatic name?
>
>
> It should. But it violates WCAG requirement for VISIBLE label for input,
> so it is an authoring error, too.
>
> There is a temptation in saying “browsers! Don”t map authoring errors”.
> But this is like expecting from your camera “don’t photograph this! It’s
> pathetic”. Such an approach lacks simplicity and makes things difficult to
> predict from a technical perspective.
>
> The more interesting case is
>
> <input placeholder=“foo” aria-label=“bar” title=“fine”>
>
> How can it be granted that on focus screen readers will speak all three
> exploiting the API mapping and not using the DOM info?
>
> - Stefan
>
> Von meinem iPad gesendet
>
> Am 07.08.2018 um 22:47 schrieb Patrick H. Lauke <redux@splintered.co.uk>:
>
>
>
> On 07/08/2018 21:37, Patrick H. Lauke wrote:
> ...
>
> The reason why placeholder is not advisable as a sole labelling mechanism
> is because it has usability and accessibility (e.g. for COGA) issues. But
> is that a reason not to have browsers expose it? Should they expose it only
> if there's another accessible name, and just as an accessible description?
> Or not at all?
>
>
> For that matter, I could make an input with just, say, aria-label, and
> that gets exposed as the accessible name...e.g. just
>
> <input aria-label="foo">
>
> Should this be exposed by the browser to the accessibility API as "foo" or
> not, if there's nothing else giving the input a programmatic name?
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>