E-mail List Archives
Thread: Placeholder and Accessible Name Computation
Number of posts in this thread: 27 (In chronological order)
From: Steve Green
Date: Wed, May 08 2019 12:16PM
Subject: Placeholder and Accessible Name Computation
No previous message | Next message →
Chrome's browser developer tools contain an Accessibility tab that calculates the accessible name. That can be very helpful when testing convoluted code you didn't write yourself, but the computation appears to contain an error insofar as it uses the "placeholder" attribute.
Bryan Garaventa's tool https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html does not use the "placeholder" attribute, and since he was an author of the Accessible Name and Description Computation 1.1 I am inclined to trust his implementation rather than Chrome's.
It seems that the computation rules are ambiguous when they say "Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string". Chrome is interpreting the "placeholder" attribute as a text alternative but Bryan's tool isn't.
Any thoughts on this?
Regards,
Steve Green
Managing Director
Test Partners Ltd
020 3002 4176 (direct)
0800 612 2780 (switchboard)
07957 246 276 (mobile)
020 7692 5517 (fax)
Skype: testpartners
= EMAIL ADDRESS REMOVED =
www.testpartners.co.uk
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
From: Detlev Fischer
Date: Wed, May 08 2019 1:29PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
I seemed to remember placeholder has been included in the native HTML input name calc https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element <https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element> which @stevefaulkner has just confirmed - while the doc Accessible Name and Description Computation 1.2 https://w3c.github.io/accname/ <https://w3c.github.io/accname/> doesn't list it. So I am not sure why these sources are out of sync and which one should be considered authoritative...
> Am 08.05.2019 um 20:16 schrieb Steve Green < = EMAIL ADDRESS REMOVED = >:
>
> Chrome's browser developer tools contain an Accessibility tab that calculates the accessible name. That can be very helpful when testing convoluted code you didn't write yourself, but the computation appears to contain an error insofar as it uses the "placeholder" attribute.
>
> Bryan Garaventa's tool https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html does not use the "placeholder" attribute, and since he was an author of the Accessible Name and Description Computation 1.1 I am inclined to trust his implementation rather than Chrome's.
>
> It seems that the computation rules are ambiguous when they say "Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string". Chrome is interpreting the "placeholder" attribute as a text alternative but Bryan's tool isn't.
>
> Any thoughts on this?
>
> Regards,
> Steve Green
> Managing Director
> Test Partners Ltd
> 020 3002 4176 (direct)
> 0800 612 2780 (switchboard)
> 07957 246 276 (mobile)
> 020 7692 5517 (fax)
> Skype: testpartners
> = EMAIL ADDRESS REMOVED =
> www.testpartners.co.uk
>
> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>
> > > >
From: Jonathan Avila
Date: Wed, May 08 2019 1:34PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
I am generally opposed to the placeholder being used as the accessible name because I believe it will lead to the sole use of it as an accepted way of providing a name rather than a fallback. The placeholder should not act as a label and should act as a hint. By including it in the name it encourages it's acceptance as a label rather than a placeholder. It's called placeholder for a reason and not a label.
Would we accept the src of an image as fallback content for the alternative text of an image if no alt text was provided? What about the name attribute of an iFrame if no title or aria-label was provided?
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Detlev Fischer
Sent: Wednesday, May 8, 2019 3:29 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I seemed to remember placeholder has been included in the native HTML input name calc https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element <https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element> which @stevefaulkner has just confirmed - while the doc Accessible Name and Description Computation 1.2 https://w3c.github.io/accname/ <https://w3c.github.io/accname/> doesn't list it. So I am not sure why these sources are out of sync and which one should be considered authoritative...
> Am 08.05.2019 um 20:16 schrieb Steve Green < = EMAIL ADDRESS REMOVED = >:
>
> Chrome's browser developer tools contain an Accessibility tab that calculates the accessible name. That can be very helpful when testing convoluted code you didn't write yourself, but the computation appears to contain an error insofar as it uses the "placeholder" attribute.
>
> Bryan Garaventa's tool https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html does not use the "placeholder" attribute, and since he was an author of the Accessible Name and Description Computation 1.1 I am inclined to trust his implementation rather than Chrome's.
>
> It seems that the computation rules are ambiguous when they say "Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string". Chrome is interpreting the "placeholder" attribute as a text alternative but Bryan's tool isn't.
>
> Any thoughts on this?
>
> Regards,
> Steve Green
> Managing Director
> Test Partners Ltd
> 020 3002 4176 (direct)
> 0800 612 2780 (switchboard)
> 07957 246 276 (mobile)
> 020 7692 5517 (fax)
> Skype: testpartners
> = EMAIL ADDRESS REMOVED =
> www.testpartners.co.uk
>
> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>
> > > archives at http://webaim.org/discussion/archives
>
From: Steve Green
Date: Wed, May 08 2019 1:49PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
I totally agree, but my immediate concern is to understand whether it is non-compliant for a textbox to have no name other than its placeholder. Sadly, the developers are pushing back against everything we ask for, regardless of how easy it is to fix.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: 08 May 2019 20:34
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
I am generally opposed to the placeholder being used as the accessible name because I believe it will lead to the sole use of it as an accepted way of providing a name rather than a fallback. The placeholder should not act as a label and should act as a hint. By including it in the name it encourages it's acceptance as a label rather than a placeholder. It's called placeholder for a reason and not a label.
Would we accept the src of an image as fallback content for the alternative text of an image if no alt text was provided? What about the name attribute of an iFrame if no title or aria-label was provided?
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Detlev Fischer
Sent: Wednesday, May 8, 2019 3:29 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I seemed to remember placeholder has been included in the native HTML input name calc https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element <https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element> which @stevefaulkner has just confirmed - while the doc Accessible Name and Description Computation 1.2 https://w3c.github.io/accname/ <https://w3c.github.io/accname/> doesn't list it. So I am not sure why these sources are out of sync and which one should be considered authoritative...
> Am 08.05.2019 um 20:16 schrieb Steve Green < = EMAIL ADDRESS REMOVED = >:
>
> Chrome's browser developer tools contain an Accessibility tab that calculates the accessible name. That can be very helpful when testing convoluted code you didn't write yourself, but the computation appears to contain an error insofar as it uses the "placeholder" attribute.
>
> Bryan Garaventa's tool https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html does not use the "placeholder" attribute, and since he was an author of the Accessible Name and Description Computation 1.1 I am inclined to trust his implementation rather than Chrome's.
>
> It seems that the computation rules are ambiguous when they say "Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string". Chrome is interpreting the "placeholder" attribute as a text alternative but Bryan's tool isn't.
>
> Any thoughts on this?
>
> Regards,
> Steve Green
> Managing Director
> Test Partners Ltd
> 020 3002 4176 (direct)
> 0800 612 2780 (switchboard)
> 07957 246 276 (mobile)
> 020 7692 5517 (fax)
> Skype: testpartners
> = EMAIL ADDRESS REMOVED =
> www.testpartners.co.uk
>
> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>
> > > archives at http://webaim.org/discussion/archives
>
From: Patrick H. Lauke
Date: Wed, May 08 2019 1:50PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
On 08/05/2019 20:34, Jonathan Avila wrote:
> I am generally opposed to the placeholder being used as the accessible name because I believe it will lead to the sole use of it as an accepted way of providing a name rather than a fallback. The placeholder should not act as a label and should act as a hint. By including it in the name it encourages it's acceptance as a label rather than a placeholder. It's called placeholder for a reason and not a label.
For what it's worth, an input relying purely on placeholder will still
fail "Labels and Instructions" (because once filled in there's no more
"label or instruction" there at all) and arguably "Label in Name"
(again, once filled in, it has no apparent label but just its entered
value, and that's not part of the accessible 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
From: joe@a11yeval.com
Date: Wed, May 08 2019 2:12PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
Hi All,
According to Scott O'hara, Steve Faulker hasn't comment yet, but the answer is yes it is included as stated in the HTML Accessibility API Mappings 1.0 doc.
The Accessible Name and Description Computation 1.2 does not mention it specifically, but it mentions " Otherwise, if the current node's native markup provides an attribute (e.g. title)" from Step D.
The placeholder attribute is a native HTML attribute for <input> elements.
Thankx,
Joe Humbert
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Detlev Fischer
Sent: Wednesday, May 8, 2019 3:29 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
I seemed to remember placeholder has been included in the native HTML input name calc https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element <https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element> which @stevefaulkner has just confirmed - while the doc Accessible Name and Description Computation 1.2 https://w3c.github.io/accname/ <https://w3c.github.io/accname/> doesn't list it. So I am not sure why these sources are out of sync and which one should be considered authoritative...
> Am 08.05.2019 um 20:16 schrieb Steve Green < = EMAIL ADDRESS REMOVED = >:
>
> Chrome's browser developer tools contain an Accessibility tab that calculates the accessible name. That can be very helpful when testing convoluted code you didn't write yourself, but the computation appears to contain an error insofar as it uses the "placeholder" attribute.
>
> Bryan Garaventa's tool https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html does not use the "placeholder" attribute, and since he was an author of the Accessible Name and Description Computation 1.1 I am inclined to trust his implementation rather than Chrome's.
>
> It seems that the computation rules are ambiguous when they say "Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string". Chrome is interpreting the "placeholder" attribute as a text alternative but Bryan's tool isn't.
>
> Any thoughts on this?
>
> Regards,
> Steve Green
> Managing Director
> Test Partners Ltd
> 020 3002 4176 (direct)
> 0800 612 2780 (switchboard)
> 07957 246 276 (mobile)
> 020 7692 5517 (fax)
> Skype: testpartners
> = EMAIL ADDRESS REMOVED =
> www.testpartners.co.uk
>
> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>
> > > archives at http://webaim.org/discussion/archives
>
From: Detlev Fischer
Date: Wed, May 08 2019 2:26PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
@Jon Avila - I fully agree - my point was just to get clarity on the normative situation (would using placeholder PASS 3.3.2 while not being recommendable)
Sent from phone
> Am 08.05.2019 um 21:50 schrieb Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >:
>
>> On 08/05/2019 20:34, Jonathan Avila wrote:
>> I am generally opposed to the placeholder being used as the accessible name because I believe it will lead to the sole use of it as an accepted way of providing a name rather than a fallback. The placeholder should not act as a label and should act as a hint. By including it in the name it encourages it's acceptance as a label rather than a placeholder. It's called placeholder for a reason and not a label.
>
> For what it's worth, an input relying purely on placeholder will still fail "Labels and Instructions" (because once filled in there's no more "label or instruction" there at all) and arguably "Label in Name" (again, once filled in, it has no apparent label but just its entered value, and that's not part of the accessible 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
> > > >
From: Sailesh Panchang
Date: Wed, May 08 2019 2:34PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
The HTML 5 specs have always maintained:
The placeholder attribute represents a short hint (a word or short
phrase) intended to aid the user with data entry when the control has
no value.
The placeholder attribute should not be used as a replacement for a
<label>. For a longer hint or other advisory text, place the text next
to the control.
https://www.w3.org/TR/html5/sec-forms.html#the-placeholder-attribute
Also see
https://lists.w3.org/Archives/Public/w3c-wai-gl/2014OctDec/0030.html
Thanks,
Sailesh
On 5/8/19, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> I am generally opposed to the placeholder being used as the accessible name
> because I believe it will lead to the sole use of it as an accepted way of
> providing a name rather than a fallback. The placeholder should not act as
> a label and should act as a hint. By including it in the name it encourages
> it's acceptance as a label rather than a placeholder. It's called
> placeholder for a reason and not a label.
>
> Would we accept the src of an image as fallback content for the alternative
> text of an image if no alt text was provided? What about the name attribute
> of an iFrame if no title or aria-label was provided?
>
> Jonathan
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Detlev Fischer
> Sent: Wednesday, May 8, 2019 3:29 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> I seemed to remember placeholder has been included in the native HTML input
> name calc
> https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element
> <https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element>
> which @stevefaulkner has just confirmed - while the doc Accessible Name and
> Description Computation 1.2 https://w3c.github.io/accname/
> <https://w3c.github.io/accname/> doesn't list it. So I am not sure why these
> sources are out of sync and which one should be considered authoritative...
>
>> Am 08.05.2019 um 20:16 schrieb Steve Green
>> < = EMAIL ADDRESS REMOVED = >:
>>
>> Chrome's browser developer tools contain an Accessibility tab that
>> calculates the accessible name. That can be very helpful when testing
>> convoluted code you didn't write yourself, but the computation appears to
>> contain an error insofar as it uses the "placeholder" attribute.
>>
>> Bryan Garaventa's tool
>> https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html
>> does not use the "placeholder" attribute, and since he was an author of
>> the Accessible Name and Description Computation 1.1 I am inclined to trust
>> his implementation rather than Chrome's.
>>
>> It seems that the computation rules are ambiguous when they say
>> "Otherwise, if the current node's native markup provides an attribute
>> (e.g. title) or element (e.g. HTML label) that defines a text alternative,
>> return that alternative in the form of a flat string". Chrome is
>> interpreting the "placeholder" attribute as a text alternative but Bryan's
>> tool isn't.
>>
>> Any thoughts on this?
>>
>> Regards,
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>> 020 3002 4176 (direct)
>> 0800 612 2780 (switchboard)
>> 07957 246 276 (mobile)
>> 020 7692 5517 (fax)
>> Skype: testpartners
>> = EMAIL ADDRESS REMOVED =
>> www.testpartners.co.uk
>>
>> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >
> > > http://webaim.org/discussion/archives
> > > > > >
--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Mobile: 571-344-1765
From: Jonathan Avila
Date: Wed, May 08 2019 2:37PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
It looks like the latest editors draft of the HTML Accessibility API mappings 1.0 includes placeholder in the name calculation. But to my knowledge that detail has not had a cross review by the Accessibility Guidelines working group.
https://w3c.github.io/html-aam/
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sailesh Panchang
Sent: Wednesday, May 8, 2019 4:34 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
The HTML 5 specs have always maintained:
The placeholder attribute represents a short hint (a word or short
phrase) intended to aid the user with data entry when the control has no value.
The placeholder attribute should not be used as a replacement for a <label>. For a longer hint or other advisory text, place the text next to the control.
https://www.w3.org/TR/html5/sec-forms.html#the-placeholder-attribute
Also see
https://lists.w3.org/Archives/Public/w3c-wai-gl/2014OctDec/0030.html
Thanks,
Sailesh
On 5/8/19, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> I am generally opposed to the placeholder being used as the accessible
> name because I believe it will lead to the sole use of it as an
> accepted way of providing a name rather than a fallback. The
> placeholder should not act as a label and should act as a hint. By
> including it in the name it encourages it's acceptance as a label
> rather than a placeholder. It's called placeholder for a reason and not a label.
>
> Would we accept the src of an image as fallback content for the
> alternative text of an image if no alt text was provided? What about
> the name attribute of an iFrame if no title or aria-label was provided?
>
> Jonathan
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Detlev Fischer
> Sent: Wednesday, May 8, 2019 3:29 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
>
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
>
> I seemed to remember placeholder has been included in the native HTML
> input name calc
> https://w3c.github.io/html-aam/#input-type-text-input-type-password-in
> put-type-search-input-type-tel-input-type-url-and-textarea-element
> <https://w3c.github.io/html-aam/#input-type-text-input-type-password-i
> nput-type-search-input-type-tel-input-type-url-and-textarea-element>
> which @stevefaulkner has just confirmed - while the doc Accessible
> Name and Description Computation 1.2 https://w3c.github.io/accname/
> <https://w3c.github.io/accname/> doesn't list it. So I am not sure why
> these sources are out of sync and which one should be considered authoritative...
>
>> Am 08.05.2019 um 20:16 schrieb Steve Green
>> < = EMAIL ADDRESS REMOVED = >:
>>
>> Chrome's browser developer tools contain an Accessibility tab that
>> calculates the accessible name. That can be very helpful when testing
>> convoluted code you didn't write yourself, but the computation
>> appears to contain an error insofar as it uses the "placeholder" attribute.
>>
>> Bryan Garaventa's tool
>> https://whatsock.github.io/w3c-alternative-text-computation/Editable%
>> 20Live%20Input%20AccName%20Test.html
>> does not use the "placeholder" attribute, and since he was an author
>> of the Accessible Name and Description Computation 1.1 I am inclined
>> to trust his implementation rather than Chrome's.
>>
>> It seems that the computation rules are ambiguous when they say
>> "Otherwise, if the current node's native markup provides an attribute
>> (e.g. title) or element (e.g. HTML label) that defines a text
>> alternative, return that alternative in the form of a flat string".
>> Chrome is interpreting the "placeholder" attribute as a text
>> alternative but Bryan's tool isn't.
>>
>> Any thoughts on this?
>>
>> Regards,
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>> 020 3002 4176 (direct)
>> 0800 612 2780 (switchboard)
>> 07957 246 276 (mobile)
>> 020 7692 5517 (fax)
>> Skype: testpartners
>> = EMAIL ADDRESS REMOVED =
>> www.testpartners.co.uk
>>
>> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Mobile: 571-344-1765
From: Steve Green
Date: Wed, May 08 2019 2:38PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
There are documents called "HTML Accessibility API Mappings 1.0" on GitHub and on the W3C website, but their content is different. The latter is called a Working Draft and appears to be the authoritative version at this time (the accessible name computation also aligns with the Accessible Name and Description Computation 1.1). The version on GitHub is called an Editor's Draft and I assume it will become the authoritative version and be migrated to the W3C website at some point.
If I am correct, the "placeholder" attribute is not currently included in the accessible name computation, but it will be in the future.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: 08 May 2019 21:12
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
Hi All,
According to Scott O'hara, Steve Faulker hasn't comment yet, but the answer is yes it is included as stated in the HTML Accessibility API Mappings 1.0 doc.
The Accessible Name and Description Computation 1.2 does not mention it specifically, but it mentions " Otherwise, if the current node's native markup provides an attribute (e.g. title)" from Step D.
The placeholder attribute is a native HTML attribute for <input> elements.
Thankx,
Joe Humbert
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Detlev Fischer
Sent: Wednesday, May 8, 2019 3:29 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
I seemed to remember placeholder has been included in the native HTML input name calc https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element <https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element> which @stevefaulkner has just confirmed - while the doc Accessible Name and Description Computation 1.2 https://w3c.github.io/accname/ <https://w3c.github.io/accname/> doesn't list it. So I am not sure why these sources are out of sync and which one should be considered authoritative...
> Am 08.05.2019 um 20:16 schrieb Steve Green < = EMAIL ADDRESS REMOVED = >:
>
> Chrome's browser developer tools contain an Accessibility tab that calculates the accessible name. That can be very helpful when testing convoluted code you didn't write yourself, but the computation appears to contain an error insofar as it uses the "placeholder" attribute.
>
> Bryan Garaventa's tool https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html does not use the "placeholder" attribute, and since he was an author of the Accessible Name and Description Computation 1.1 I am inclined to trust his implementation rather than Chrome's.
>
> It seems that the computation rules are ambiguous when they say "Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string". Chrome is interpreting the "placeholder" attribute as a text alternative but Bryan's tool isn't.
>
> Any thoughts on this?
>
> Regards,
> Steve Green
> Managing Director
> Test Partners Ltd
> 020 3002 4176 (direct)
> 0800 612 2780 (switchboard)
> 07957 246 276 (mobile)
> 020 7692 5517 (fax)
> Skype: testpartners
> = EMAIL ADDRESS REMOVED =
> www.testpartners.co.uk
>
> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>
> > > archives at http://webaim.org/discussion/archives
>
From: Jonathan Avila
Date: Wed, May 08 2019 2:40PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
Hi Detlev,
Whether it counts as an accessible name under SC 4.1.2 is a different question from SC 3.3.2 which is aimed at visual labels and instructions that are present to all users.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Detlev Fischer
Sent: Wednesday, May 8, 2019 4:26 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
@Jon Avila - I fully agree - my point was just to get clarity on the normative situation (would using placeholder PASS 3.3.2 while not being recommendable)
Sent from phone
> Am 08.05.2019 um 21:50 schrieb Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >:
>
>> On 08/05/2019 20:34, Jonathan Avila wrote:
>> I am generally opposed to the placeholder being used as the accessible name because I believe it will lead to the sole use of it as an accepted way of providing a name rather than a fallback. The placeholder should not act as a label and should act as a hint. By including it in the name it encourages it's acceptance as a label rather than a placeholder. It's called placeholder for a reason and not a label.
>
> For what it's worth, an input relying purely on placeholder will still fail "Labels and Instructions" (because once filled in there's no more "label or instruction" there at all) and arguably "Label in Name" (again, once filled in, it has no apparent label but just its entered value, and that's not part of the accessible 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
> > > archives at http://webaim.org/discussion/archives
>
From: Detlev Fischer
Date: Wed, May 08 2019 2:44PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
True! And I agree that on its own (without visible label or floating label) ir would fail 3.3.2 (as Patrick also pointed out). Was just trying to understand the mismatch between the accname spec and the HTML API spec - which @jnurthen on twitter has cleared up by pointing to https://github.com/w3c/accname/issues/17
> Whether it counts as an accessible name under SC 4.1.2 is a different question from SC 3.3.2 which is aimed at visual labels and instructions that are present to all users.
>
From: glen walker
Date: Wed, May 08 2019 5:21PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
Joe, I think you need to finish the sentence from the spec regarding native
markup.
"Otherwise, if the current node's native markup provides an attribute (e.g.
title) or element (e.g. HTML label) **that defines a text alternative**..."
(emphasis mine)
So, yes, the placeholder attribute is a native markup attribute but it is
not an attribute that defines a text alternative. As several have noted,
it's hint and not a text alternative so shouldn't be included in the name
calculation.
On Wed, May 8, 2019 at 2:12 PM < = EMAIL ADDRESS REMOVED = > wrote:
>
> The Accessible Name and Description Computation 1.2 does not mention it
> specifically, but it mentions " Otherwise, if the current node's native
> markup provides an attribute (e.g. title)" from Step D.
>
> The placeholder attribute is a native HTML attribute for <input> elements.
>
> Thankx,
> Joe Humbert
>
>
From: glen walker
Date: Wed, May 08 2019 5:28PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
That sentence in step D has always bothered me.
"Otherwise, if the current node's native markup provides an attribute (e.g.
title)"
Why is the TITLE attribute given as an example in step D as a text
alternative? If you continue through the calculation to step I (eye), you
finally get to the lonely tooltip attribute, which is also the TITLE
attribute. So it's a bit confusing on when the TITLE attribute should be
used. Step D or step I?
From: Birkir R. Gunnarsson
Date: Wed, May 08 2019 9:08PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
That discussion doesn't make sense to me. They even talk about what
hapens if an element has title, placeholder and a non-empty value
attribute. I thought an input could never have both a visible
placeholder and a value and the placeholder attribute should not be
exposed by a screen reader as the input's accessible name when it is
not visible.
For one thing it creates a major inconsisency between the visible and
screen reader experience, for another, the recommended use of the
placeholder attribute makes it unsuitable for the element's accessible
name, for a third, an input with placeholder only text fails WCAG
3.3.2 (visible label) except in the rare cases where the field is
sufficiently labeled visually by an adjacent control (e.g. a search
input labeled by a search button).
I just don't like where this discussion is going, oh no precious, not
at all, Gollum.
On 5/8/19, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> That sentence in step D has always bothered me.
>
> "Otherwise, if the current node's native markup provides an attribute (e.g.
> title)"
>
> Why is the TITLE attribute given as an example in step D as a text
> alternative? If you continue through the calculation to step I (eye), you
> finally get to the lonely tooltip attribute, which is also the TITLE
> attribute. So it's a bit confusing on when the TITLE attribute should be
> used. Step D or step I?
> > > > >
--
Work hard. Have fun. Make history.
From: Detlev Fischer
Date: Wed, May 08 2019 11:34PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
Tangential to this discussion is the case, which I see more often, of the search field made visible once a search button has been activated, a field which has no further label and may not be anywhere near the search button, and which may have a placeholder (more Ofen just a text cursor). You could argue that since it is only brought about after the user action and intent of searching, it wouldn't require a label as much as other fields. But I just throw this in to contemplate.
Sent from phone
> Am 09.05.2019 um 05:08 schrieb Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = >:
>
> That discussion doesn't make sense to me. They even talk about what
> hapens if an element has title, placeholder and a non-empty value
> attribute. I thought an input could never have both a visible
> placeholder and a value and the placeholder attribute should not be
> exposed by a screen reader as the input's accessible name when it is
> not visible.
> For one thing it creates a major inconsisency between the visible and
> screen reader experience, for another, the recommended use of the
> placeholder attribute makes it unsuitable for the element's accessible
> name, for a third, an input with placeholder only text fails WCAG
> 3.3.2 (visible label) except in the rare cases where the field is
> sufficiently labeled visually by an adjacent control (e.g. a search
> input labeled by a search button).
> I just don't like where this discussion is going, oh no precious, not
> at all, Gollum.
>
>
>> On 5/8/19, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>> That sentence in step D has always bothered me.
>>
>> "Otherwise, if the current node's native markup provides an attribute (e.g.
>> title)"
>>
>> Why is the TITLE attribute given as an example in step D as a text
>> alternative? If you continue through the calculation to step I (eye), you
>> finally get to the lonely tooltip attribute, which is also the TITLE
>> attribute. So it's a bit confusing on when the TITLE attribute should be
>> used. Step D or step I?
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > >
From: Steve Green
Date: Thu, May 09 2019 3:12AM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
Perhaps step I is intended for non-HTML languages where the tooltip is provided by some means other than the "title" attribute.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: 09 May 2019 00:29
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
That sentence in step D has always bothered me.
"Otherwise, if the current node's native markup provides an attribute (e.g.
title)"
Why is the TITLE attribute given as an example in step D as a text alternative? If you continue through the calculation to step I (eye), you finally get to the lonely tooltip attribute, which is also the TITLE attribute. So it's a bit confusing on when the TITLE attribute should be used. Step D or step I?
From: Steve Green
Date: Thu, May 09 2019 3:18AM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
The change log at https://w3c.github.io/html-aam/#a-1-change-log shows that placeholder was removed from the computation in 2016 and reintroduced this year. This change does not yet appear on the W3C website, so I guess it's not official yet, but I don't really understand the status of the GitHub website.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: 09 May 2019 00:22
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
Joe, I think you need to finish the sentence from the spec regarding native markup.
"Otherwise, if the current node's native markup provides an attribute (e.g.
title) or element (e.g. HTML label) **that defines a text alternative**..."
(emphasis mine)
So, yes, the placeholder attribute is a native markup attribute but it is not an attribute that defines a text alternative. As several have noted, it's hint and not a text alternative so shouldn't be included in the name calculation.
On Wed, May 8, 2019 at 2:12 PM < = EMAIL ADDRESS REMOVED = > wrote:
>
> The Accessible Name and Description Computation 1.2 does not mention
> it specifically, but it mentions " Otherwise, if the current node's
> native markup provides an attribute (e.g. title)" from Step D.
>
> The placeholder attribute is a native HTML attribute for <input> elements.
>
> Thankx,
> Joe Humbert
>
>
From: Mallory
Date: Thu, May 09 2019 4:06AM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
I have seen pages suggesting that single-input search fields with the submits labelled "search" are practically (but not technically) labelled by the submits. Sometimes the control you click to reveal the field is the submit button.
I dislike the pattern for other reasons, but that argument generally about one input + submit does stick in my head.
I have seen these which are verbosity-overloads:
```<form... role="search">
<fieldset>
<legend>Search</legend> (visually hidden)
<label for="searchID">Search</label> (hidden visually)
<input type="search" id="searchID" placeholder="find your [x] on [website.com]" title="find your [x] on [website.com]">
<button aria-label="Submit search">[picture of a circle with a tail]</button>
</fieldset>
</form>```
The mismatch with the placeholders/titles is really common for some reason.
_mallory
On Thu, May 9, 2019, at 7:34 AM, Detlev Fischer wrote:
> Tangential to this discussion is the case, which I see more often, of
> the search field made visible once a search button has been activated,
> a field which has no further label and may not be anywhere near the
> search button, and which may have a placeholder (more Ofen just a text
> cursor). You could argue that since it is only brought about after the
> user action and intent of searching, it wouldn't require a label as
> much as other fields. But I just throw this in to contemplate.
>
> Sent from phone
>
> > Am 09.05.2019 um 05:08 schrieb Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = >:
> >
> > That discussion doesn't make sense to me. They even talk about what
> > hapens if an element has title, placeholder and a non-empty value
> > attribute. I thought an input could never have both a visible
> > placeholder and a value and the placeholder attribute should not be
> > exposed by a screen reader as the input's accessible name when it is
> > not visible.
> > For one thing it creates a major inconsisency between the visible and
> > screen reader experience, for another, the recommended use of the
> > placeholder attribute makes it unsuitable for the element's accessible
> > name, for a third, an input with placeholder only text fails WCAG
> > 3.3.2 (visible label) except in the rare cases where the field is
> > sufficiently labeled visually by an adjacent control (e.g. a search
> > input labeled by a search button).
> > I just don't like where this discussion is going, oh no precious, not
> > at all, Gollum.
> >
> >
> >> On 5/8/19, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> >> That sentence in step D has always bothered me.
> >>
> >> "Otherwise, if the current node's native markup provides an attribute (e.g.
> >> title)"
> >>
> >> Why is the TITLE attribute given as an example in step D as a text
> >> alternative? If you continue through the calculation to step I (eye), you
> >> finally get to the lonely tooltip attribute, which is also the TITLE
> >> attribute. So it's a bit confusing on when the TITLE attribute should be
> >> used. Step D or step I?
> >> > >> > >> > >> > >>
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > > > >
> > > > >
From: Steve Faulkner
Date: Thu, May 09 2019 5:03AM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
placeholder was added back in to reflect the reality that browsers expose
placeholder as an accessible name in the absence of other sources for it.
Whether one agrees or not with its inclusion, if browsers implement
something and cannot be convinced to change it, we as spec writers document
what is implemented. there is a related ARIA thread which may be of
interest https://github.com/w3c/accname/issues/17
As far as what spec to look at, the living spec
https://w3c.github.io/html-aam/ is probably most accurate and the one to
file issues on
--
Regards
SteveF
Accessibility is political[image: â]
Working for the web
<https://twitter.com/stevefaulkner/status/940835584410574850>,
anywhere and everywhere [image: ðð½]
On Thu, 9 May 2019 at 10:18, Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:
> The change log at https://w3c.github.io/html-aam/#a-1-change-log shows
> that placeholder was removed from the computation in 2016 and reintroduced
> this year. This change does not yet appear on the W3C website, so I guess
> it's not official yet, but I don't really understand the status of the
> GitHub website.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> glen walker
> Sent: 09 May 2019 00:22
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
>
> Joe, I think you need to finish the sentence from the spec regarding
> native markup.
>
> "Otherwise, if the current node's native markup provides an attribute (e.g.
> title) or element (e.g. HTML label) **that defines a text alternative**..."
> (emphasis mine)
>
> So, yes, the placeholder attribute is a native markup attribute but it is
> not an attribute that defines a text alternative. As several have noted,
> it's hint and not a text alternative so shouldn't be included in the name
> calculation.
>
>
> On Wed, May 8, 2019 at 2:12 PM < = EMAIL ADDRESS REMOVED = > wrote:
>
> >
> > The Accessible Name and Description Computation 1.2 does not mention
> > it specifically, but it mentions " Otherwise, if the current node's
> > native markup provides an attribute (e.g. title)" from Step D.
> >
> > The placeholder attribute is a native HTML attribute for <input>
> elements.
> >
> > Thankx,
> > Joe Humbert
> >
> >
> > > at http://webaim.org/discussion/archives
> > > > > >
From: Steve Green
Date: Thu, May 09 2019 6:03AM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
Thanks for the explanation for the change. However, it is still not at all clear how anyone is supposed to know which is the definitive version of the spec when there are similar, but different, versions with the same version number on different websites. I would have thought that the W3C website contains the definitive version but apparently not.
This really does need to be made very clear because when we conduct WCAG audits we make recommendations for changes that cost time and money to implement, not to mention the political cost of persuading stakeholders that the changes are necessary. This is made all the more difficult if people opposed to the changes can point to documents that appear to contradict us.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Faulkner
Sent: 09 May 2019 12:03
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
placeholder was added back in to reflect the reality that browsers expose placeholder as an accessible name in the absence of other sources for it.
Whether one agrees or not with its inclusion, if browsers implement something and cannot be convinced to change it, we as spec writers document what is implemented. there is a related ARIA thread which may be of interest https://github.com/w3c/accname/issues/17
As far as what spec to look at, the living spec https://w3c.github.io/html-aam/ is probably most accurate and the one to file issues on
--
Regards
SteveF
Accessibility is political[image: â]
Working for the web
<https://twitter.com/stevefaulkner/status/940835584410574850>,
anywhere and everywhere [image: ðð½]
On Thu, 9 May 2019 at 10:18, Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:
> The change log at https://w3c.github.io/html-aam/#a-1-change-log shows
> that placeholder was removed from the computation in 2016 and
> reintroduced this year. This change does not yet appear on the W3C
> website, so I guess it's not official yet, but I don't really
> understand the status of the GitHub website.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> glen walker
> Sent: 09 May 2019 00:22
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
>
> Joe, I think you need to finish the sentence from the spec regarding
> native markup.
>
> "Otherwise, if the current node's native markup provides an attribute (e.g.
> title) or element (e.g. HTML label) **that defines a text alternative**..."
> (emphasis mine)
>
> So, yes, the placeholder attribute is a native markup attribute but it
> is not an attribute that defines a text alternative. As several have
> noted, it's hint and not a text alternative so shouldn't be included
> in the name calculation.
>
>
> On Wed, May 8, 2019 at 2:12 PM < = EMAIL ADDRESS REMOVED = > wrote:
>
> >
> > The Accessible Name and Description Computation 1.2 does not mention
> > it specifically, but it mentions " Otherwise, if the current node's
> > native markup provides an attribute (e.g. title)" from Step D.
> >
> > The placeholder attribute is a native HTML attribute for <input>
> elements.
> >
> > Thankx,
> > Joe Humbert
> >
> >
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
From: Birkir R. Gunnarsson
Date: Thu, May 09 2019 6:34AM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
Why can't the placeholder be mapped to an accessible description
instead of an accessible name?
Its definition and recommended use case are not to provide a name for
the field, I mean, "01/01/2000" is not a sufficient accessible name
for "Send on date".
What happens when the placeholder text has been replaced by an actual
value, is it still going to be announced if there is another source of
accessible name? What if not?
I mean "01/01/2000" "04/09/2019" (place holder / value" is downright
nonsensical to a user, much worse than having no accessible name at
all.
I think allowing the placeholder attribute as a source of an
accessible name for an input field is a dangerous path that is bad for
accessibility.
It makes accessibility auditing tools less effective (they can check
for the presence of what they believe to be an author intended
accessible name, but they cannot validate the content of that source".
It is bad for the users, placeholder text is not intended to be an
accessible name, but either an example input or interaction
instruction.
It creates further confusion if it is always announced whether it is
visible or not. when it is not visible it is usually because its
excessive, excessive verbosity it bad for screen reader usability.
It's confusing for developers. The biggest problems I run into working
with developers is how aria-labelledby and aria-describedby do not
respect visibility settings.
Maybe the browsers expose it, but it doesn't mean it should be
legitimized as accessible (passing WCAG 4.1.2), especially not as the
accessible name.
I think this is very close to legitimizing the name of the source file
of an image as its alt text, or at least the <figcaption> element as
the accessible name of an image in a figure.
Both are bad for accessibility.
On 5/9/19, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks for the explanation for the change. However, it is still not at all
> clear how anyone is supposed to know which is the definitive version of the
> spec when there are similar, but different, versions with the same version
> number on different websites. I would have thought that the W3C website
> contains the definitive version but apparently not.
>
> This really does need to be made very clear because when we conduct WCAG
> audits we make recommendations for changes that cost time and money to
> implement, not to mention the political cost of persuading stakeholders that
> the changes are necessary. This is made all the more difficult if people
> opposed to the changes can point to documents that appear to contradict us.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve
> Faulkner
> Sent: 09 May 2019 12:03
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
>
> placeholder was added back in to reflect the reality that browsers expose
> placeholder as an accessible name in the absence of other sources for it.
> Whether one agrees or not with its inclusion, if browsers implement
> something and cannot be convinced to change it, we as spec writers document
> what is implemented. there is a related ARIA thread which may be of interest
> https://github.com/w3c/accname/issues/17
>
> As far as what spec to look at, the living spec
> https://w3c.github.io/html-aam/ is probably most accurate and the one to
> file issues on
>
> --
>
> Regards
>
> SteveF
> Accessibility is political[image: â]
> Working for the web
> <https://twitter.com/stevefaulkner/status/940835584410574850>,
> anywhere and everywhere [image: ðð½]
>
>
> On Thu, 9 May 2019 at 10:18, Steve Green < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> The change log at https://w3c.github.io/html-aam/#a-1-change-log shows
>> that placeholder was removed from the computation in 2016 and
>> reintroduced this year. This change does not yet appear on the W3C
>> website, so I guess it's not official yet, but I don't really
>> understand the status of the GitHub website.
>>
>> Steve
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
>> glen walker
>> Sent: 09 May 2019 00:22
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
>>
>> Joe, I think you need to finish the sentence from the spec regarding
>> native markup.
>>
>> "Otherwise, if the current node's native markup provides an attribute
>> (e.g.
>> title) or element (e.g. HTML label) **that defines a text
>> alternative**..."
>> (emphasis mine)
>>
>> So, yes, the placeholder attribute is a native markup attribute but it
>> is not an attribute that defines a text alternative. As several have
>> noted, it's hint and not a text alternative so shouldn't be included
>> in the name calculation.
>>
>>
>> On Wed, May 8, 2019 at 2:12 PM < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> >
>> > The Accessible Name and Description Computation 1.2 does not mention
>> > it specifically, but it mentions " Otherwise, if the current node's
>> > native markup provides an attribute (e.g. title)" from Step D.
>> >
>> > The placeholder attribute is a native HTML attribute for <input>
>> elements.
>> >
>> > Thankx,
>> > Joe Humbert
>> >
>> >
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > http://webaim.org/discussion/archives
> > > > > >
--
Work hard. Have fun. Make history.
From: Mallory
Date: Fri, May 10 2019 5:07AM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
I feel this is a general problem with "compliance" recommendations. I know clients
ask for it, and it's often what they are paying for-- but it would be better if as a
general industry we could say "our standards are that WCAG is a minimum and
non-WCAG UX considerations are always part of our recommendations."
(up front so anyone asking for minimum compliance knows this is what they're
going to get no matter who they turn to.)
In this case, there's a handful of regular UX problems with placeholders, like
their tendency to vanish and be low-contrast OR appear as a pre-filled default
value. So it seems easier if, regardless if a UA+AT is able to extract an accessible
name from a placeholder, we could recommend to simply not use them to
clients, even those who only want to toe the WCAG AA line. Toeing the WCAG
AA line just seems almost unethical in so many cases-- I often mentally transfer
it to fire codes. People only implement stuff because "it's in the fire code" and
don't necessarily actually care about people's safety, but inspectors would still
ideally consider efforts to only just meet the bare minimum as mildly unethical
and recommend something more.
If we could take this position globally as an industry, then differences in specs
like this example would matter less and maybe cause less hair loss on our end.
cheers,
_mallory
> On 5/9/19, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> > This really does need to be made very clear because when we conduct WCAG
> > audits we make recommendations for changes that cost time and money to
> > implement, not to mention the political cost of persuading stakeholders that
> > the changes are necessary. This is made all the more difficult if people
> > opposed to the changes can point to documents that appear to contradict us.
> >
> > Steve
From: Patrick H. Lauke
Date: Fri, May 10 2019 1:23PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
On 10/05/2019 12:07, Mallory wrote:
[...]
> In this case, there's a handful of regular UX problems with placeholders, like
> their tendency to vanish and be low-contrast OR appear as a pre-filled default
> value. So it seems easier if, regardless if a UA+AT is able to extract an accessible
> name from a placeholder, we could recommend to simply not use them to
> clients, even those who only want to toe the WCAG AA line.
As reliance just on placeholder already fails 2.5.3 Label in Name and
3.3.2 Labels or Instructions (as soon as the placeholder text isn't
visible), and as you mentioned probably 1.4.3 Contrast (in some browsers
anyway), it shouldn't be too hard of a problem to discourage their use.
The fact remains that most (?) modern browsers also use/expose
placeholder text for their accessible name calculation, so matching
reality, I'm not sure why we're so keen on digging our heels in with a
"but the accessible name calculation algorithm doesn't explicitly
mention this" (considering the algo is, to some extent, handwavy about it)
And yes, it's nice when it's crystal clear directly in the specs whether
something is unambiguously a pass or a fail...but what counts is the end
result here, and if in most browser/AT combos placeholder text IS used
as a name of last resort, then why try by hook or crook to say it fails?
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
From: Jim Homme
Date: Tue, May 14 2019 8:09AM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
Hi,
It is possible to use the :hover pseudo class to bring the contrast of the placeholder into the right contrast range. Also, if you are helping your client conform to WCAG 2.1, you need to deal with the Label In Name success criterion.
Thanks.
Jim
==========
Jim Homme
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
Sent: Friday, May 10, 2019 3:24 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Placeholder and Accessible Name Computation
On 10/05/2019 12:07, Mallory wrote:
[...]
> In this case, there's a handful of regular UX problems with
> placeholders, like their tendency to vanish and be low-contrast OR
> appear as a pre-filled default value. So it seems easier if,
> regardless if a UA+AT is able to extract an accessible name from a
> placeholder, we could recommend to simply not use them to clients, even those who only want to toe the WCAG AA line.
As reliance just on placeholder already fails 2.5.3 Label in Name and
3.3.2 Labels or Instructions (as soon as the placeholder text isn't visible), and as you mentioned probably 1.4.3 Contrast (in some browsers anyway), it shouldn't be too hard of a problem to discourage their use.
The fact remains that most (?) modern browsers also use/expose placeholder text for their accessible name calculation, so matching reality, I'm not sure why we're so keen on digging our heels in with a "but the accessible name calculation algorithm doesn't explicitly mention this" (considering the algo is, to some extent, handwavy about it)
And yes, it's nice when it's crystal clear directly in the specs whether something is unambiguously a pass or a fail...but what counts is the end result here, and if in most browser/AT combos placeholder text IS used as a name of last resort, then why try by hook or crook to say it fails?
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
From: Mallory
Date: Tue, May 14 2019 10:43AM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | Next message →
I can't hover most touchscreens (luckily I can on this laptop).
On Tue, May 14, 2019, at 4:09 PM, Jim Homme wrote:
> Hi,
> It is possible to use the :hover pseudo class to bring the contrast of
> the placeholder into the right contrast range. Also, if you are helping
> your client conform to WCAG 2.1, you need to deal with the Label In
> Name success criterion.
>
> Thanks.
>
> Jim
>
>
>
> ==========
> Jim Homme
> Digital Accessibility
> Bender Consulting Services
> 412-787-8567
> https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
From: Birkir R. Gunnarsson
Date: Tue, May 14 2019 1:10PM
Subject: Re: Placeholder and Accessible Name Computation
← Previous message | No next message
Typically placeholder text with proper color contrast looks like
actual input. That creates significant usability issues because people
think they've already filled in the field or that the webpage has
filled it in for them.
This is one of the primary reasons placeholder is widely discouraged
On 5/14/19, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
> I can't hover most touchscreens (luckily I can on this laptop).
>
> On Tue, May 14, 2019, at 4:09 PM, Jim Homme wrote:
>> Hi,
>> It is possible to use the :hover pseudo class to bring the contrast of
>> the placeholder into the right contrast range. Also, if you are helping
>> your client conform to WCAG 2.1, you need to deal with the Label In
>> Name success criterion.
>>
>> Thanks.
>>
>> Jim
>>
>>
>>
>> ==========
>> Jim Homme
>> Digital Accessibility
>> Bender Consulting Services
>> 412-787-8567
>> https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
> > > > >
--
Work hard. Have fun. Make history.