Re: label for, aria-label and aria-labelledby

On 29/6/09 10:06, Schnabel, Stefan wrote:
> Well I give you 2 use cases:
>
> 1) Suppose we like to add hidden extra information to the INPUT, say
> an "special explanation" attribute and we want it spoken on input
> focus
>
> - we don't want to use title attribute (should be reserved for other
> things not of interest now)

Could you please elaborate further on why this special explanation
doesn't belong in the "title" attribute: what sort of explanations would
you put in the two locations, and why? Saying it's not of interest
doesn't help evaluate your use-case, because it prevents readers 
thinking in about either the authoring rationale or the user experience.

> - we don't want to instantiate an extra hidden element that can be
> referenced by labelledby /describedby (performance reasons, don't
> ignore this, this one is IMPORTANT for SAP)

Additional elements and attributes have performance costs:

http://developer.yahoo.com/performance/rules.html#min_dom

But functionality often costs performance, and we're talking SGML-based 
markup languages here; elements and attributes are how they express 
semantics, so this goes with the territory.

Can you quantify the performance cost of one extra element?

If one were to agree that the performance cost of an extra element is
unacceptable, that would be an argument for adding an "aria-description" 
attribute parallel to "aria-label".

However, "aria-describedby" has a better backwards compatibility story
than "aria-description" would do, since even non-ARIA UAs can render the 
referent, and adding another attribute would increase spec complexity.

> For me, a good + simple solution would be
>
> <label for="Text1">Name:</label> <input type="text" id="Text1"
> aria-label="special explanation" title="XYZ" />
>
> Currently, the LABEL text will be ignored by such a combination.

At the moment, you /could/ force UAs to treat the special explanation as 
part of the accessible name with:

<label for="Text1">Name:</label> <input type="text" id="Text1"
 > aria-label="Name (special explanation)" title="XYZ" />

But you'd be a little wrong to do so, since a "special explanation" 
doesn't belong in an accessible name. Quoth the draft:

"A label should provide the user with the essence of what the object 
does, whereas a description is intended to provide detail that some 
users might need."

> 2) Suppose you WANT to use labelledby in context of 1) for some
> reasons not of interest now

Again, to me, these reasons seem important to evaluating your use-case. 
Please elaborate.

> <span id="d1">Name:</span> <input type="text" id="Text8"
> aria-labelledby="d1" aria-label="special explanation" title="XYZ" />
>
> Currently, the span text will be also ignored by such a combination.

An obvious problem with concatenating aria-labelledby and aria-label is 
that the order of attributes is not meaningful or guaranteed in HTML or 
XML (http://www.w3.org/TR/REC-xml/#sec-starttags), so there'd be no 
guarantee aria-labelledby and aria-label would be concatenated in the 
right order. You'd have to specify an concatenation priority for each 
source in the accessible name calculation algorithm, which would 
probably increase the number of authoring errors. e.g. Naive authors 
might write:

<input type="text" id="Text8"
aria-label="Name:" aria-labelledby="d1" title="XYZ" />
<span id="d1">Special explanation.</span>

and expect it to work, although the spec would need to specify 
aria-labelledby to be concatenated /before/ aria-label for your markup 
to work.

What algorithms would you propose in place of:

http://www.w3.org/TR/wai-aria/#nameref

http://www.w3.org/TR/wai-aria/#textequivalentcomputation

And how would the two sets of algorithms compare for:

1) Accurate results against other real-world DOMs - in other words, do 
they produce the same or better accessible names?
2) Performance against other real-world DOMs.
3) Ease of author understanding.
4) Ease of UA implementation.

It seems to me the addition of "aria-described" would be a smaller and 
less problematic change to the draft and would meet your desired usage 
(providing details but avoiding the performance cost of an extra element 
or using "title"). I'm not personally persuaded your usage is justified 
by strong use-cases, but perhaps more details would change my mind.

--
Benjamin Hawkes-Lewis

Received on Thursday, 2 July 2009 04:45:46 UTC