Re: text equivalent computation algorithm

Hi Alex,

This is very difficult material to understand for everyone. I think some of
the issues might be important, though, so we should try to find a way to
simplify this so it can be discussed.

I have some ideas on how to simplify it:
1. Let's ignore anything that doesn't affect authors for now. If it doesn't
affect authors then it is probably either for clarity or for simplicity in
dealing with edge cases like recursion.
2. Provide tests with expected screen reader results. Could you provide a
few real use cases that are broken with the new rules? Ideally they would
be links to small test case pages that work in Firefox because of the old
implementation guide rules, and do not work in something like Safari, which
is likely following the new rules. Maybe the page could have a description
on the bottom of the old and new rule.

This might make it easier for some of the folks on the list who really need
to understand this. I have a hard time parsing through these issues myself
even though I've worked on the spec, the implementation and the
implementation guide.

All your hard work is appreciated,
Aaron


On Wed, Mar 21, 2012 at 4:38 AM, Alexander Surkov <
surkov.alexander@gmail.com> wrote:

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