Clarify "required owned element"

5.2.5 Required Owned Elements:

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?

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

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)

@jnurthen

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

Clarify the intent of "required owned elements"

@jnurthen

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

@WilcoFiers

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

@WilcoFiers

@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

@carmacleod

@carmacleod @jnurthen any update on this?

@carmacleod

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

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.

@mcking65

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

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

Navigation Menu

Repository navigation

Clarify "required owned element" #1033

role=list

ul

role=table

table

role=listbox

select

tablist

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Clarify "required owned element" #1033

Description

Activity

JAWS-test commented on Aug 24, 2019

role=list

ul

role=table

table

role=listbox

select

tablist

JAWS-test commented on Dec 13, 2019

WilcoFiers commented on Jan 20, 2020

WilcoFiers commented on Aug 26, 2020

carmacleod commented on Aug 27, 2020

carmacleod commented on Aug 29, 2020

1 remaining item

WilcoFiers commented on Sep 30, 2020

mcking65 commented on Oct 1, 2020

carmacleod commented on Oct 1, 2020

WilcoFiers commented on Oct 5, 2020

jnurthen commented on Nov 18, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions