WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Bryan Garaventa
Date: Nov 19, 2012 3:24PM

Wouldn't this be a bug in NVDA then? It doesn't make sense that, if an
explicit label is present, that it would not be announced when arrowing.

----- Original Message -----
From: "Sailesh Panchang" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Monday, November 19, 2012 2:15 PM
Subject: Re: [WebAIM] Is use of <label> and title redundant?


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