accname-aam need to clarify aria-owns in Step 2F

[jnurthen]

From @jnurthen on March 21, 2017 21:9

Need to clarify if aria-owns should be taken into account in step 2F (iii - a).

When talking about "child node"

• Chrome includes nodes owned through use of aria-owns
• FF only considers DOM children

To be honest I don't care what the result is - but I want consistency. Please clarify.

(see bug https://bugs.chromium.org/p/chromium/issues/detail?id=702811 logged against Chrome)

Copied from original issue: w3c/aria#538

[jnurthen]

From @joanmarie on March 23, 2017 17:23

And Chrome does it on purpose: https://bugs.chromium.org/p/chromium/issues/detail?id=561766. The question is why? Let's ask Dominic.

[jnurthen]

From @aleventhal on May 12, 2017 15:13

@jnurthen, I talked with both the Chrome and Firefox a11y team and the consensus is to do things the Chrome way -- that is, to include aria-owns children in the accessible name. Is there an issue with test case filed in the Mozilla bug tracker? That would be helpful

CC'ing @asurkov

[accdc]

I'm pretty sure in recent FF versions aria-owns followed aria-owned relationships too, but doing so matches the definition of owned children in the 1.1 spec, so this should be done by browsers if it's not already being done at present. This can be clarified in 1.2.

[joanmarie]

At the moment, Chrome sometimes does it and sometimes doesn't. For instance we have a failure in Chrome/Chromium for this test case:

  <input type="file" id="test" />
  <label for="test">Flash <span aria-owns="id1">the screen</span> times.</label>
  <div>
    <div id="id1" role="combobox" aria-owns="id2">
      <div role="textbox"></div>
    </div>
  </div>
  <div>
    <ul id="id2" role="listbox" style="list-style-type: none;">
      <li role="option" >1 </li>
      <li role="option" aria-selected="true">2 </li>
      <li role="option">3 </li>
    </ul>
  </div>

Expected: "Flash the screen 2 times." Actual: Flash the screen times."

WebKit/Safari fails both for the above test case and the simpler case:

  <input type="file" id="test" />
  <label for="test">Flash <span aria-owns="id1">the screen</span> times.</label>
  <div id="id1">
    <div role="combobox">
      <div role="textbox"></div>
      <ul role="listbox" style="list-style-type: none;">
        <li role="option" aria-selected="true">1 </li>
    <li role="option">2 </li>
    <li role="option">3 </li>
      </ul>
    </div>
  </div>

Expected: "Flash the screen 1 times." Actual: Flash the screen times."

Firefox does pass in both of the above cases, but Firefox also changes the accessibility tree based on ARIA owns. In other words, for the Firefox accessibility tree, the owned elements are children. Mind you I haven't yet looked at the code to see if that reparenting is why we're getting the expected name calculation or not.

Regardless, I don't think we can use the owned-children test cases for the 1.1 exit criteria because AccName doesn't say anything about aria-owns.

[accdc]

I don't have any problem skipping it for the exit criteria, and agree that aria-owns isn't explicitly mentioned, so this can be easily changed in the future update to do this.

As far as interpretation though, I'm pretty sure the implied intent is to follow the aria-owns relationship in the same manner as though these were actual children in the DOM. This is supported in the spec where it states:

Section 4.3: "Text alternatives are built up, when appropriate, from all the relevant content contained within an element. This is accomplished via steps 2B and 2F, which are recursive, using the full set of rules to retrieve text from its own children or nodes it references."

Section 4.3.1: "Current node The DOM node currently traversed to compute the root node's text equivalent. Initially, the current node is the root node, but at later stages is either some descendant of the root node, or another referenced node."

If an aria-owns relationship doesn't qualify as a "referenced node", I'm not sure what does.

I remember some years back when we went back and forth with Rich and Cynthia amongst everybody else about the most desirable usage of aria-owns, and I believe we ended up agreeing back then that it made sense for the accessibility tree to follow the aria-owns relationship. There are a lot of inherent accessibility enhancements that magically become possible and very beneficial for ATs when this is done that aren't feasible otherwise. This was when FF was updated to do this I think since Marco was involved.

[joanmarie]

The DOM node currently traversed to compute the root node's text equivalent. Initially, the current node is the root node, but at later stages is either some descendant of the root node, or another referenced node."

If an aria-owns relationship doesn't qualify as a "referenced node", I'm not sure what does.

To me, an aria-labelledby reference clearly qualifies; an aria-errormessage reference doesn't; discussion here suggests we may have some consensus that aria-owns counts. But given that it's not stated in the spec and that we don't have sufficient implementations that reflect that understanding, ....

If we want consistent implementations so that we have consistent user experiences across user agents and platforms, implied intent is (imho) insufficient.

[dd8]

We've just done an implementation of this and came across a few things not really addressed by accname-aam:

• parent-child loops created by aria-owns (direct or indirect)
• the same node assigned to multiple parents by two different aria-owns attributes
• forward references (e.g. processing a child which should be re-parented by aria-owns, but the node with the aria-owns attribute hasn't been visited yet by the calculation)

Parent-child loops

One issue to consider is what happens when one of the IDREFs in aria-owns references an ancestor. The ARIA spec is clear that aria-owns is intended to represent parent-child relationships, but silent on loops, so should the entire aria-owns be dropped in this case or just the looping IDREF?

<article id='article1'>
 <label aria-owns='article1 control1'>Label:</label>
 <input id='control1' />
</article>

This can also happen indirectly, which is harder to detect:

<article id='article1'>
 <label aria-owns='article2 control1'>Label:</label>
 <input id='control1' />
</article>

<article id='article2'>
 <label aria-owns='article1 control2'>Label:</label>
 <input id='control2' />
</article>

Multiple parents

Can also have multiple aria-owns attributes assigning the same node to multiple parents, which the ARIA spec says authors must not do, but will happen in practice. This also interacts with parent-child loop detection (e.g. one of the aria-owns loops, but the other doesn't)

<article id='article1' aria-owns='control1 control2'>
 <label>Label:</label>
 <input id='control1' />
</article>

<article id='article2' aria-owns='control1 control2'>
 <label'>Label:</label>
 <input id='control2' />
</article>

Forward references

Aside from loops, there are some tricky ordering issues for the name calculation:

• what happens when processing children (e.g. name from content) where some of the children have been re-parented to another node using aria-owns, but the new owner with the aria-owns attribute hasn't been visited yet because it appears later in DOM order
• what happens when processing parent relationships (e.g. looking for an ancestor label) where the parent has been changed but the new parent with the aria-owns attribute hasn't been visited yet because it appears later in DOM order

<article id='article1'>
 <label>Label 1:
  <input id='control1' />
  <span id='span2'>Span 2</span>
  <input id='control2' />
 </label>
</article>

<article id='article2'>
 <label aria-owns='span2 control2'>Label 2:</label>
</article>

I guess the fundamental question is which tree does the AccName calculation use:

• does it operate on the DOM tree, or
• a partially complete accessibility tree, or
• a fully complete accessibility tree using a second pass after aria-owns references have been resolved, or
• something else

[accdc]

Hi, For author errors like loops, the browser will have to include logic to prevent this when detected, otherwise it will likely crash it. Loops should never be used in practice like this. The same is true when referencing the same elements multiple times in the same aria-owns attribute or within multiple aria-owns attributes.

The use of aria-owns changes the order of the accessibility tree, and this is where the danger of using it incorrectly will cause critical accessibility issues. The aria-owns attribute should never be used casually for this reason.

The AccName algorithm treats any parent child construct in the same manner, whether these elements are natively nested in the DOM, or instead referenced using aria-owns, both are equally referred to as 'owned children' in accordance with the spec.

The AccName algorithm also specifies that nodes can only be processed once, no matter how many times they might be referenced or indirectly referenced later on. This is a hardline rule in the spec to prevent the danger of infinite loops.

So the correct order of events would be that the accessibility tree is created by the browser using a combination of what the DOM represents plus any overrides specified by aria-owns, then the AccName computation would be applied to the resulting structures. When doing this, the AccName algorithm will only process the first occurrence of any particular node, and ignore any subsequent references to the same node later on if this is part of the same recursion process.

All of these processes and rules are included within the AccName Prototype at https://github.com/WhatSock/w3c-alternative-text-computation Which might help when experimenting with combinations like these.

Hopefully this helps a bit.

All the best, Bryan

[dd8]

For author errors like loops, the browser will have to include logic to prevent this when detected, otherwise it will likely crash it. Loops should never be used in practice like this.

@accdc thanks that's useful. I think the spec should define how invalid aria-owns attributes are handled (including loops and other invalid constructs) to ensure the accessibility tree really is a tree and not a cyclic graph.

Loops are probably worst for virtual buffer implementations - they're likely to go into an infinite loop traversing an accessibility tree that's been turned into a cyclic graph using aria-owns

Given the accname calculation needs a complete accessibility tree, I think aria-owns resolution needs done as a separate step prior to running accname calculations, and (ideally) should have well-defined behaviour for invalid constructs similar to how invalid markup is handled in the HTML and CSS specs.

If the decision is not to define the behaviour, then the spec should say behaviour of invalid constructs is undefined and a conformance error.

Other invalid constructs I can think of:

1) direct loops (i.e. referencing an ancestor in aria-owns) 2) indirect loops (e.g. referencing a second element with aria-owns which in turn has an aria-owns attribute reference an ancestor of the first element) 3) nonsensical aria-owns relationships (e.g. referencing the document <head> element in aria-owns or referencing a non-content element like <style> or <script> )

These are possibly valid, but if they are behaviour is very unclear: 4) element indirectly used in multiple aria-owns attributes (e.g. one aria-owns points to a <ul> element and another aria-owns points to a child <li>)

Invalid constructs already handled by the spec: 5) element ID directly used in multiple aria-owns attributes

There are probably many other ways to break things with aria-owns. If it gets too difficult to define all the invalid conditions, it might be easier to define what's valid (i.e. which elements aria-owns is allowed to reference relative to the element with the aria-owns attribute)