Definition of "owned" is not strict enough; should actually be direct children, not any descendant

[jnurthen]

From - https://www.w3.org/Bugs/Public/show_bug.cgi?id=26307

The definition of "owned" in the ARIA spec includes any descendant (or any descendant of a node that's aria-owned).

That means that according to the spec, it's okay to have a list with listitems that are descendants but not direct children, or a grid with rows that are descendants but not direct children, e.g.:

<div role="list">
  <div>
    <div role="listitem">One</div>
  </div>
  <div>
    <div role="listitem">Two</div>
  </div>
</div>

<div role="grid">
  <div>
    <div role="row">
      <div>
        <div role="gridcell">1, 1</div>
      </div>
      <div>
        <div role="gridcell">2, 1</div>
      </div>
    </div>
  </div>
</div>

In practice, this doesn't seem to work with any browser or screen reader, unless you use aria-owns or role=presentation.

It occasionally works in some circumstances when the browser skips over extra unneeded container elements - but it definitely doesn't work in general.

Either the spec needs to better match how browsers and assistive technology have implemented their support for owned relationships, or browsers need to start doing a lot of extra work to search all descendants for required owned elements.

[jnurthen]

See related info in auto-wcag https://github.com/auto-wcag/auto-wcag/blob/c031c8987712478e95932c022b78ebf01d22b44f/pages/glossary/owner-element.md

[jnurthen]

@WilcoFiers - does this cover it?

[jnurthen]

Proposal:
Fix owned element language to restrict owned elements to

• Direct Children
• Elements referenced with aria-owns
• Descendant elements where each ancestor node between the parent and the element has a role of none or generic

Should we also allow

• Descendant elements of the element referenced with aria-owns where each ancestor node between the element referenced with aria-owns and the owned element has a role of none or generic

(need to make this language completely unambiguous - this is a first proposal and needs work)

[accdc]

Clarification is good, but this is a thorny one, because this restriction has the potential to break ARIA menus and trees and listboxes where additional markup is almost always used in the wild for styling purposes.

E.G what if the intervening markup includes LI elements that are not presentational?

I agree this has never worked reliably before, but browsers should be capable of at the very least to process explicit role associations and identify in which order interactive constructs include their parent child role associations. I know this is doable, because I already had to do this as part of the AccName algorithm code to get it to work right.

[jnurthen]

@accdc it would be helpful to provide an example which a change like this would break. This change would actually be slightly more generous than the current level of support by allowing generic containers which don’t work reliably today I believe.

[accdc]

Sorry, not that the change would break anything, just that if the logic wasn't inclusive enough it would leave those constructs out of the computation.

E.G I've seen constructs like this in the wild.

<div role="tablist">
<ul>
<li>
<a role="tab" aria-selected="true" tabindex="0" href="#"> One </a>
</li>
<li>
<a role="tab" aria-selected="false" tabindex="-1" href="#"> Two </a>
</li>
</ul>
</div>

At present, browsers primarily ignore the computed child tabs so the child count such as "x of y" is typically "1 of 1" when encountered by screen readers. The same thing happens for radios, listboxes, and likely others.

Algorithmically though, within browsers, it is possible to compute the explicit role assignments and compute an accurate role hierarchy without having to nullify all intervening markup, since technically such as in this case, list and listeitem roles as these implicitly are, are not generic. The same is true for many other standard HTML elements that might be unexpectedly combined in these ways.

[jnurthen]

As this doesn't currently work today we have 2 options:

• try to get the browsers to allow this
• make the spec clear that this is not allowed.

As authors have a way of making this work in my proposal by using role=none on the ul, I personally lean towards speccing the current browser behavior and moving on.

[accdc]

Adding this to the spec sounds fine to me, though I recommend adding that, in cases where role="none" is not added, then aria-posinset and aria-setsize must then be set upon relevant roles to ensure proper accessibility for supported widgets.

[accdc]

And before you say it, because you are probably thinking it, if role='none' is added then they don't have to use those attributes... :)

One big issue with the 'broad-strokes' approach is that framework devs will start adding role="none" to everything just to play it safe. I've already seen this in production environments, and it breaks everything.

[joanmarie]

Another issue which came up: What about the scenario where there are no children? For instance, what if an author has a need to do something like <div role="list"></div> because they have a need to expose an empty list? In that case, I think we have two choices:

• Remove the current required owned elements (listitem and group→listitem)
• Modify the definition of "required owned elements" to indicate that they are required when the element in question has children

My vote is for the latter.

[rdeltour]

Note that this issue potentially impacts the DPUB ARIA extension, which currently relies on the required context role being an ancestor, not the direct parent (in the semantic tree, i.e. no-role elements being ignored).

For instance, doc-biblioentry is a subclass of listitem and is intended to be used as a list child:

Authors MUST ensure that elements with role doc-biblioentry are contained in, or owned, by an element with the role list

but is also specifying a required context role of doc-bibliography, which is itself a landmark.

See the markup example 7 of DPUB ARIA 1.0:

<section role="doc-bibliography">
   <h1>Select Bibliography</h1>
   <ul>
      <li role="doc-biblioentry" id="faulkner-dying">
         William Faulkner, As I Lay Dying (New York: Jonathan Cape & Harrison Smith, 1930)
      </li>
   </ul>
   …
</section>

[joanmarie]

Meta comment regardless of the direction we take: I suspect that we will get some pushback from user agents if we normatively require (MUST) them to sanity-check the new, more strict language. If we want to be able to ship things, I think we'll want to SHOULD the user agents and MUST the authors. That way, validators can complain loudly.

[mattgarrish]

Note that this issue potentially impacts the DPUB ARIA extension

Late to the party after being away for a couple of weeks, but, yes, it effects cleanup we'd have to do to the specification to properly align with the new requirement, but it's not a breaking change.

We wanted to establish that bibliography entries are expected inside a bibliography section (and term/def inside a glossary), but not having that as an ownership requirement shouldn't be an issue. It sort of happens logically, anyway.

[joanmarie]

Potentially related: We have language which says things like:

Authors MUST ensure elements with role treeitem are contained in, or owned by, an element with the role group or tree.

Does that mean a treeitem must be a direct child of a group or tree, or any descendant? Regardless of the answer, perhaps we can also clarify what "contained in" means as part of this fix?

[MelSumner]

<div role="list">
  <div>
    <div role="listitem">One</div>
  </div>
  <div>
    <div role="listitem">Two</div>
  </div>
</div>

I wonder if allowing this would be confusing, since the equivalent in semantic HTML is not valid?

Example (this is invalid):

<ul>
  <div>
    <li>One</li>
  </div>
  <div>
    <li>Two</li>
  </div>
</ul>

[stes-acc]

Currently validators (for some lugubrious reasons) don't apply always the same strict nesting rules for markup with ARIA as for plain HTML.

There are many other examples.

[scottaohara]

@MelSumner per your test cases, i created this codepen to show how these patterns are interpreted by jaws/nvda/vo/talkback
https://codepen.io/scottohara/pen/gOrzrmJ

support has actually improved in some cases, even from a few months ago where invalid nesting / severing the direct parent child relationship between the list/list items would cause more instances of significant issues than i'm finding (though some of those still did occur).

[jnurthen]

#1033 related