E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: Jennifer Sutton
Date: Tue, Jan 14 2014 3:54PM
Subject: labels on search buttons -- Drupal.org and Beyond
No previous message | Next message →

Greetings, WebAIM:

I was looking at this Drupal issue, filed against the Drupal.org site:

<https://drupal.org/node/2083561>https://drupal.org/node/2083561


And I wondered if any of you had input/might want to comment on it.

I was trying to do some research to confirm whether the search button
needs a label, and this WebAIM article made me think it might not,
i.e. via the heading 2 called Buttons:
http://webaim.org/techniques/forms/controls

Can anyone let me know and/or comment on the ticket?
Part of what's confusing me is that when I look at a range of
accessibility-related sites, some do have the label, while others don't.

Thanks.

Best,
Jennifer

From: Birkir R. Gunnarsson
Date: Tue, Jan 14 2014 6:55PM
Subject: Re: labels on search buttons -- Drupal.org and Beyond
← Previous message | Next message →

Greetings!

I am a bit confused here.
The issue title claims the problem is with the search button, but the
code indicates the missing label is on the search input field.
According to the search button on the issue page itself which seems to
suffer from precisely the same problem, (the URL referred to in the
issue description requires a username and password) the html looks
like this:
<input type="submit" class="form-submit" value="Search" name="op"
id="edit-submit">
This is fine, inputs of type submit require the descriptive attribute
to be the value, which it is.

If we are discussing the search text input field, it appears to have
no labelling except html5 placeholder text.
It has its drawbacks and is not recommended as an accessible
alternative to an explicit visible label
see: http://blog.paciellogroup.com/2011/02/html5-accessibility-chops-the-placeholder-attribute/
I agree with the recommendation of that page, add a title attribute
containing the placeholder text to the field.
Yes, it probably causes screen readers to read the label twice, since
the support for the placeholder attribute is on the rise, but it is
better than not reading it at all.
Remember that the title attribute suffers from some of the same issues
as placeholder for sighted keyboard only users, i.e. title only
appears visibly when mouse activated, so an explicit label, either
wrapping the field or using the for=id connection is always most
preferred.
If you want to go the screen reader route specifically aria-label
could be used in place of title, though it is even more restrictive
and screen reader support is still not quite there if we allow
ourselves to look reasonably far back.
In short, either
- wrap the <input> field in a <label> tag with the input field and the
label text
or
- put a title attribute on the <input> tag.

Cheers
Birkir Gunnarsson
Accessibility SME | Deque Systems


On 1/14/14, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> Greetings, WebAIM:
>
> I was looking at this Drupal issue, filed against the Drupal.org site:
>
> <https://drupal.org/node/2083561>https://drupal.org/node/2083561
>
>
> And I wondered if any of you had input/might want to comment on it.
>
> I was trying to do some research to confirm whether the search button
> needs a label, and this WebAIM article made me think it might not,
> i.e. via the heading 2 called Buttons:
> http://webaim.org/techniques/forms/controls
>
> Can anyone let me know and/or comment on the ticket?
> Part of what's confusing me is that when I look at a range of
> accessibility-related sites, some do have the label, while others don't.
>
> Thanks.
>
> Best,
> Jennifer
>
> > > >


--
Work hard. Have fun. Make history.

From: John Bickar
Date: Tue, Jan 14 2014 8:41PM
Subject: Re: labels on search buttons -- Drupal.org and Beyond
← Previous message | Next message →

Birkir,

Thanks!

My initial reply didn't make it to the list because I am
Mailman-challenged, so CCing back to the list.

-John Bickar
Stanford Web Services


