chore: update roles with interactive info

[straker]

The information was taken from https://www.w3.org/TR/html-aria/#allowed-aria-roles-states-and-properties

This is a precursor to #601. From reading the discussion in that issue, there was a lot of concern with false positives of nested roles. For example, a menuitem cannot have interactive descendants but is allowed a menu which could have a menuitem.

To address that, I believe the following algorithm works in all listed cases of that pr:

1. find all interactive roles which have interactiveDescendant: false. An interactive role is defined as a role whose contentTypes includes interactive (this step can be done in a rule matcher)
2. loop through all descendants
   1. if the descendants HTML or ARIA role contentTypes includes flow, continue to the next descendant
      1. if the descendants HTML or ARIA role contentTypes also includes interactive then don't loop through its descendants as the algorithm will start again from that descendant
   2. else if the descendants HTML or ARIA role contentTypes includes interactive it fails

This should catch all the issues brought up in the original issue, allowing menuitems to have menu children as it is both flow and interactive (causing the algorithm to break and start again from there). It should also catch ARIA buttons having nested HTML interactive elements such as anchors or buttons.

Reviewer checks

Required fields, to be filled out by PR reviewer(s)

• Follows the commit message policy, appropriate for next version
• Code is reviewed for security

[WilcoFiers]

I'm guessing you didn't mean to put this in?

[WilcoFiers]

If this is exclusively based on whether contentType includes "interactive", this is redundant. I'm not sure this is the right solution though. What I was thinking is to look at ARIA's "presentational children" property. The issue isn't that screen readers just don't know how to deal with nested interactive elements. It's that anything you put inside of an element with presentational children will not be included in the accessibility tree. Not just interactive stuff either:

The image in this button is not in the accessibility tree. This button wouldn't be announced as having an image inside it. But if you put role=link on the button, it will be.

<button><img src="..." alt="hello" /></button>

There are interactive elements that require other interactive children. Combobox and listbox jump to mine. I suspect you can also do it with links without causing accessibility problems. ARIA definitely says you can, but we should probably test that to be sure.

[straker]

Closing per Wilcos comment (making a new PR with presentational children instead)