listitem role seems to be missing directory as required context role

[annethyme]

listitem (role) has this definition:

listitem (role)
A single item in a list or directory.

However, it doesn't have directory listed as one of its required context roles.

Is it a mistake that directory is not listed as a required context role?
Or is it a mistake that the definition says listitem can also be an item in a directory?

The discussion around this came up when trying to write an Accessibility Conformance Testing (ACT) Rule for required context roles: https://github.com/act-rules/act-rules.github.io/pull/255/files

[pkra]

I believe listing the superclass is sufficient here since directory is a subclass of list, cf. https://w3c.github.io/aria/#superclassrole.

[annethyme]

@pkra,
For 5.2.5 Required Owned Elements there is this note:

NOTE
An element with a subclass role of the 'required owned element' does not fulfill this requirement. For example, the list role requires ownership of an element using either the listitem or group role. Although the group role is the superclass of row, adding a owned element with a role of row will not fulfill the requirement that list must own a listitem or a group.

Having this note for the required owned elements suggests that subclasses should not be taken into consideration for required context roles either.

To back this up, feed is also a subclass of list, and that doesn't seem to be an appropriate required context for listitem.

But it is hard to tell, when nothing is explicitly specified.

[pkra]

@annethyme ah, now I'm confused, too 😄 I would have taken the absence of a similar note to be intentional but I see your point. I'm sure more knowledgeable people than me will help clarify it later this week.

[LaurenceRLewis]

Quick recommendation of grammar for the note:

NOTE
An element with a subclass role of the 'required owned element' does not fulfill this requirement. For example, the list role requires ownership of an element using either the listitem or group role. Although the group role is the superclass of row, adding a owned element with a role of row will not fulfill the requirement that list must own a listitem or a group.

Recommend change:

adding an owned element...

Not important; just thought may as well fix while your discussing. 😬

[WilcoFiers]

Very much related to this, combobox seems to be missing searchbox as a required owned element. In ARIA 1.1, combobox requires a textbox (and some other element). But searchbox, which inherits from textbox, isn't listed. According to 5.2.5 Required Owned Elements, searchbox isn't allowed in a combobox, which seems like an oversight to me, rather than something that was done intentionally.

Another important piece to this puzzle is DPUB-ARIA, which has examples like this: https://www.w3.org/TR/dpub-aria-1.0/#doc-biblioentry (Example 6)

<section role="doc-bibliography">
   <h1>Cited Works</h1>
   <div role="list">
      <p role="doc-biblioentry" id="b8cab5dd-bc24-459c-9858-7afa9da69b64">
         John Steinbeck, The Grapes of Wrath (New York: The Viking Press, 1939)
      </p>
   </div>
   …
</section>

Since list does not have doc-biblioentry as a required owned element, it seems to me that this doesn't comply to ARIA 1.1. There are other examples like that. I would go so far as to argue that the current inheritance model doesn't work with ARIA modules. Since there's no way to add a module's new roles to the required owned elements / context role of existing roles, you can't mix existing roles with new ones.

[mcking65]

Every time the directory role has been discussed, I've left thinking ... why have it? In real life, I have never seen it provide value. but, I guess it has its origins in the DPub space, where perhaps, some readers may use it to locate a TOC -- that is a pure guess. I have never used such a reader. I have never recommended the directory role be used in a web app. Maybe I should open my eyes to the possibility.

That off my chest, it has never been clear to me whether directory is a container for a list, more like a region, or a list itself.

Reading the spec from the perspective of this issue, it seems pretty clear that directory is a special kind of list. Since it is a subclass of list, it would seem it should be required to have listitem children, or children that are subclasses of listitem.

The directory role does not list any required owned elements, which is why directory does not show up as a required context role for listitem. This is most likely a bug. If the solution of adding listitem as a required owned element is nontraversial, we could easily resolve this in ARIA 1.2.

We are taking on #1011 concerning the use of group in list, and this is closely related to that.

With this perspective, however, I think we may have made a mistake having feed be a subclass of list. A feed is a collection, but not of listitems. A feed is a collection of articles.

[mcking65]

WilcoFiers commented:

Very much related to this, combobox seems to be missing searchbox as a required owned element. In ARIA 1.1, combobox requires a textbox (and some other element). But searchbox, which inherits from textbox, isn't listed. According to 5.2.5 Required Owned Elements, searchbox isn't allowed in a combobox, which seems like an oversight to me, rather than something that was done intentionally.

The defining prose of combobox allows searchbox, but I now believe that is a mistake. So, my inclination is to change the prose to explicitly prohibit searchbox as a child of combobox. Alternatively, we could make searchbox a subclass of combobox instead of textbox. However, the could create problems for existing content.

Why is it a mistake?

If my screen reader tells me something is a searchbox, what am I to believe about it? Does it work like a textbox or a combobox? Maybe the screen reader tells me it has autocomplete. I heard autocomplete ... oh goody, it works like a combobox. Well, maybe, or maybe that is just browser autocomplete. Nop, it is real search suggestions provided by the web page. Then, in that case, what is the difference between a textbox with autocomplete and a combobox? Apparently there is no difference. If there is no difference, then why have the combobox role? Ah, so one way to eliminate this problem is to deprecate the combobox role. Now, there is no confusion. A searchbox is always a textbox, and sometimes it is a textbox with autocomplete.

I'm not a super big fan of the searchbox role because it does have these ambiguities. I believe the driving force behind adding searchbox was that it has a native mobile counterpart. In hind sight, when we added it, I should have pushed harder against these ambiguities. Does a searchbox have to have autocomplete? On native mobile, they always seem to have something that looks like autocomplete=list. If it always has autocomplete, then it should be a subclass of combobox.

In ARIA 1.2, I am hoping we will revert some of the ARIA 1.1 changes to combobox such that the input element is the combobox rather than being contained by a combobox parent. In that case, it would not be possible for a combobox to contain a searchbox and this problem goes away. This is one of my primary agenda items at TPAC. The related issue that is on the TPAC agenda is #742.

[jnurthen]

My honest reaction to this is why do we have a directory role at all....
https://publicwww.com/websites/%22role%3D%5C%22directory%5C%22%22/
shows almost no usage - perhaps the solution is to obsolete it.