- From: David MacDonald <david100@sympatico.ca>
- Date: Wed, 8 Aug 2018 21:09:05 -0400
- 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>
- Message-ID: <CAAdDpDZAo-RDuHx8rkeDPvMpqDuUYCwh=Sz=MLsY=UvjeCdLcQ@mail.gmail.com>
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 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 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 > > 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 > <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 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/WCA >> G21/#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 >> <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) >> > >
Received on Thursday, 9 August 2018 01:09:31 UTC