Ambiguity in DPUB-AAM for listitem children(?) of doc-bibliography and doc-endnotes

[cookiecrook]

The following DPUB-AAM mappings:

• https://w3c.github.io/dpub-aam/#role-map-biblioentry-implied
• https://w3c.github.io/dpub-aam/#role-map-endnote-implied

…both use the prose:

listitem descendants of [accessibility parent role name] (not descendant of another listitem)

Which I think is intended to mean children:

listitem accessibility children of [accessibility parent role name]

(where "accessibility children" is the ARIA definition...)

But perhaps there is some other reason for the additional complexity? For example, as phrased, it also pulls in the following, which I think is unintentional.

<ul>
  <li>
    <ul role="doc-bibliography">
      <li><!-- this is a lisitem descendant (direct child) of doc-bibliography that is also a descendant of another listitem  -->

In any case, I blocked the WPT computedrole tests for those two until the working group resolves the ambiguity.

Editorial Note: there are also some typos in these same headings:

• ofanother in #role-map-biblioentry-implied
• another<code>listitem</code> in #role-map-endnote-implied (missing space after another)

[cookiecrook]

Well shoot... I filed this on DPUB-ARIA not DPUB-AAM. Thanks if you can move it.

[mattgarrish]

The problem that led to doc-biblioentry and doc-endnote being deprecated in 1.1 is that doc-bibliography and doc-endnotes are not list roles, so you'd use them on a section tag, for example.

This rule, as I recall, is trying to imply the doc-biblioentry and doc-endnote roles on the immediate children of top-most list within its respective section, without capturing lists within the bibliography entry or endnote.

For example:

<section role="doc-bibliography">
   ...
   <ul>
      <li> <-- implied doc-biblionetry
         ...
         <ul>
            <li> <-- not a biblioentry
               ...
            </li>
            ...
         </ul>
      </li>
      ...
   </ul>
</section>

[cookiecrook]

@mattgarrish wrote:

… on the immediate children […] without capturing [descendant] lists within the bibliography entry or endnote.…

Okay then I think the spec should consider this pseudo diff, which would be more precise and unblock the related tests.

- listitem descendants of [accessibility parent role name] (not descendant of another listitem)
+ listitem children of [accessibility parent role name]

[cookiecrook]

Actually the first child <ul> in your example breaks that proposed diff. Hmm… No rush, but once you figure out a precise phrasing, that will unblock the two remaining tests.

[mattgarrish]

Actually the first child <ul> in your example breaks that proposed diff.

Right, the implied roles are always children of a list role, which is descendant of (doc-bibliography|doc-endnotes). By saying "listitem descendants of [...]" we skip over the list.

If you wanted to include the list, and have them identified as children, it would have to be more like:

listitem accessibility children of a [accessibility parent role name] that is descendant of (doc-bibliography|doc-endnotes) and not descendant of another listitem

The parent role is list, so it's maybe more accurate this way, but it's still a mouthful.

[mattgarrish]

I'm curious, though, should we even have these mappings that imply deprecated roles?

Doesn't it mean that any user agent that implements the mapping will add the deprecated roles to the list items, overriding the correct authoring that excludes the roles?

Similarly, if you use the list/listitem roles instead of ul/li in a bibliography or endnotes section, will it also override the listitem role?

It seems like it makes the situation worse than it is now, or am I misunderstanding something?

[cookiecrook]

Yikes... I didn't know they were deprecated. Good catch. I will pull those out of the WPT Pull Request, and yes, I think those should be removed (or marked as deprecated in DPUB-AAM)

[mattgarrish]

We didn't have these mappings in 1.0, so we should be able to remove them entirely.

I've been trying to figure out what issue they were supposed to solve so we don't create a new problem by removing them, but so far have had no luck. It looks like whatever discussion we had was in a meeting or by email as I can't track anything down.

I think the idea was that these implied roles would provide a means of identifying the entries if a user agent or processor wanted to do something with them. That could probably be done as notes for each role in the dpub-aria spec, rather than having the implied purpose turn into real roles as these mappings make happen.

@aleventhal @joanmarie @avneeshsingh @TzviyaSiegman do any of you have any better recollections, or any comments on removing these mappings and using notes instead? (Or just dropping the mappings and doing nothing else.)