- From: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Date: Fri, 6 Jan 2017 17:35:14 +0000
- To: John Foliot <john.foliot@deque.com>, Andrew Kirkpatrick <akirkpat@adobe.com>
- CC: Shawn Lauriat <lauriat@google.com>, David MacDonald <david100@sympatico.ca>, "josh@interaccess.ie" <josh@interaccess.ie>, lisa.seeman <lisa.seeman@zoho.com>, Detlev Fischer <detlev.fischer@testkreis.de>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <DM5PR03MB278074E0A8F95380082DAE899B630@DM5PR03MB2780.namprd03.prod.outlook.com>
Ø I would be strongly in favor of a new (or modified/enhanced) SC requiring (RFC 2119<https://www.ietf.org/rfc/rfc2119.txt> – SHOULD I disagree with adding should into the requirement. The way “should” is taken in the RFC may be one thing but it will NOT be seen that way by most people in the real world. It will be seen as recommended but not required without people doing due diligence. Once we start having “should” in WCAG then we might as well not write the SC or make it a AAA as it won’t be done. The proper way to do this is the have an exception or is to define the definition in such a way that it allows for flexibility. I believe this is already required in the current WCAG based on the normative definition and note. Jonathan Jonathan Avila Chief Accessibility Officer SSB BART Group jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com> 703.637.8957 (Office) Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | LinkedIn<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/> Don't miss Trends in Accessibility & Electronic Documents on Wed 12/7!<http://info.ssbbartgroup.com/Accessibility-Trends-and-Documents.html?mkt_tok=eyJpIjoiWXpsak9XWTJNbUV5T1RneiIsInQiOiJzWWlWT2FiUnpjS1hOYmx5dzdHRUs1d0lcL2Y4VjBHU1EyRWZuSm40aFQ2TE51Zm4wUU9PaGowcGN4Nm5UdFhnMTVxUHFBSHAwR21BODV1UGc2TFloV1NaUFNvbE8wU05IV2> The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited. From: John Foliot [mailto:john.foliot@deque.com] Sent: Friday, January 06, 2017 12:12 PM To: Andrew Kirkpatrick Cc: Shawn Lauriat; David MacDonald; josh@interaccess.ie; lisa.seeman; Detlev Fischer; WCAG Subject: Re: Re[2]: Should we require labels to be always visible? > ...it has title=“search” and aria-label=“search”, does it need a visible label? Hi Andrew, I think there is a distinction between "NEED" and "SHOULD". In that particular (corner)case, likely not, no, but not because of the overarching requirement that form inputs always require labels; rather because this is a unique "page" that has a learned behavior reaction (you go to the homepage of the largest search engine on the planet, and put the search term into the one text input on the page). There will always be exceptions to the rule, but as a Principle ("Understandable") and a Guideline ("Help users avoid and correct mistakes.") those exceptions would be rare indeed. I would be strongly in favor of a new (or modified/enhanced) SC requiring (RFC 2119<https://www.ietf.org/rfc/rfc2119.txt> - SHOULD) visible form labels at all times, using any technique we've seen on this thread (or any other that meets the requirement). JF On Fri, Jan 6, 2017 at 10:51 AM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote: One of the other classic cases: https://www.google.com – it has title=“search” and aria-label=“search”, does it need a visible label? Thanks, AWK Andrew Kirkpatrick Group Product Manager, Standards and Accessibility Adobe akirkpat@adobe.com<mailto:akirkpat@adobe.com> http://twitter.com/awkawk From: Shawn Lauriat <lauriat@google.com<mailto:lauriat@google.com>> Date: Friday, January 6, 2017 at 11:45 To: David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> Cc: "josh@interaccess.ie<mailto:josh@interaccess.ie>" <josh@interaccess.ie<mailto:josh@interaccess.ie>>, "lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>" <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>, Detlev Fischer <detlev.fischer@testkreis.de<mailto:detlev.fischer@testkreis.de>>, WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Subject: Re: Re[2]: Should we require labels to be always visible? Resent-From: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Resent-Date: Friday, January 6, 2017 at 11:46 As my two cents, I would say always required, and beyond helping around cognitive and low-vision, to situational impairments: * If the browser helpfully fills in all fields, with duplicate entries in four of them, you have no way of knowing what data really belongs in which field. * If you start to fill out a form and then the phone rings, diverting your attention for an extended period, you won't remember the fields. Even if you just have focus in the field, the placeholder falls off. Beyond that, using placeholder as a label goes against HTML spec<https://www.w3.org/TR/2011/WD-html5-20110525/common-input-element-attributes.html#the-placeholder-attribute>. I know everyone does it these days, so I always say that the label should move from inside/over the input to above or next to it, so it remains visible. Limited space comes down to a design challenge, not a reason to forgo a visible label. -Shawn On Fri, Jan 6, 2017 at 11:26 AM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote: I would say it's already a best practice... Lisa, are those with cognitive disabilities likely to loose track of what the field label is, if it disappears after they click on it? Is that a common complaint out in the wild about placeholder text for labels? Cheers, David MacDonald CanAdapt Solutions Inc. Tel: 613.235.4902<tel:(613)%20235-4902> LinkedIn <http://www.linkedin.com/in/davidmacdonald100> twitter.com/davidmacd<http://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 Fri, Jan 6, 2017 at 11:15 AM, josh@interaccess.ie<mailto:josh@interaccess.ie> <josh@interaccess.ie<mailto:josh@interaccess.ie>> wrote: <chair hat off> >Would it help the cognitive community if the label is always visible. I like the demo David :-) I couldn't see my clients wearing having to do that. On mobile, there are times when screen real estate is so sparse that at best you get an icon and placeholder text. I just don't think that would fly as a MUST, as best practice maybe. As long as it fits into the look and feel guidelines etc. My 2 cents Josh ------ Original Message ------ From: "Detlev Fischer" <detlev.fischer@testkreis.de<mailto:detlev.fischer@testkreis.de>> To: w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>; david100@sympatico.ca<mailto:david100@sympatico.ca> Sent: 06/01/2017 16:03:31 Subject: Re: Should we require labels to be always visible? That's one way of doing it, but there will be others. So the requirement might be EITHER have external visible label OR if using placeholder, show label next to field after focussing field. Note that some implementations keep the placeholder text visible even after focussing (mostly grey text) until you start typing, which I personally find confusing. Not sure whether some SC (COGA?) or technique addresses this yet. David MacDonald schrieb am 06.01.2017 16:51: Most of the sites I evaluate these days seem to have placeholder text for labels. An aria-label helps, but the label still disappears on focus or on clicking into the field. Would it help the cognitive community if the label is always visible. So for placeholder labels, should we require that the label appears near the field when the user clicks or tabs to the field? Like this? http://davidmacd.com/widgets/floating-label/floating-placeholder1.html <http://davidmacd.com/widgets/floating-label/floating-placeholder1.html> Cheers, David MacDonald CanAdapt Solutions Inc. Tel: 613.235.4902<tel:613.235.4902> LinkedIn <http://www.linkedin.com/in/davidmacdonald100> twitter.com/davidmacd<http://twitter.com/davidmacd> <http://twitter.com/davidmacd> GitHub <https://github.com/DavidMacDonald> www.Can-Adapt.com<http://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> -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com<mailto:john.foliot@deque.com> Advancing the mission of digital accessibility and inclusion
Received on Friday, 6 January 2017 17:35:50 UTC