WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Is use of <label> and title redundant?

for

From: Sailesh Panchang
Date: Nov 20, 2012 11:48AM

James,
>>my opinion this meets 3.3.2.
And I pointed out documentation that does not support that view.
Certainly techniques and understanding docs are not normative and are
guidance docs.
The 'How to meet' doc suggests what is appropriate in different circs.
and in fact is a guide to how to meet the SC.
Label text that is not marked up as a label is not 'associated' with
the control.
I never said title does not work for screen reader / magnifier users.
Title is simply not the recommended technique in the circumstance.
Label helps other user groups as I pointed out earlier. If you wish to
ignore them, it is your prerogative.
Sailesh Panchang



On 11/20/12, James Nurthen < <EMAIL REMOVED> > wrote:
> Sailesh,
>
> There is nothing in WCAG which states that you have to use any of the
> prescribed techniques. The important thing is to meet the Success Criteria.
> 3.3.2 states
> "3.3.2 Labels or Instructions: Labels or instructions are provided when
> content requires user input. (Level A)".
> The Understanding document provides more
> "The intent of this Success Criterion is to help users avoid making
> mistakes when their input is required. To help avoid mistakes it is good
> user interface design to provide simple instructions and cues for entering
> information. Some users with disabilities may be more likely to make
> mistakes than users without disabilities or recovery from mistakes may be
> more difficult, making mistake avoidance an important strategy for users
> with disabilities. People with disabilities rely on well documented forms
> and procedures to interact with a page. Blind users need to know exactly
> what information should be entered into form fields and what the available
> choices are. Simple instructions visually connected to form controls can
> assist users with cognitive disabilities or those accessing a page using a
> screen magnifier."
>
> In this simple example there is a label associated visually with the field.
> There is also the title (which happens in this case to be the identical to
> the visible label) which is programmatically associated with the field. In
> my opinion this meets 3.3.2.
>
> I am certainly not saying that this is the optimal design as label is
> certainly better, but we shouldn't rule out techniques which actually work
> for users due to the fact that they are not optimal. I'd much rather that
> the developers of web sites and applications spent their limited time
> fixing issues which actually cause a problem rather than fix areas where
> their code is not optimal but actually don't cause users any issues.
>
> regards,
> James
>
>
> On Tue, Nov 20, 2012 at 8:43 AM, Sailesh Panchang <
> <EMAIL REMOVED> > wrote:
>
>> Hello James,
>>
>> Technique H65 says use title if UI does not support visible label text.
>> In your example there is no apparent reason for not using label
>> element and for-id association. Title should not be used there.
>> Refer to: Description for H44:[1]
>> "However, for Success Criterion 3.3.2, the label element must be
>> visible since it provides assistance to all users who need help
>> understanding the purpose of the field. "
>> There are other user groups besides screen reader users who are
>> benefited by label association.
>>
>> Sailesh
>>
>> [1] http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H44
>> On 11/20/12, James Nurthen < <EMAIL REMOVED> > wrote:
>> > Sailesh,
>> > I'm not sure how this fails 3.3.2. Can you explain how the following
>> fails
>> > 3.3.2?
>> >
>> > <div>First Name</div><input type="text" title="First Name">
>> >
>> > I understand it is better practice to specify the label using for and
>> > id,
>> > but I'm not seeing how this example actually fails 3.3.2
>> >
>> > regards,
>> > James
>> >
>> >
>> > On Mon, Nov 19, 2012 at 2:15 PM, Sailesh Panchang <
>> > <EMAIL REMOVED> > wrote:
>> >
>> >> Zoe / Bryan,
>> >>
>> >> JAWS does read title in Firefox and IE when arrowing down the page
>> >> (without activating forms mode).
>> >> NVDA does not read the title unless one is in forms mode.
>> >> Using title is simpler as I have maintained all along as compared to
>> >> off-screen label in the situations discussed.
>> >> Failing to markup visible labels as labels and use title instead will
>> >> fail SC 3.3.2.
>> >> It is not alright to simply use title there.
>> >> Sailesh
>> >>
>> >>
>> >> On 11/19/12, Bryan Garaventa < <EMAIL REMOVED> > wrote:
>> >> > When you refer to browse mode, do you mean when using the arrow keys
>> to
>> >> > navigate up and down the page in the Virtual Buffer?
>> >> >
>> >> > When title attributes are included on form fields, I'm hearing these
>> >> > announced correctly as form field labels in addition to tabbing
>> >> > using
>> >> > interactive mode.
>> >> >
>> >> > This can be broken if a title attribute is included on a form field
>> >> > that
>> >> > also includes an explicit label element with matching for and ID
>> >> attributes
>> >> >
>> >> > in some ATs though.
>> >> >
>> >> >
>> >> >
>> >> > ----- Original Message -----
>> >> > From: "GILLENWATER, ZOE M" < <EMAIL REMOVED> >
>> >> > To: "WebAIM Discussion List" < <EMAIL REMOVED> >
>> >> > Sent: Monday, November 19, 2012 10:17 AM
>> >> > Subject: Re: [WebAIM] Is use of <label> and title redundant?
>> >> >
>> >> >
>> >> > Hi Sailesh,
>> >> >
>> >> > But if you were using visible labels you *would* hear them read in
>> >> > browse
>> >> > mode, so using title text that is not read in browse mode is a
>> >> > different
>> >> > experience from the norm, and it seems to me a worse one.
>> >> >
>> >> > For instance, if I had three fields for month, day, and year of a
>> >> birthday,
>> >> >
>> >> > and each had a visible label in front of it, I would hear in browse
>> >> > mode
>> >> > something like "Birthday. Month, edit, blank. Day, edit, blank.
>> >> > Year,
>> >> edit,
>> >> >
>> >> > blank." It's clear to me what those fields are, which allows me to
>> know
>> >> > whether or not I want to enter forms mode and fill out this form.
>> >> >
>> >> > But if I got rid of the visible labels and just used title text,
>> >> > some
>> >> screen
>> >> >
>> >> > reader users would now hear in browse mode something like "Birthday.
>> >> Edit,
>> >> > blank. Edit, blank. Edit, blank." You don't think this is a worse
>> >> experience
>> >> >
>> >> > than the former? Sure, I can guess at what each of those fields is,
>> and
>> >> have
>> >> >
>> >> > my guess validated when I enter forms mode and finally hear the
>> >> > title
>> >> text,
>> >> >
>> >> > but why should the user have to do this? Why not just provide hidden
>> >> labels
>> >> >
>> >> > so they hear the exact same thing they would hear had visible labels
>> >> > been
>> >> > used instead?
>> >> >
>> >> > I still don't see what advantage using title has over a hidden
>> >> > label,
>> >> apart
>> >> >
>> >> > from:
>> >> > -- it's slightly less bytes of HTML
>> >> > -- it's slightly easier to implement (if you don't already have a
>> >> > hiding
>> >> CSS
>> >> >
>> >> > class in your CSS, but if you do, creating hidden labels is pretty
>> much
>> >> just
>> >> >
>> >> > as easy)
>> >> > -- it will show on hover as a tooltip to mouse-using sighted users
>> >> > (which
>> >> > could be seen as a disadvantage by some people in some situations)
>> >> >
>> >> > What am I missing? Are these the only reasons why you find title to
>> >> > be
>> >> > superior?
>> >> >
>> >> > Thanks,
>> >> > Zoe
>> >> >
>> >> >
>> >> >
>> >> > Zoe Gillenwater
>> >> > Web Accessibility Technical Architect
>> >> > AT&T Consumer Digital Experience
>> >> >
>> >> > o: 919-241-4083
>> >> > e: <EMAIL REMOVED>
>> >> >
>> >> > 4625 Creekstone Dr | Durham, NC 27703
>> >> >
>> >> > This email and any files transmitted with it are AT&T property, are
>> >> > confidential, and are intended solely for the use of the individual
>> >> > or
>> >> > entity to whom this email is addressed. If you are not one of the
>> named
>> >> > recipient(s) or otherwise have reason to believe that you have
>> received
>> >> this
>> >> >
>> >> > message in error, please notify the sender and delete this message
>> >> > immediately from your computer. Any other uses, retention,
>> >> > dissemination,
>> >> > forwarding, printing, or copying of this email is strictly
>> >> > prohibited.
>> >> >
>> >> >
>> >> >