On 1/14/14 7:00 PM, Birkir R. Gunnarsson wrote:
> Yeap.
> inputs of type submit or reset communicate the text label via their
> value attribute, that is sufficient and no further explicit labelling
> is needed.
> Input of type image requires a src attribute and an alt attribute to
> function, the alt attribute provides the textual label.
> http://www.jimthatcher.com/webcourse8.htm
> This is a few years old, but is definitely a classic.
> Cheers
> Birkir Gunnarsson
> Accessibility SME | Deqe Systems
>
>
>
> On 1/14/14, John Bickar < = EMAIL ADDRESS REMOVED = > wrote:
>> Hi,
>>
>> Thank you for clarifying this. The linked issue from drupal.org is
>> tangentially related to what we are trying to solve (and it's
>> understandable that you are confused by it), but it's not the precise
>> issue.
>>
>> This part is edifying, and what we were looking for:
>>
>>> <input type="submit" class="form-submit" value="Search" name="op"
>>> id="edit-submit">
>>> This is fine, inputs of type submit require the descriptive attribute
>>> to be the value, which it is.
>>
>> So there does *not* need to be a <label> element, like so?
>>
>> <label for="edit-submit">Search</label>
>>
>> Jennifer and I have been banging our heads against this for a little
>> while, trying to find a definitive answer.
>>
>> Here's a different link, containing a search box built with Drupal:
>> https://vpge.stanford.edu/
>>
>> Direct link to submit input: https://vpge.stanford.edu/#edit-submit
>>
>> If I am reading your response correctly, we will want to add a
>> value="Search" attribute to the input#edit-submit element, like so:
>>
>> <input value="Search" class="btn-search form-submit" alt="Search"
>> type="image" id="edit-submit" name="submit"
>> src="https://vpge.stanford.edu/sites/default/themes/open_framework/images/searchbutton.png">
>>
>> (Or maybe not, because we are replacing the submit button with an image.)
>>
>> Thanks for the feedback,
>>
>> John Bickar
>> Stanford Web Services
>>
>>
>> On 1/14/14 5:55 PM, Birkir R. Gunnarsson wrote:
>>> Greetings!
>>>
>>> I am a bit confused here.
>>> The issue title claims the problem is with the search button, but the
>>> code indicates the missing label is on the search input field.
>>> According to the search button on the issue page itself which seems to
>>> suffer from precisely the same problem, (the URL referred to in the
>>> issue description requires a username and password) the html looks
>>> like this:
>>> <input type="submit" class="form-submit" value="Search" name="op"
>>> id="edit-submit">
>>> This is fine, inputs of type submit require the descriptive attribute
>>> to be the value, which it is.
>>>
>>> If we are discussing the search text input field, it appears to have
>>> no labelling except html5 placeholder text.
>>> It has its drawbacks and is not recommended as an accessible
>>> alternative to an explicit visible label
>>> see:
>>> http://blog.paciellogroup.com/2011/02/html5-accessibility-chops-the-placeholder-attribute/
>>> I agree with the recommendation of that page, add a title attribute
>>> containing the placeholder text to the field.
>>> Yes, it probably causes screen readers to read the label twice, since
>>> the support for the placeholder attribute is on the rise, but it is
>>> better than not reading it at all.
>>> Remember that the title attribute suffers from some of the same issues
>>> as placeholder for sighted keyboard only users, i.e. title only
>>> appears visibly when mouse activated, so an explicit label, either
>>> wrapping the field or using the for=id connection is always most
>>> preferred.
>>> If you want to go the screen reader route specifically aria-label
>>> could be used in place of title, though it is even more restrictive
>>> and screen reader support is still not quite there if we allow
>>> ourselves to look reasonably far back.
>>> In short, either
>>> - wrap the <input> field in a <label> tag with the input field and the
>>> label text
>>> or
>>> - put a title attribute on the <input> tag.
>>>
>>> Cheers
>>> Birkir Gunnarsson
>>> Accessibility SME | Deque Systems
>>>
>>>
>>> On 1/14/14, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>>>> Greetings, WebAIM:
>>>>
>>>> I was looking at this Drupal issue, filed against the Drupal.org site:
>>>>
>>>> <https://drupal.org/node/2083561>https://drupal.org/node/2083561
>>>>
>>>>
>>>> And I wondered if any of you had input/might want to comment on it.
>>>>
>>>> I was trying to do some research to confirm whether the search button
>>>> needs a label, and this WebAIM article made me think it might not,
>>>> i.e. via the heading 2 called Buttons:
>>>> http://webaim.org/techniques/forms/controls
>>>>
>>>> Can anyone let me know and/or comment on the ticket?
>>>> Part of what's confusing me is that when I look at a range of
>>>> accessibility-related sites, some do have the label, while others don't.
>>>>
>>>> Thanks.
>>>>
>>>> Best,
>>>> Jennifer
>>>>
>>>> >>>> >>>> >>>>
>>>
>>>
>>
>
>

From: John Foliot
Date: Wed, Jan 15 2014 8:39AM
Subject: Re: labels on search buttons -- Drupal.org and Beyond
← Previous message | No next message

Howdy John and Jennifer,

There are a few form input types that do not require pairing with the
<label> element: Submit, Reset, Image and Button. This is because there is a
stronger binding of the intent of those inputs to the larger "form" - these
elements have an additional, built in semantic within the spec:
Submit Button - An enumerated value, with the extra semantic that it
must be the last value selected and initiates form
Image Button - A coordinate, relative to a particular image's size,
with the extra semantic that it must be the last value selected and
initiates form submission
(source: http://www.w3.org/TR/html5/forms.html#the-input-element)

The differentiator for these input types are the value="" string. You can
see this by building the most basic of forms and using the <submit> input:
without a value attribute a screen reader (for example) will still announce
that it is a submit button. Add a value string (value="search", value="go",
etc.) and not only does the value displayed on the visual button (in the
GUI) change, but the value string is now announced by the screen reader.

(To apply an accessible name or accessible description to these elements
other than the defaults, you could also use aria-label, aria-labeledby
and/or aria-describedby as outlined here:

http://www.w3.org/TR/html-aapi/#input-type-button-input-type-submit-and-inpu
t-type-reset
- although this will only manifest to the Accessibility APIs: using
aria-label for example will not change the "value" of the button visually.)

HTH.

JF




>