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

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.  
Sailesh Panchang

On Fri, 1/13/17, Mike Elledge <> wrote:

 Subject: Re: Re[2]: Should we require labels to be always visible?
 To: "David MacDonald" <>, "White, Jason J" <>
 Cc: "Glenda Sims" <>, "Andrew Kirkpatrick" <>, "" <>, "lisa.seeman" <>, "Detlev Fischer" <>, "WCAG" <>
 Date: Friday, January 13, 2017, 4:35 PM
 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
 <input type="submit" value="Search"
 and aXe both pass it...could the submit button text be
 considered a visible label?
    On Friday, January
 13, 2017 4:05 PM, David MacDonald
 <> 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.
 David MacDonald CanAdapt Solutions
 Inc.Tel:  613.235.4902LinkedIn    Adapting the web
 to all users            Including those with
 If you are not the intended recipient,
 please review our privacy
 On Fri, Jan 13, 2017 at
 3:37 PM, White, Jason J <>
 From: Glenda Sims []
 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
 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
 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
  on the field) is enough to pass - so long as a label is
 always programmatically
 [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
 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
 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
 Thank you for your compliance.

Received on Saturday, 14 January 2017 02:37:00 UTC