- From: David MacDonald <david100@sympatico.ca>
- Date: Thu, 9 Aug 2018 14:03:33 -0400
- To: Mike Elledge <melledge@yahoo.com>
- Cc: "Newton, Brooks (Legal)" <Brooks.Newton@thomsonreuters.com>, Glenda Sims <glenda.sims@deque.com>, Eric Eggert <ee@w3.org>, "Schnabel, Stefan" <stefan.schnabel@sap.com>, "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAAdDpDbdTNrnR38V827Bwzac5UfRBgCf4UiZvMi=Ducbz3xymg@mail.gmail.com>
> there are some implementations where it moves above the input field to remain visible, which would seem to make it compliant--unless I've missed something. The current proposed title is "Failure of SC 3.3.2 due to using the HTML placeholder attribute for a label on form fields" Floating labels don't use the HTML placeholder attribute, and could not. Cheers, David MacDonald *Can**Adapt* *Solutions Inc.* Tel: 613.235.4902 LinkedIn <http://www.linkedin.com/in/davidmacdonald100> twitter.com/davidmacd GitHub <https://github.com/DavidMacDonald> www.Can-Adapt.com <http://www.can-adapt.com/> * Adapting the web to all users* * Including those with disabilities* If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html> On Thu, Aug 9, 2018 at 1:31 PM, Mike Elledge <melledge@yahoo.com> wrote: > Hi David-- > > It would be clearer to me, at least, since there are some implementations > where it moves above the input field to remain visible, which would seem to > make it compliant--unless I've missed something. > > Thanks for the testing comment as well-- > > Mike > > On Thursday, August 9, 2018, 12:08:40 PM EDT, David MacDonald < > david100@sympatico.ca> wrote: > > > > Wouldn't the failure also have to include "when the placeholder > disappears on focus" or some such? > > The html placeholder attribute disappears on focus by design, so I think > its Ok, but I'm fine with making the title longer if it will be clearer to > some. > > > Also, a bit tangential, is anyone else having problems with the latest > FF and JAWS versions not working well together? I'm finding that keystroke > navigation (h, l, etc.) doesn't work. > > I don't test JAWS with FF, I'd use Chrome, and fallback to IE ... > > I will often use NVDA with FF > > Cheers, > David MacDonald > > > > *Can**Adapt* *Solutions Inc.* > > Tel: 613.235.4902 > > LinkedIn > <http://www.linkedin.com/in/davidmacdonald100> > > twitter.com/davidmacd > > GitHub <https://github.com/DavidMacDonald> > > www.Can-Adapt.com <http://www.can-adapt.com/> > > > > * Adapting the web to all users* > * Including those with disabilities* > > If you are not the intended recipient, please review our privacy policy > <http://www.davidmacd.com/disclaimer.html> > > On Thu, Aug 9, 2018 at 11:12 AM, Mike Elledge <melledge@yahoo.com> wrote: > > Hi David-- > > Wouldn't the failure also have to include "when the placeholder disappears > on focus" or some such? > > Also, a bit tangential, is anyone else having problems with the latest FF > and JAWS versions not working well together? I'm finding that keystroke > navigation (h, l, etc.) doesn't work. > > Mike Elledge > > On Thursday, August 9, 2018, 10:52:23 AM EDT, David MacDonald < > david100@sympatico.ca> wrote: > > > It might make sense to add a failure: > > "Failure of SC 3.3.2 due to using the HTML placeholder attribute for a > label on form fields" > > I could write that up and do a pull request on Github. > > Cheers, > David MacDonald > > > > *Can**Adapt* *Solutions Inc.* > > Tel: 613.235.4902 > > LinkedIn > <http://www.linkedin.com/in/davidmacdonald100> > > twitter.com/davidmacd > > GitHub <https://github.com/DavidMacDonald> > > www.Can-Adapt.com <http://www.can-adapt.com/> > > > > * Adapting the web to all users* > * Including those with disabilities* > > If you are not the intended recipient, please review our privacy policy > <http://www.davidmacd.com/disclaimer.html> > > On Thu, Aug 9, 2018 at 9:41 AM, Newton, Brooks (Legal) <Brooks.Newton@thomsonreuters. > com <Brooks.Newton@thomsonreuters.com>> wrote: > > Thank you, David, for the excellent write up and explanation of how > placeholder works with current user agent and assistive technology > combinations. Also, thanks for providing clarity on the intent of SC > 3.3.2. I’ve got your blog post bookmarked. > > > > Also, many thanks to Stefan, Andrew, Glenda, Jon, Patrick and Eric for the > valuable contributions to this thread. Glenda, great summary of the issues > at play with using placeholder text. My understanding of this topic is > substantially improved having read everyone’s thoughts on this subject. > > > > Brooks > > > > *From:* David MacDonald [mailto:david100@sympatico.ca] > *Sent:* Wednesday, August 08, 2018 8:09 PM > *To:* Glenda Sims <glenda.sims@deque.com> > *Cc:* Eric Eggert <ee@w3.org>; Schnabel, Stefan <stefan.schnabel@sap.com>; > Patrick H. Lauke <redux@splintered.co.uk>; WCAG <w3c-wai-gl@w3.org> > *Subject:* Re: Bug: Firefox Accessibility Inspector reports placeholder > attribute as eligible for accessible name > > > > I've done some testing and posted the results on Placeholder and offer my > opinion on what WCAG says, and my memories of what 3.3.2 meant when we were > writing it. > > > > http://davidmacd.com/blog/is- placeholder-accessible-label. html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__davidmacd.com_blog_is-2Dplaceholder-2Daccessible-2Dlabel.html&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=u1jVO0Q2MaEBF_n7bkWBDdilqcK3chxASBjOA3oWrFY&e=> > > > > > > > Cheers, > David MacDonald > > > > *Can**Adapt* *Solutions Inc.* > > Tel: 613.235.4902 > > LinkedIn > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_davidmacdonald100&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=2G0PyiGOzGRrFbuCwET8RhiOp8RfowVS80MS8_LCsr0&e=> > > twitter.com/davidmacd > <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_davidmacd&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=XVKYwoQDl-OoIjHd9u4g0wrSxWvDyF6cI4UDrW03Co8&e=> > > GitHub > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DavidMacDonald&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=nLvM6DdDGExUWgl0kyX-hQnIvpOYvorGSmVsA8XHiGg&e=> > > www.Can-Adapt.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.can-2Dadapt.com_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=ldO9OG2YJi6pITnxqcnYFgcRBvIFCWKbzCco7Sd1nQo&e=> > > > > * Adapting the web to all users* > > * Including those with disabilities* > > > > If you are not the intended recipient, please review our privacy policy > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidmacd.com_disclaimer.html&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=2qu5zad5mgom20h3CmKsd3xGPHB4A8PzGNx9Jb6Bs8Q&e=> > > > > On Wed, Aug 8, 2018 at 8:37 PM, Glenda Sims <glenda.sims@deque.com> wrote: > > I think I can find a11y peace with the thought of placeholder being (as a > last ditch choice) allowed to serve as accessible name. And agreeing with > Jon Avila that that placeholder value serving as an accessible name needs > to be meaningful as a label. > > > > Eric, Patrick, is it still valid for me to ask for F68 to be updated to > include placeholder? https://www.w3. org/TR/2016/NOTE-WCAG20-TECHS- > 20161007/F68 <https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F68> > > > > And if placeholder can be an accessible name, then my dang codepen example > would pass WCAG 2.1 SC 2.5.3 Label in Name (sigh) > > > > And then failing my codepen on SC 3.3.2 Labels or Instructions (when the > placeholder disappears and there is no visible label). (nodding in > agreement to Brooks) > > > > Thanks for entertaining this question and helping me see more clearly. > > G > > > *glenda sims* <glenda.sims@deque.com>, cpacc > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accessibilityassociation.org_certification&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=GFDnfNnBOfxgySz7U9F_swJk6GzEL15VaWMs1A1HTu0&e=> > | team a11y lead | 512.963.3773 > > > > deque systems > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.deque.com&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=89tIR9rgOqPHeKvm6bmrWc6H3w7ZcOMstQMM28gVfyI&e=> > accessibility for good > > > > On Wed, Aug 8, 2018 at 4:24 PM, Eric Eggert <ee@w3.org> wrote: > > <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 <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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__codepen.io_goodwitch_pen_OwEmEw&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=9YAF65uCv_JYHHvpkD-8DGB2LG8uMi-GrKtBnGa482c&e=> > > 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 > <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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accessibilityassociation.org_certification&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=GFDnfNnBOfxgySz7U9F_swJk6GzEL15VaWMs1A1HTu0&e=> > | team a11y lead | 512.963.3773 > > > > deque systems > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.deque.com&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=89tIR9rgOqPHeKvm6bmrWc6H3w7ZcOMstQMM28gVfyI&e=> > 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://urldefense.proofpoint.com/v2/url?u=http-3A__www.splintered.co.uk&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=h-ZNT83pqNejSsSuqfErEuL50yBDI_GH6HTF9zMiyC8&e=> > | https://github.com/ patrickhlauke > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_patrickhlauke&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=wZXWcWpGzfAVHn_HHwhYjU5QBof7XvWf0aK8goDcv3Y&e=> > http://flickr.com/photos/ redux/ > <https://urldefense.proofpoint.com/v2/url?u=http-3A__flickr.com_photos_redux_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=3EVXJjI8y_32BP1G4xoJRWjr_ZIDRIfPQgplCweoVf4&e=> > | http://redux.deviantart.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__redux.deviantart.com&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=tn3Zye3R_PBJ2o8yLqfYtSRbqvAzByfmpy1CLSlllCM&s=3CL1hckKHQ-5aKRSTKQQ7OUhD3BH6jYiAGIl9_wDSto&e=> > twitter: @patrick_h_lauke | skype: patrick_h_lauke > > > > > > -- > > Eric Eggert > Web Accessibility Specialist > Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C) > > > > > > > >
Received on Thursday, 9 August 2018 18:04:01 UTC