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

Benjamin,

first, thank you for the detailed answer.

I give you a more elaborated example that reflects the current requirements for a typical INPUT element in one of our UI's.

1) Should have a Label explicitly associated with the Input element, a click on the label will put focus inside Input
2) Should have a tooltip with custom info (displayed as yellow browser default tooltip)
3) Should have an explanation attribute (explanation displayed separately in a popup when element is focused and a hotkey combination is invoked
4) Should have an additional error popup that always pops up when a value is erroneous and shows the reason for the error
5) Should have an optional 2nd label (for instance a unit after the Input)
6) Should have an optional 2nd text used as description after/next to the Input
7) Should have Keyboard Info how to use the element (we call this tutor text). This includes AccessKey info (in case we do accesskey functionality by other means then the UA-built-in "accesskey" mechanism) but also info how to interact with the element
8) Should have optional information about the subtype of the element (type: number, Type date) or/and the format string. This one is important for we are forced not to put element type and format in 2) info (tooltip) and "empty" is often the default for fields, for now. And also we assume no available numeric input mask.
9) Should have optional prompt text (like "enter search criteria") in the Input field
10) Should have a suggest list with possible values for the input

Now for the coding:

1) can be addressed using "label for"
2) + 9) can be addressed using "title"

3) and 4) can be resolved using the ARIA tooltip role for DHTML popoups associated with the Input, but will the content of the popup been automatically announced by AT when the popup is displayed? If not, what to do?

5) can be addressed using aria-labelledby
6) can be addressed using aria-describedby

7) and 8) were first candidates for aria-label for me, but after your mail comment (thanks for pointing this out) and because IE8 does not supply this property at all for now, I'm now on the track that we will generate a special non-displayed span referenced using either existing aria-describedby property from 6) or creating a new one for this purpose.

10) is currently left to UA Feature but may change if we need a custom implementation


Use Case:

Stock: [      ] piece(s)    Wrench

Now the (naïve) example code fragment sketch:

<label id="l1" for="i1"> <u>S</u>tock:</label>
<input type="text" id="i1" aria-labelledby="l1 l2" aria-describedby="inspectionText hint explanation err" title="Enter amount in Stock" onfocus="errorShow(event, this, ' err ')" onkeydown="explanationShow(event, this, ' explanation ')" />
<span id="hint" style="display:none">Numeric, type Alt+S to focus, press enter to read explanation</span>
<span id="l2"> piece(s)</span>
<span id="inspectionText"> Wrench</span>

<span id="explanation" role=tooltip" aria-hidden="true">See document node 123.4. This is also related to parts List field 5 (Prerequisites for Order)</span>
<span id="err" role=tooltip" aria-hidden="true"></span>

Note that at least error info rendering will be done dynamically using JS on the "err" span.

We have MANY references now in the aria-describedby and aria-labelledby declarations to satisfy all the info been spoken. The info can be added on request (governed by user's accessibility settings) and will not always be present.

If I want to be spoken the info in correct order and I use OTHER element properties (like element value etc.) as part of the screen reader speech output, the id sequence WILL NOT ALWAYS GRANT A CORRECT speech output sequence (as can be seen from aria-labelledby="l1 l2"). For instance, it can be expected that aria-labelledby l1 and l2 will be spoken FIRST and THEN the value which leads e.g. to "Stock: piece(s) four" which may be ok in some scenario but in others not (e.g. metric units). Also, this may become language dependant. 

Concatenation of title with all the other info in aria-describedby will probably be confusing, too. Having the error information being part of the describedby is the recommended procedure so far (see e.g. http://codetalks.org/source/widgets/tooltip/tooltip.html)

What can be done here? Would Heuristics help, e.g. a recommendation to speak language dependant first idreference then insert the value then the following references?

Finally I would like to say that the MSAA kbshortcut (IAccessible::get_accKeyboardShortcut) and Method  Help/help IAccessible::get_accHelp topic properties would have been perfect candidates for the requirement 7), but property strings aria-shortcut="" and aria-help="" that would actually map to these was never in the concept of ARIA.

Also for performance reasons, an aria-description="" that can be used when there is no visible (but declared) node to be referenced by aria-describedby would come in handy. 

Best Regards
Stefan





-----Original Message-----
From: Benjamin Hawkes-Lewis [mailto:bhawkeslewis@googlemail.com] 
Sent: Donnerstag, 2. Juli 2009 06:45
To: Schnabel, Stefan
Cc: Alexander Surkov; wai-xtech@w3.org
Subject: 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 14:36:23 UTC