consider allowing other roles on the figure element

[rdeltour]

The document conformance requirements currently says that only the roles group, none, and presentation may be used on the figure element.

I believe the doc-example role should also be allowed. Possibly others too? (img/doc-cover? 'math? not quite sure about these ones).

[scottaohara]

I think adding doc-example could work out if the conformance requirements were updated to note that a figure can have this role as long as it does not contain a figcaption.

TBH, I think that's an oversight since HTML doesn't allow a figcaption outside of a figure. So if the figure were changed to a different role, e.g.role=none, that should be considered invalid.

regarding allowing image-related roles on the figure... an <img> would still need to be a child of the <figure role=doc-cover>, so I'm not sure why the role wouldn't be added to the img, or why the figure element would have been used at all?

[rdeltour]

I think adding doc-example could work out if the conformance requirements were updated to note that a figure can have this role as long as it does not contain a figcaption.

TBH, I think that's an oversight since HTML doesn't allow a figcaption outside of a figure. So if the figure were changed to a different role, e.g.role=none, that should be considered invalid.

Right. I hadn't realized at the time I opened this issue that problematic aspect of overriding the native figure role.

I believe the situation is a tad more complex however. I don't think HTML strictly forbids figcaption in the content model of figure when its role is overridden. This conformance criterion is at the element level, not at the semantics level. The problem then is that there would no longer be a "figure" semantic that the content of figcaption would actually caption, so the semantics is useless, but not strictly invalid. But then, using an aria-describedby element could "fix" the semantics relationship?

In other words, would there be anything wrong with the following markup?

<figure role=doc-example aria-describedby=caption>
  <figcaption id=caption>…<figcaption>
  …
</figure>

Out of curiosity, do you know or happen to have tested how AT deal with figure elements with an overridden role? (I'm aware of your excellent article “How do you figure?”).

All that said, I do realize that it would be much simpler and a better practice to set the doc-example role to a parent element wrapped around the figure. I don't think that shoehorning overcomplex and wacky markup options is a good rationale for changing HTML ARIA 😅, so this issue might just as well be closed as wontfix. (ping @mattgarrish, @TzviyaSiegman, wdyt?).

regarding allowing image-related roles on the figure... an <img> would still need to be a child of the <figure role=doc-cover>, so I'm not sure why the role wouldn't be added to the img, or why the figure element would have been used at all?

Right, I agree. Allowing the doc-cover role doesn't make much sense.

[scottaohara]

@rdeltour per the PR I've created referencing this issue, I've adjusted the allowances where a figure with no descendant figcaption can have any role set to it, which would then allow the doc-example.

However, if the figure has a figcaption (whose role isn't overridden) then the figure would not be allowed to have a new role set so as to not break the expected parent/child relationship for the figure and figcaption.

[mattgarrish]

I don't think that shoehorning overcomplex and wacky markup options is a good rationale for changing HTML ARIA

I think this is another issue we should take up in the next dpub-aria revision. doc-example is intended to be analogous to a figure which is why it also inherits from the section role. The figure role itself has this overlapping sense in its definition: "A perceivable section of content that typically contains a graphical document, images, code snippets, or example text."

It might be more intuitive to have it inherit from the figure role instead, and then there wouldn't be this problem with what to do about figcaption (although that problem should be addressed since it seems like it applies if you were to use group, none or presentation on the element).

[scottaohara]

seems we were responding at the same time @mattgarrish, as yes, the issues of using group, none, or presentation on a figure with child caption are being addressed in my PR.

That said, I think you're right and inheriting from figure would help clarify doc-examples intended use (so many roles inherit from section). I'd also consider updating the example to help clarify as well.

[rdeltour]

However, if the figure has a figcaption (whose role isn't overridden) then the figure would not be allowed to have a new role set so as to not break the expected parent/child relationship for the figure and figcaption.

Ah, I just now realize that I missed the new caption role in ARIA 1.2, TIL. By parent/child relationship I understand you're talking about figure/caption in ARIA, right?
I was also misled by looking at the currently published ARIA in HTML editor draft, which doesn't mention caption as the native role of figcaption elements. 😊
My bad!

It might be more intuitive to have it inherit from the figure role instead, and then there wouldn't be this problem with what to do about figcaption

but then we're hit by w3c/dpub-aria#15 and w3c/aria#1056?

[scottaohara]

I was also misled by looking at the currently published ARIA in HTML editor draft, which doesn't mention caption as the native role of figcaption elements.

yes, need to wait for ARIA 1.2 to be published before I can do some mass updates over here :)