Clarify "required owned element" #1033

WilcoFiers · 2019-08-14T12:45:42Z

Any element that will be owned by the element with this role. For example, an element with the role list will own at least one element with the role group or listitem.

As a non-native English speaker, this first sentence doesn't make sense to me. It doesn't seem to say anything, rather it seems like an unfinished sentence. As though what it should have been is "Any element that will be owned by the element with this role MUST be one of the required owned elements", but the sentence got clipped.

Then in the second sentence it says "will own at least", even though that is followed by a paragraph explaining how there are cases where a list can be empty. Which strongly implies that something like this would be fine:

<div role="list">
  <div role="listitem">List item</div>
  <div> not a list item</div>
</div>

This "at least one" is especially confusing. Should this have been all owned elements SHOULD have a role from the required owned elements list?

JAWS-test · 2019-08-24T02:00:36Z

In this context, it should be clarified whether all child elements that do not belong to the required owned elements automatically have role=presenation implicitly or not. If this is always the case, this should be added to the specification when defining required owned. If this is not always the case, it should be explicitly specified for each role whether it is the case or not.

Currently, it is handled differently by the browsers depending on the role and element:

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="utf-8">
		<title>required owned element</title>
	</head>
	<body>
		<h1>List</h1>
		<div role=list>
			<input type=checkbox aria-label="checkbox in role=list">
			<div role=listitem>li1</div>
			<div role=listitem>li2</div>
			<h3>heading in role=list</h3>
		</div>

		<ul>
			<input type=checkbox aria-label="checkbox in ul">
			<li>li3</li>
			<li>li4</li>
			<h3>h3 in ul</h3>
		</ul>	

		<h1>Table</h1>
		<div role=table>
			<input type=checkbox aria-label="checkbox in role=table">
			<div role=row><span role=columnheader>ch1</span><span role=columnheader>ch2</span></div>
			<div role=row><span role=cell>c3</span><span role=cell>c4</span></div>
			<h3>heading in role=table</h3>
		</div>

		<table>
			<input type=checkbox aria-label="checkbox in table">
			<tr><th>th1</th><th>th2</th></tr>
			<tr><td>td3</td><td>td4</td></tr>
			<h3>h3 in table</h3>
		</table>	

		<h1>Listbox</h1>
		<div role=listbox>
			<input type=checkbox aria-label="checkbox in role=listbox">
			<div role=option>opt1</div>
			<div role=option>opt2</div>
			<h3 aria-select=true>heading in role=listbox</h3>
		</div>

		<select size=2>
			<h3>h3 in select</h3>
			<option>opt3</option>
			<option>opt4</option>
			<input type=checkbox aria-label="checkbox in select">
		</select>	

		<h1>Tablist</h1>
		<div role=tablist>
			<input type=checkbox aria-label="checkbox in role=tablist">
			<div role=tab>tab1</div>
			<div role=tab>tab2</div>
			<h3>heading in role=tablist</h3>
		</div>
	</body>
</html>

Results (with IE 11 and Chrome, JAWS 2019):

role=list

h3 and checkbox: not a list item, but part of the list

ul

h3 and checkbox: not a list item, but part of the list

role=table

h3 and checkbox: not a table cell, but part of the table

table

h3 and checkbox: not part of the table

role=listbox

h3 and checkbox: ???

select

h3: part of the select, but no output
checkbox: not part of the select

tablist

h3 and checkbox: not a tab, for me not determinable, whether part of the tablist

JAWS-test · 2019-12-13T19:58:09Z

Perhaps it is better not to define the required elements, but the permitted ones. Then one avoids the problem that e.g. an empty selection list is possible in HTML, but not in ARIA. See w3c/aria-practices#468 (comment)

WilcoFiers · 2020-01-20T20:31:36Z

