aria-roledescription is flagged as invalid

[CamiloGarciaLaRotta]

For the following website: https://camilogarcialarotta.github.io/
The message is:

`[aria-*]` attributes are not valid or misspelled

aria-roledescription is a valid tag as per: https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription

[robdodson]

Thanks for the ticket! We may be running an older version of axe that doesn't pick this up. Possibly related to #7496

[paulirish]

@CamiloGarciaLaRotta i updated the version of axe and indeed the result did change...

"[aria-*] attributes are not valid or misspelled" is now passing..

BUT the exact same elements are failing a different rule: "[aria-*] attributes do not match their roles". This rule was passing previously.

[robdodson]

@WilcoFiers, @dylanb are y'all able to see anything that looks fishy in that output?

[paulirish]

These elements have a role of either list or listitem and apparently aria-roledescription isn't a valid attribute on these roles?

[paulirish]

@WilcoFiers @straker I have a feeling like the recent dequelabs/axe-core#1382 may resolve this ?

[robdodson]

These elements have a role of either list or listitem and apparently aria-roledescription isn't a valid attribute on these roles?

Based on a quick read of the spec aria-roledescription seems valid on any element that has a role. I thought the point of it was to help more clearly define the role:

<div role="button" tabindex="0" aria-roledescription="attachment button">family_reunion.jpg</div>

And it's listed in the inherited properties tables for listitem and list.

[straker]

I'll take a look at this for axe. As far as I'm aware in axev3.2.2, aria-allowed-attr should always pass on aria-roledescription. aria-allowed-attr should pass on aria-roledescription for a handful of supported elements/roles across all browsers, throw an incomplete result if it isn't on one of those elements (for manual review), or fail if on an element without a role. But it doesn't seem to be the case if it's throwing an error instead of an incomplete for unsupported elements.

[robdodson]

Moved this over to the Lighthouse repo. Lighthouse was crashing for my in Canary so I wasn't able to test again :\

[patrickhulce]

Latest Lighthouse (axe-core 3.2.2), fails on "[aria-*] attributes do not match their roles" (aria-allowed-attr).

This is also reproducible in the axe extension, so we'll need a fix in axe-core for this.

[patrickhulce]

@straker did you already file any issue for this we can reference or do we need to file one?

[pepinho24]

Hello,

Is it possible that this is related to the fact that a role="combobox" with aria-readonly attribute fails with the [aria-*] attributes do not match their roles when running the Lighthouse audit?

It used to be not allowed in ARIA 1.0, but is allowed in ARIA 1.1.

I have checked the source code of the AXE you are using and it seems it is not added: https://github.com/dequelabs/axe-core/blob/a4b524084cb8fd61e5ac802b3b6bc7a0d5f86668/lib/commons/aria/index.js#L436

The same is observed with role="listbox" also.

[straker]

@patrickhulce yep. dequelabs/axe-core#1517

[connorjclark]

Issue has been resolved.

[Abdull]

Issue has been resolved.

In which Lighthouse version is this issue supposed to be resolved?

When running Lighthouse 5.7.0 with Chrome 81, I still get [aria-*] attributes do not match their roles for the following websites:

• https://camilogarcialarotta.github.io/
• https://www.w3.org/TR/wai-aria-practices-1.1/examples/carousel/carousel-1.html

[patrickhulce]

@Abdull fixed in 6.0.0-beta.0 not yet released to Chrome.

[godanny86]

Ah just found: https://web.dev/lighthouse-whats-new-6.0/, so pretty soon this fix will be in Chrome Stable?