Incorrect ARIA usage (blocks DOM, Fetch, URL, etc.)

[annevk]

New day, new Fetch build failure:

Bad value “menu” for attribute “role” on element “aside”

I suspect this is from 55f2a5c by @dlaliberte?

As per https://w3c.github.io/html-aria/#el-aside menu is indeed not allowed here.

[annevk]

This also blocks DOM and presumably other specifications.

[saschanaz]

Hmm, perhaps there should be some tests that uses the same validator 🤔

[tabatkins]

Wait, why is WHATWG blocked on this? Do y'all have the validator in your own publishing pipeline too?

Anyway, as far as I can tell it would be a semantic regression to switch the dfn panels to naked divs rather than asides; I'm about to raise an issue asking what I'm supposed to do here for such content (since none of the other aria-haspopup values seem to be correct either).

[annevk]

Yes, we validate.

[svgeesus]

Bro, do you even validate?

[tabatkins]

Sigh, all right.

For context, this was already raised internally, but as a medium prio (as in, would be useful to fix in a week or so but not actively blocking).

I'm chatting with @scottaohara about this on Twitter right now.

[kainino0x]

WebGPU also soft-blocked on this. We continuously publish to TR and my understanding is TR won't allow publishing documents that fail validation. Because of this, our PR build checks require the TR build to pass (or admin override).

[saschanaz]

Perhaps worth unpublishing before the fix happens?

[tabatkins]

Yeah, I'm just ripping out most of the ARIA changes for now until I get accurate guidance on what to do here (since my spelunking thru MDN and Google apparently didn't yield good info).

[tabatkins]

Okay, ripped out, what's left should be valid and still useful. Version 3.11.10 will hopefully pass validation.

[saschanaz]

Fingers crossed!

[saschanaz]

It's green, thank you!

[tidoust]

The validator is green but the validator does not run JavaScript code and the generated HTML once JavaScript code has run still seems invalid: the insertDfnPopupAction method copies the <aside> inline within a <span>, which is not allowed because <aside> is sectioning content.

At a minimum, that makes it difficult for me to create tests in Reffy as I cannot reproduce the exact same DOM tree with static HTML content (browsers automatically close the previous <p> when they bump onto <aside>).

[tabatkins]

Yes, the HTML parser makes it impossible to place the panel element in the correct place in the markup. That is complely unfixable - even ignoring the panel's outermost element, the panel contains elements (ul, notably) that will also trigger that behavior. There's simply nothing I can do about that, except completely wreck the semantics of the panel by switching the entire markup to be class'd spans, which I'm not doing. Unfortunately, "saving the rendered DOM back to a static page" is not a use-case I'm targeting, and doing so would harm the more important use-cases of "people reading the spec'.

And the panel has to be at that location to receive reasonable tabbing behavior. The alternative is putting in pretty substantial effort to manually juggle tabindex values, which I'm not willing to do to satisfy a theoretical notion of validity, unless there's demonstrated real-world issues with what I'm doing.

(And remember, the situation before I made these recent changes is that the panels were all clustered at the end of the document and were only mouse-accessible. The current situation is a strict improvement over what came before.)