Custom rules with class selector fail on SVGElements

[muan]

Demo: https://html-is.glitch.me/axe-core.html (see console)

Expectation:
Custom rules with selector: '.klass' should run successfully.

Actual:
Custom rules with class selectors fail with TypeError: node.className.match is not a function.

Motivation:
Our custom rules fail because there are <svg>s on the page, and that should not be the case.

This line causes this error:

axe-core/lib/core/utils/qsa.js

Line 18 in 60b3630

return result && (node.className && node.className.match(cl.regexp));

SVGSVGElement.className returns an instance of SVGAnimatedString instead of DOMString and does not have the match function. As noted on MDN:

className can also be an instance of SVGAnimatedString if the element is an SVGElement.

---

Version 2.6.1 works fine and breaks in 3.0.0+.

axe-core version: 3.1.2

Browser and Assistive Technology versions

For Tooling issues:
- Platform:  Mac

[WilcoFiers]

Odd. Thank you for reporting. We'll definitely take a look at it.

Out of curiosity, what are you using custom rules for?

[muan]

Odd. Thank you for reporting. We'll definitely take a look at it.

Thanks!

Out of curiosity, what are you using custom rules for?

Mostly to make sure custom JS behaviors are bound to interactive elements, and that they have appropriate ARIA attributes on them.

[padmavemulapati]

after hasClass 's "className !== 'string' " replaced with class attribute. And the actual bug ,
SVG elements return a SVGAnimatedString object and not a string when accessing node.className.
Fix is working fine and seeing failure on " https://html-is.glitch.me/axe-core.html ".
Verified for all axe-core versions available now.
@straker , is this enough verification , or anything else need to be QAed.

[padmavemulapati]

Thank you for confirming the validation. Closing the ticket as seeing the expected results

[dylanb]

@muan can you explain how your custom rule works? I am always interested in the rules that users create so I can take good practices and make them available to other users. If you can, could you share the code?

[muan]

@dylanb axe.run is called on load, pjax navigation, defer loading, details element toggling, etc. We can definitely create our own observers for these rules, but it is just easier for them to piggyback off axe-core's existing visibility checks and these event listeners we've already set up.

Rules for custom behaviors:

• .js-details-target, .js-menu-target: checks element.nodeName === 'BUTTON', because it installs a click handler.
• .js-menu-target: checks element.hasAttribute('aria-haspopup'), because it opens a menu.
• [role=menuitem]: checks element is focusable.

Rules for HTML tags:

• <form>: checks !element.closest('form'), so forms aren't nested.
• <summary>: uses existing axe-core checks: 'has-visible-text', 'aria-label', 'aria-labelledby', 'role-presentation', 'role-none', 'non-empty-title'.

We also have a simple nested interactive element rule (#601) that only checks against tag names (not checking role attribute).