text equivalent computation algorithm

Firefox text equiv computation algorithm is different from ARIA spec
algorithm (here:
http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#mapping_special_te)
and actually it sounds like it differed forever (see first draft
http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#mapping_special_te).

Unfortunately I failed to find the original algorithm implemented in
Firefox in 2008 (see
https://bugzilla.mozilla.org/show_bug.cgi?id=455886). The bug is
referred to devmo page with empty history
(https://developer.mozilla.org/index.php?title=en/ARIA_User_Agent_Implementors_Guide&action=history).
Thus I can't be sure that algorithm implementation was ever in sync
with original proposal.

So I run through ARIA spec and Firefox implementation and spot the
difference as Aaron suggested.

1) "Skip hidden elements unless the author specifies to use them via
an aria-labelledby or aria-describedby being used in the current
computation."

Firefox doesn't skip any hidden elements IDRefed by attributes used in
text equivalent calculation. For example, the spec requires to left
name blank for input element in following case:
<label style="display:none" for="input">label</label><input id="input"/>

1A1) "The aria-labelledby attribute takes precedence as the element's
text alternative unless this computation is already occurring as the
result of a recursive aria-labelledby declaration (in other words,
aria-labelledby is not recursive when referenced from another element,
so it will not cause loops)"

<span id="txt1">txt1</span>
<span id="txt2" aria-labelledby="txt1">txt2</span>
<span id="txt3" aria-labelledby="txt2">txt3</span>

That makes me think that "txt3" name is empty, "txt2" name is "txt1".
It seems that goes with Firefox implementation but I don't quite
understand what is another element from "(in other words,
aria-labelledby is not recursive when referenced from another
element". I'd be nice to clarify it.

Also the phrase "takes precedence unless" makes me think that if
"unless" statement takes a place and other options fail then we get
back to aria-labelledby again.

The spec doesn't address reentrances from native markup and
aria-labelledby combos like:
<label for="input" aria-labelledby="input">label</label><input id="input"/>

Compare to initial draft of the spec section D saying: "Else if
aria-labelledby is present, and this node is not already part of an
aria-labelledby or accessible name calculation, then process
aria-labelledby"

1A2) "If aria-labelledby is empty or undefined, the aria-label
attribute, which defines an explicit text string, is used."

Firefox tries aria-label if aria-labelledby provided empty name. This
can occur for example when IDs used in aria-labelledby don't point to
valid elements.

1A2) "However, if this computation is already occurring as the result
of a recursive text alternative computation and the current element is
an embedded control as defined in rule 2B, ignore the aria-label
attribute and skip directly to rule 2B."

This item appears to be new. Firefox implementation always looks at
aria-label if aria-labelledby failed. I'd be great to get an idea
behind this rule.

1A3) "If aria-labelledby and aria-label are both empty or undefined,
and if the element is not marked as presentational
(role="presentation") check for the presence of an equivalent host
language attribute or element for associating a label"

role="presentation" case is new. Technically role="presentation"
results that element is not accessible (what means text equivalent alg
is not applicable to it) until the element is focusable. I don't
clearly understand why focusable elements marked as presentational
should ignore name from native markup. But that may be the same issue
as Firefox doesn't remove native semantics form focusable
presentational elements. Anyway, if non focusable presentational
elements were meant here then it makes sense to include them into 1)
item where hidden elements are discussed. Note, aria-hidden is not
mentioned at all.

B) "Authors sometimes embed a control within the label of another
widget, where the user can adjust the embedded control's value. For
such cases, include the value of the embedded control as part of the
text alternative"

Since select element of the following example is an embedded control
within the label of *not* another widget then value isn't required to
be included as "select" name:
<label id="comboinmiddle">
  Subscribe to
  <select id="combo" name="occupation">
    <option>ATOM</option>
    <option>RSS</option>
  </select>
  feed.
</label>

That's different from original wording "Append the current
user-entered value of this node to the text equivalent. However, in
order to avoid redundant presentation of the same text, do not append
this text if it will be the first or last part of a text equivalent
calculation for the same node that it came from."

Firefox follows the original rule and computes "combo" name as
"Subscribe to ATOM feed".

B) "include the value of the embedded control as part of the text
alternative in the following manner: "

text field, menu, select or combobox and range doesn't pretend to be a
complete list. For example, it miss things like trees. Anyway the spec
probably shouldn't provide a complete set of elements by it should say
that. For ARIA widgets it makes sense to list roles that supports
accessible value concept.

B) "If the embedded control is a menu, use the text alternative of the
chosen menu item."

Usually menus don't have chosen menu item until they are active. That
makes name dependent on menu state.

C) "Otherwise, if the attributes checked in rules A and B didn't
provide results"

attributes term seems to be treated widely and be different from DOM
attribute term since it should include name from accessible value etc.
Would be nice to state it more accurately.

C) "text is collected from descendant content if the current element's
role allows "Name From: contents."

It'd be great to specify which roles (at least ARIA roles) allows name
from contents.

C)

It appears the algorithm misses "name from content if recursive" item.
For example,
<p id="p">this is paragraph</p>
<input aria-labelledby="p"/>

Paragraph role doesn't allow name form contents rule but if the
paragraph is a part of name of another element then Firefox
implementation goes into paragraph to compute name from children.

Compare to old wording: "If the text equivalent for this node is
empty, and either the current node's role allows "Name From: subtree"
or the current node is not a control but is part of a label or
description, recursively implement this name computation for each
child".

Note, nowdays spec allows the UA to choose whether it wants to get a
text from content or from accessible names: "However, any given
descendant subtree may instead collect their part of the text
alternative from the preferred markup described in A and B above." Not
sure about the purpose of this since it leads to inconsistencies in
implementations.

I'd love to hear your feedback.
Thank you.
Alex.

Received on Wednesday, 21 March 2012 08:39:14 UTC