Bump vnu-jar from 21.6.11 to 21.9.2

[dependabot]

Bumps vnu-jar from 21.6.11 to 21.9.2.

Release notes

Sourced from vnu-jar's releases.

latest

c2cdd4a054360f764ff74022525e3bc457c9feff — Drop some no-longer-needed filters

Commits

• 2022031 Roll back to latest Jetty 9 (9.4.43.v20210629)
• be0bcb0 Revert "Add Jetty backend HTTP/2 support (clear text, h2c)"
• f86bde2 Update css-validator
• 956ed34 Update css-validator
• 11e9ee1 Update Jetty to 10.0.6; javax.servlet-api to 4.0.1
• b1dd328 Update css-validator
• 93c88bd Update css-validator
• f5384f4 Drop another no-longer-needed filter
• 21ea635 Update css-validator; drop some no-longer-needed filters
• 4d79cda Dockerfile: Bump unzip version
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[XhmikosR]

@patrickhlauke should we just ignore these errors?

[patrickhlauke]

An "aria-disabled" attribute whose value is "true" should not be specified on an "a" element that has an "href" attribute. are warnings, not hard errors.

per https://www.w3.org/TR/html-aria/#docconformance

It is NOT RECOMMENDED to use aria-disabled="true" on an a element with an href attribute.

NOTE
If a link needs to be "disabled", remove the href attribute.

to be cleaner though, it may actually be better to do what the recommendation there is an remove the href and the aria-disabled="true" altogether. but it's not a hard failure either way

[XhmikosR]

I'm not sure if we should remove the href attribute in all of those cases, though. That's why I was leading towards to just disabling the error 😛

But if you or anyone else wants to take a stab at it and see it in action, fine by me!

[patrickhlauke]

ah, i only looked at a few (where the intent in the docs was clearly to show disabled styling). i think we should do both - set to ignore the warning, but also go through docs example usage of links with aria-disabled="true" to see if they shouldn't just be neutralised and turned into <a> elements without href altogether

[XhmikosR]

@patrickhlauke if you are up to make a PR we'll need to backport this.

[patrickhlauke]

for how long will we be backporting doc tweaks to v4? (to be clear, that PR #34886 still needs this check disabled in vnu, as we do give at least one less-than-ideal example that would fail validation)

[XhmikosR]

We will be supporting v4-dev for some more time for sure. Not sure for how much exactly at this point, though.

I don't mind disabling the check, although we won't catch any other cases if we disable the rule. Just pointing it out :)

[patrickhlauke]

I don't mind disabling the check, although we won't catch any other cases if we disable the rule. Just pointing it out :)

but again, we need it disabled because we have a non-ideal example or two (but only a warning, not a hard error) in the docs, even after #34886 is merged) - to show that yes, this can be done, and then explain to the reader the better alternatives

[XhmikosR]

I know, I meant it mostly that we wouldn't notice any further cases after we ignore this :)

[XhmikosR]

I disabled it, feel free to edit the JS file to add a comment for future reference :)

[XhmikosR]

BTW we can always go back to treating warnings as warnings and not errors if you think that's better @patrickhlauke. Otherwise please have a look an maybe add a comment about the new suppression, otherwise we can land this :)

[patrickhlauke]

maybe add a comment about the new suppression

done