Re: Re[2]: Should we require labels to be always visible?

I think there should be a mechanism available to show labels - such as support for  personalization:)

Basicly we need personalization here. It is a lot to ask designers to always show labels for controls , especially on small devices.
Hamburger menus and others benefit from labels but showing the label will really affect the look


However having an "show all labels" setting as a standardized option that should be included in a test suit is doable


Rich and I am working on personalization standard. I will add it there - and we can have a mechanism available for showing all labels  in wcag
\

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Sat, 14 Jan 2017 04:33:38 +0200 Sailesh Panchang<spanchang02@yahoo.com> wrote ---- 

Numerator/denominator type of fields are not different from multi-part fields I alluded to in my last email where a hyphen between textboxes serves as a visual cue. In the case of numerator / denominator fields, the slash does the same. It is standard practice to wrap The multi part fields within a fieldset with a suitable legend. 
With reference to:     <input type="search" placeholder="Search this site" aria-label="search this site"/> 
The values of the placeholder and aria-label are identical resulting in repetition for screen reader users. Why should accessibility consultant suggest something that will result in poorer experience for a set of users who depend on accessibility markup? 
The value of the placeholder / aria-label in the above example are better suited for the search button than the textbox. 
The placeholder is meant to contain a hint or such ... not state the purpose of the field. 
The title attribute is more robust serving a wider user group vis-a-vis the aria-label. 
Thanks, 
Sailesh Panchang 
 
-------------------------------------------- 
On Fri, 1/13/17, Mike Elledge <melledge@yahoo.com> wrote: 
 
 Subject: Re: Re[2]: Should we require labels to be always visible? 
 To: "David MacDonald" <david100@sympatico.ca>, "White, Jason J" <jjwhite@ets.org> 
 Cc: "Glenda Sims" <glenda.sims@deque.com>, "Andrew Kirkpatrick" <akirkpat@adobe.com>, "josh@interaccess.ie" <josh@interaccess.ie>, "lisa.seeman" <lisa.seeman@zoho.com>, "Detlev Fischer" <detlev.fischer@testkreis.de>, "WCAG" <w3c-wai-gl@w3.org> 
 Date: Friday, January 13, 2017, 4:35 PM 
 
 Hi 
 All-- 
 What 
 if an input field of type "search" has a 
 placeholder of "Search this page" associated with 
 a button labeled "Search", eg.: 
   
 <form role="search" class="inLine 
 search" > 
     
 <input type="search" placeholder="Search 
 this site" aria-label="search this 
 site"/> 
     
 <input type="submit" value="Search" 
 /> 
   
 </form> 
 
 
 WAVE 
 and aXe both pass it...could the submit button text be 
 considered a visible label? 
 
 Mike 
 
 
 
 
 On Friday, January 
 13, 2017 4:05 PM, David MacDonald 
 <david100@sympatico.ca> wrote: 
 
 
 I think the construct is 
 sufficiently comprehensible visually. The instructions/label 
 are 10 years of math classes ...  
 the aria-label should have 
 numerator and denominator in them. 
 Cheers, 
 David MacDonald CanAdapt Solutions 
 Inc.Tel:  613.235.4902LinkedIn  
 twitter.com/davidmacdGitHubwww.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 
 
 On Fri, Jan 13, 2017 at 
 3:37 PM, White, Jason J <jjwhite@ets.org> 
 wrote: 
 
 
 
 
 
 
 
 
   
   
 
 
 
 
 From: Glenda Sims [mailto:glenda.sims@deque.com] 
 
 
 Sent: Friday, January 6, 2017 1:54 PM 
 
 
 
 
 
 
 
 
 In my book, the label 
 can be an icon (or text).  Here is how I have our experts 
 consistently call this for 3.3.2 (with some thoughts related 
 to 1.3.1 and 4.1.2) 
 
 
 
 Label or 
 Instructions MUST be visible at all times to sighted 
 users. 
 An 
 icon (with appropriate alternative text) can serve as a 
 label. Examples of common icons that label form fields (or 
 user controls) include: magnifying glass (for search), 3 
 horizontal lines on top of each other (hamburger menu), gear 
 (preferences or settings), trash can (delete or view trash 
 depending on context). Remember, these are just a few 
 examples. 
 A 
 placeholder alone in a form field does not qualify as a 
 label for sighted users because it is not always present. 
 Note: A placeholder, then supplemented by a label (even if 
 the label does not visually appear until after the user 
 focuses 
 on the field) is enough to pass - so long as a label is 
 always programmatically 
 associated. 
 [Jason] An interesting example 
 that occurs here at ETS is a pair of fields for entering the 
 numerical numerator 
 and denominator of a fraction, arranged vertically and 
 separated by a visible fraction 
 line. 
 I assume that label elements or 
 aria-label attributes are used correctly to provide explicit 
 labels for assistive 
 technologies. The spatial layout of the fields and the 
 fraction line (in an educational setting) should be clear to 
 visual readers without the need for textual labels. This 
 example arguably doesn’t fall into your first category 
 (icons), although the intent 
 is similar. My inclination is to regard such examples as 
 sufficiently unambiguous to be worthy of satisfying any 
 proposed success criterion in this 
 area. 
   
 
 
 
 
 
 
 
 This e-mail and any files transmitted with it may 
 contain privileged or confidential information. It is solely 
 for use by the individual for whom it is intended, even if 
 addressed incorrectly. If you received this e-mail in error, 
 please notify the sender; 
 do not disclose, copy, distribute, or take any action in 
 reliance on the contents of this information; and delete it 
 from your system. Any other use of this e-mail is 
 prohibited. 
 
 
 Thank you for your compliance.