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 12:55PM

James,
Sure, I know that.
And Patrick,
Please refer to the first email to James which has the reasoning. It
is the description of H44:
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H44
Thanks and regards,
Sailesh



On 11/20/12, James Nurthen < <EMAIL REMOVED> > wrote:
> Sailesh,
> The fact is that nothing in 3.3.2 requires programmatic association of
> fields and labels. 3.3.2 deals with providing labels or instructions for
> fields, not their association.
> 3.3.2 can be met by (for example) applying G131 (Providing Descriptive
> Labels) and G162 (Positioning labels to maximize predictability of
> relationships). so even the following:
> <span>First Name</span><input type="text"> would meet 3.3.2
>
> Programmatic association of fields and labels is covered by 1.3.1 in WCAG2.
>
> regards,
> James
>
>
> On Tue, Nov 20, 2012 at 10:48 AM, Sailesh Panchang <
> <EMAIL REMOVED> > wrote:
>
>> 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.
>> >> >> >
>> >> >> >
>> >> >> >