@jnurthen I want to reraise this issue as part of my feedback on the wide review draft. I would appreciate an explanation of why this is not being addressed in ARIA 1.2. A simple clarification would be sufficient, as to whether or not "required owned elements" means all owned elements need to be of the given type, or if it permitted that other elements can be owned, as long as one of the owned elements is of the permitted type.

Change is motivated by issue w3c#1033

WilcoFiers · 2020-08-26T11:21:31Z

@jnurthen Would it be possible to get an explanation of why this will not be addressed in WAI-ARIA 1.2?

I think there is a substantial problem in the way "required owned element" works. At least one of the following patterns is not valid, but it isn't clear which one. Both of them seem completely reasonable to me:

List without content:

<label>
  Todo: <input type="text">
</label>
<button>Add</button>
<ul id="todo-list"> <!-- empty until a user adds something --> </ul>

Radiogroup with some radiobuttons:

<div role="radiogroup" aria-label="Search options">
  <input type="radio" id="restrict">
  <label for="restrict">English</label>

  <input type="radio" id="university" checked>
  <label for="university">University</label>
</div>

This second one is borrowed from an issue in the ACT-rules repo (act-rules/act-rules.github.io#1426).

carmacleod · 2020-08-27T18:29:03Z

@WilcoFiers Apologies - I saw your comment yesterday, forgot that you already provided a PR, and I typed something up and created a new PR. I will look through your PR, re-read all of the comments above, and probably delete my new PR... but maybe there are some words that can be incorporated. Will let you know.

carmacleod · 2020-08-29T16:25:59Z

@WilcoFiers
Let me try to restate the problems with the current definition of "required owned element" that we are trying to resolve in this issue:

the wording of the initial sentence is confusing
the words "at least one" are problematic because an empty list needs to be valid
need to allow for the possibility of owned elements that are not in the list of required owned elements

I think your PR solves 1, but not 2 or 3?

So, keeping in mind the definition of Owned Element:

An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child.

how about the following:

Required Owned Elements
The role required for owned elements in order to complete the semantics of this role.
For example, an element with the role list will own elements with the role listitem.
All owned elements SHOULD have a role from the list of required owned elements.

Notes:

first sentence includes "The role" (although maybe it should be "A list of roles" or "A set of roles", but "The role" is simpler?)
first sentence explains why the role is required (i.e. to complete the semantics of a given role)
second sentence does not contain "at least one", to allow for empty state
third sentence is new. It uses "SHOULD" instead of "MUST", to allow for label in radiogroup, etc

WilcoFiers · 2020-09-08T09:58:28Z

@carmacleod Thanks for looking into this. You are right that my proposal doesn't solve everything I'm raising here now. The radiogroup > label example is new to me.

I think changing this to SHOULD will result in tools ignoring this. If we can find another solution, I think I'd prefer that. In thinking more about the radiogroup example, radiogroups, unlike most other required context roles, don't really need to have a parent-child relationship:

It seems to me that the following shouldn't be valid ARIA:

<div role="list"> <div role="article"> <div role="listitem">

But this probably should be:

<div role="radiogroup"> <div role="article"> <div role="radio">

The other thing I realised as I was reading your reply is that "owned elements" doesn't just apply to an element's children, but to all its descendants. That's clearly incorrect too. All children of a list must be listitems, but the descendants of thost listitems don't have to be listitems too. That's completely different from radiogroups, where it really doesn't matter if the radiobutton is a child or some lower down descendant.

I think radiogroups are completely different from lists, grids, etc. It might be better to just not give them a requirement. That way required owned element can be used for things that need that strict parent-child relationship, and we can keep that MUST in.

WilcoFiers · 2020-09-30T09:48:57Z

@carmacleod @jnurthen any update on this?

mcking65 · 2020-10-01T18:51:41Z

@carmacleod wrote:

Let me try to restate the problems with the current definition of "required owned element" that we are trying to resolve in this issue:

the wording of the initial sentence is confusing

the words "at least one" are problematic because an empty list needs to be valid

need to allow for the possibility of owned elements that are not in the list of required owned elements

In the call today, @smhigley pointed out that if we solve both 2 and 3, then required owned elements would be meainingless. No elements would be required per item 2 above. Any particular kind of element would be allowed per item 3. I agree with her observation.

I am pretty certain that the origin of required owned elements is that the element that requires specific descendants is not complete or valid if it does not contain at least one of the required owned elements. I have always understood it that way. If an empty list is allowed, then it should not have any required owned elements.

At the same time, required owned elements has never been restrictive. In other words, it does not mean the same thing as "allowed" or "permitted" elements. ARIA does not currently have a concept of permitted descendants except where explicitly stated in prose via normative author must requirements.

I think this issue should be limited to clarifying that required owned elements means "at least one" of the required owned elements is required. If there are cases where we list required owned elements where in fact none are required, e.g., list, then we should fix that by removing the required owned elements from those roles, in a separate PR.

If we want to add a specific "permitted" elements type of requirement to ARIA, that too should be a separate issue.

carmacleod · 2020-10-01T23:50:04Z

I think it makes sense to wait on a final definition of Owned element first (see #748) and then we can work on refining the definition of Required owned elements.

WilcoFiers · 2020-10-05T10:15:03Z

@mcking65 I definitely see your point about "permitted" vs "required". That's a fair distinction to make.

Going through the list, I'm not too sure there are any required owned elements in that case. The ARIA 1.1 combobox pattern is the only one that comes to mind, but that too is no longer valid. Everything else seems like it can be empty.

jnurthen · 2020-11-18T19:04:39Z

Discussed in WG call on 11/12/2020

**JN:** this one we have a PR, is that correct? … this is dependant on a different one … #748, is that done? … no … so this is now dependent on something else, who wants to think about this one? … because these all need resolving

CM: is this all kind of rolled into what is a descendant

MK: no this is different, this is about what does required owned elements mean

JN: so does required own elements -- we really mean allowed owned elements

MK: no we dont actually, so that is the question on the table. There are several scenarios that are different. There's this question of things in a tablist because we don't list button as a required owned element, is it actually an allwed element, or is illegal to put a button in a tablist
… so you can put a button in a tablist for a context menu, and stuff like that
… so does required exclude other things? does it mean allowed? how exclusionary is it, does it exclude generic? And does it mean a child or a descendant?
… none of that is clear from the definition

CM: do we need another entry in the characteristics, so required means required, and we can add allowed?

MK: I don't know, because right now in menu you can have group or menuitem, but you don't have to have both, you can have one or the other
… and list, you have them marked as required but you can have an empty list

SH: I think required is difficult because for most things you can have an empty container

JN: I think in most cases required means allowed, but maybe there are more things that should be added to that?

MK: in most cases allowed sounds exclusionary

JN: in most cases I've read required as exclusionary

SH: currently although I see a use case some times for other elements, it breaks certain AT behavior if it's not exclusionary

JN: so if that's not the intention, we should clarify

MK: yeah we would break the empty container thing if we changed it to required

JN: Matt, in your comment earlier:

jamesn: At the same time, required owned elements has never been restrictive. In other words, it does not mean the same thing as "allowed" or "permitted" elements. ARIA does not currently have a concept of permitted descendants except where explicitly stated in prose via normative author must requirements.

JN: is that true that ARIA doesn't have a concept of perimtted descendants? because if that's not true maybe we should just drop required owned elements

MK: yeah I wish I had dropped some examples in here. I think this is a place where we should do some analysis

JN: actually so doesn't the required owned elements thing hit presentation as well?

SH: only if you interpret it as children and not descendants
… I think I have a list of all the roles that have required owned elements in a blog post

MK: that would be great to have in a comment in the issue
… so we could interpret if it could be allowed without breaking anything
… I know there are a lot of things that exist in the real world where things would become illegal if it were changed to allowed. That doesn't mean we can't do that, but what we might want to do...
… is just be thoughtful about on some of these containers if maybe... yeah, I guess we do need to think about if some things... like if we have a menu with no menuitems, should we require at least one menuitem or one group to be a menu
… but will it break AT if we allow an empty container?

SH: an empty menu should be allowed for authors, and AT can treat it as not a menu

MK: so if the browser were to handle that in the recovering from errors section, maybe we could leave that menu
… i think it would be immensely helpful to add that list of elements that have required owned elements to the issue
… I think this is a topic that needs to be discussed with the group

sarah higley: ah, sorry, just wanted to prevent zakim from complaining when I closed the topic

JN: I have no problem with containers being empty, a screen reader should just ignore it

IH: what should happen if the container gets focused

JN: generally the containers shouldn't get focuseed unless someone has messed up anyway

MK: yeah, they're all containery

JN: a listbox with nothing in it is focusable, but is allowed in HTML

MK: a lot of those are focusable because they support activedescendant
… so is one of the questions here in some of these cases would it be necessary to have both allowed an required? Do we need both concepts? If we change required to allowed, do we lose anything?

jamesn: https://www.w3.org/TR/wai-aria-1.2/#mustContain

MK: are empty grids and tables something to allow? Because currently they're not permitted

JN: right now none of these things are allowed, which seems wrong

SH: I think there's a solid use case, e.g. when users can remove rows and they remove all rows

JN: or you can hide columns, and hide all columns
… so here's it's saying that essentially it's invalid if you do not have a listitem in a list

MK: which disagrees with html, same with listbox
… so in html is an empty table tag permissable markup?

JN: I don't know
… I mean, it's not going to cause any problems, things are just going to ignore it right?

MK: I don't know, but I think I would like to know that

JN: anyone want to investigate native html behavior for each of these things and work out what happens there?

MK: there's only four: definition/associationlist, table, list, listbox

IH: should I have a go at that?

JN: of course! and you can hassle Scott, that's even better

CM: so you're asking for two things? What does HTML say, and what does AT do?

JN: yeah, I think we should work out whether HTML allows an empty table or row, then we should work out what actually happens in accessibility APIs

MK: I said there were only four, but now that you bring that up, can you have an empty row, or table body?

JN: yeah we should, but we should probably start with investigating just the top-level things. We don't need a complete analysis

JD: I agree in spirit with "also see what ATs do" but ATs are often working around browser and author weirdness, so as an interim step we should look at what is exposed to us using accessibility inspectors, independent of what the screen reader is actually saying

JN: yeah, I agree Joanie
… Isabel, if you need help please ping me

jnurthen added this to the ARIA 1.2 milestone Aug 15, 2019

mcking65 mentioned this issue Aug 22, 2019

Implicit role=presentation except for Required Owned Elements #1034

Closed

straker mentioned this issue Sep 4, 2019

rule: aria-allowed-children dequelabs/axe-core#925

Closed

WilcoFiers mentioned this issue Oct 23, 2019

<ul role="menubar"> not recognizing <li><a role="menuitem"></a></li> as a descendent dequelabs/axe-core#1171

Closed

jnurthen mentioned this issue Nov 18, 2019

Add normative text to menuitem and treeitem about allowed child elements #1120

Open

jnurthen modified the milestones: ARIA 1.2, ARIA 1.3 Nov 19, 2019

WilcoFiers added a commit to WilcoFiers/aria that referenced this issue Jan 21, 2020

Clarify the intent of "required owned elements"

d936e01

Change is motivated by issue w3c#1033

WilcoFiers mentioned this issue Jan 21, 2020

Clarify the intent of "required owned elements" #1162

Closed

scottaohara added the has PR PR exists that will close this issue label Jan 23, 2020

carmacleod added the WR comments label Mar 2, 2020

carmacleod linked a pull request Mar 2, 2020 that will close this issue

Clarify the intent of "required owned elements" #1162

Closed

JAWS-test mentioned this issue Apr 22, 2020

May a treeitem contain interactive elements? #1251

Open

kasperisager mentioned this issue Aug 26, 2020

ARIA required owned elements (bc4a75): Elements should be allowed children _not_ required by their role act-rules/act-rules.github.io#1426

Open

jnurthen added the Agenda label Aug 26, 2020

carmacleod self-assigned this Aug 27, 2020

carmacleod mentioned this issue Aug 27, 2020

Clarify "required owned element" #1314

Closed

ajanec01 mentioned this issue Sep 15, 2020

Editorial fix for aria-required-owned as per TF feedback act-rules/act-rules.github.io#1448

Merged

jnurthen mentioned this issue Oct 1, 2020

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

Open

WilcoFiers mentioned this issue Oct 9, 2020

AGENDA ITEM: Rules ready for W3C publication act-rules/act-rules.github.io#1120

Closed

jnurthen removed the Agenda label Oct 14, 2020

WilcoFiers mentioned this issue Oct 22, 2020

False negative: 'aria-required-children' rule does not ensure all the child elements have an appropriate role dequelabs/axe-core#2576

Closed

jnurthen mentioned this issue Nov 18, 2020

Unclear use of the term "descendant" #1150

Closed

iamrafan mentioned this issue Nov 19, 2020

Can a list have children that are not listitem (or group) microsoft/accessibility-insights-web#3486

Closed

jnurthen added Agenda and removed Agenda labels Dec 9, 2020

jnurthen assigned smhigley Mar 3, 2021

smhigley mentioned this issue Mar 10, 2021

Nested menus vs. required owned elements #1425

Open

Jym77 mentioned this issue Mar 11, 2021

Resolve "ARIA required context role" survey comments w3c/wcag-act#507

Open

5 tasks

smhigley mentioned this issue Mar 26, 2021

Secondary actions on items in composite widget roles #1440

Open

smhigley mentioned this issue Apr 13, 2021

Update required owned elements and required context role #1454

Merged

8 tasks

jnurthen unassigned carmacleod Apr 26, 2022

hzr mentioned this issue Aug 25, 2022

useRadioGroup intercepts all arrow key presses leading to unexpected behavior adobe/react-spectrum#3447

Closed

tesk9 mentioned this issue Feb 21, 2023

aria-required-children violation for tablist role dequelabs/axe-core#3915

Closed

spectranaut closed this as completed in #1454 May 1, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify "required owned element" #1033

Clarify "required owned element" #1033

WilcoFiers commented Aug 14, 2019

JAWS-test commented Aug 24, 2019

JAWS-test commented Dec 13, 2019

WilcoFiers commented Jan 20, 2020

WilcoFiers commented Aug 26, 2020

carmacleod commented Aug 27, 2020

carmacleod commented Aug 29, 2020

WilcoFiers commented Sep 8, 2020

WilcoFiers commented Sep 30, 2020

mcking65 commented Oct 1, 2020

carmacleod commented Oct 1, 2020

WilcoFiers commented Oct 5, 2020 •

edited by carmacleod

Loading

jnurthen commented Nov 18, 2020

Clarify "required owned element" #1033

Clarify "required owned element" #1033

Comments

WilcoFiers commented Aug 14, 2019

JAWS-test commented Aug 24, 2019

role=list

ul

role=table

table

role=listbox

select

tablist

JAWS-test commented Dec 13, 2019

WilcoFiers commented Jan 20, 2020

WilcoFiers commented Aug 26, 2020

carmacleod commented Aug 27, 2020

carmacleod commented Aug 29, 2020

WilcoFiers commented Sep 8, 2020

WilcoFiers commented Sep 30, 2020

mcking65 commented Oct 1, 2020

carmacleod commented Oct 1, 2020

WilcoFiers commented Oct 5, 2020 • edited by carmacleod Loading

jnurthen commented Nov 18, 2020

WilcoFiers commented Oct 5, 2020 •

edited by carmacleod

Loading