WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Name, Role, Value and Labels or Instructions techniques...

for

From: Bryan Garaventa
Date: Mar 29, 2015 2:23PM

Regarding the naming calculation, there are still issues with how this breaks down, as is being discussed at:
http://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0155.html
Which is probably good for others to be aware of.

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of John Foliot
Sent: Sunday, March 29, 2015 10:45 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] Name, Role, Value and Labels or Instructions techniques...

Sean Keegan wrote:

> Hello all,
>
> I am reviewing a web application that has many form fields that are
> using the title attribute. To add to this, there is on-screen text for
> nearly all the form fields but the <label> tag is not used
> consistently. It appears that the title attribute was used initially
> to provide supplemental information and then became more of a support
> for screen-readers.
>
> I considered this is a fail under 4.1.2 (Name, Role, Value) and 3.3.2
> (Labels and Instructions). It was pointed out to me that the technique
> H65 allows for the title attribute for form fields and this satisfies
> the "programmatically determined" requirement as well as provides the
> relevant instructions. I say shenanigans as the second part of the H65
> technique uses the phrase "when the label element cannot be used."
>
> Any thoughts/comments from those all-knowing in the ways of WCAG?


For me, the primary question to answer is - is the form usable by those users requiring AT/screen readers? According to the "HTML to Platform Accessibility APIs Implementation Guide" (currently still a draft, but accurate non-the-less), using @title to provide an Accessible Name to a form input is acceptable, as the algorithm calls for the following:

1. Use aria-labelledby
2. Otherwise use aria-label
3. Otherwise use the associated label element
4. Otherwise use the placeholder attribute
5. Otherwise use the title attribute
6. If none of the above yield a usable text string there is no accessible name

(source:
http://www.w3.org/TR/html-aapi/#accessible-name-and-description-calculation)

Therefore, if each of the form inputs @title value serves as a useful accessible name then it meets the practical requirement that drives the spirit of WCAG. Further, basic testing confirms that this "works" with screen readers today. Question: do the @title values "mirror" the on-screen text (exactly and/or close-enough?). (Note, the algorithm also calls for 'processing' those instructions in order, so for example if the form input has @placeholder text present, the Accessibility API's are supposed to expose that value *before* the value of @title - yes, this is a problem for cognition and low vision deficits, but as far as the AAPI is concern, it isn't, it's a text value that 'labels' the input.)

If however you are mandated for a strict conformance to WCAG, then per your reading I would issue, at a minimum, a warning that using the <label> element is the "better" way of providing an accessible name (label) to form inputs.
However, using @title is not technically "wrong" and does work today.

This "predicament" reminds me of the old saying (regarding marriage) "You can be right, or you can be married."

HTH

JF