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

<w3c-hat off>

Hi Glenda, all,

Just a quick reminder that if something that is not a WCAG compliant 
technique, it does not mean that browsers are not allowed to surface it 
in their APIs.

If browsers decide to surface the placeholder as an accessible name with 
the alternative of having no description at all, I think that’s their 
discretion. I also think that screen reader users would/do appreciate 
that as it renders form fields accessible to them where they otherwise 
wouldn't be for them. (There are accessibility issues for other Groups.) 
I personally don’t feel it serves them well to be thrown under the bus 
for theoretical purity.

As for the argument that having it in the accessible name calculation 
would encourage developers to use just placeholders, I don’t feel 
that’s valid from my day-to-day observations. They use the pattern 
because it is modern and because they can. Most developers don’t care 
about the accessibility of their websites, still. But they know they 
have to add some text to the field so there is a chance that users can 
fill it out.

I totally think “just placeholders” should be flagged in testing 
tools and maybe in browsers and validators, too, if the group decides it 
violates WCAG. But I think if browsers want to let assistive 
technologies grasp onto that last straw of an accessible name, let them 
have it.

Eric

On 8 Aug 2018, at 19:43, Glenda Sims wrote:

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





--

Eric Eggert
Web Accessibility Specialist
Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)