Div actionverbs withattributes rule

[Felicia5]

#Addressed user stories:

1. As a developer, I would like ESLint to warn me when I attempt to use the two attributes (tabindex=”0” role=”button”) that makes div elements interactive, use
   elements with a call to action verb within the opening and closing tags for example “apply” or “submit”, but the values of one or both of the attributes are missing or are wrong and provide the right values in the error message, so that I can correct my mistake right away.
2. As a developer, I would like ESLint to warn me when I miss to add or wrongly add the tabindex=”0” attribute that makes div elements interactive, use
   elements with a call to action verb within the opening and closing tags for example “apply” or “submit”, and provide the right values in the error message, so that I can correct my mistake right away.
3. As a developer, I would like ESLint to warn me when I miss to add or wrongly add the role=”button” attribute that makes div elements interactive, use
   elements with a call to action verb within the opening and closing tags for example “apply” or “submit” and provide the right values in the error message, so that I can correct my mistake right away.
4. As a developer, I would like ESLint to warn me when I create an optional component e.g.: with a name that is a call to action verb for example “apply” or “submit”, and I do not put a call to action word inside the opening and closing tags but leave it empty or use a noun instead sot that I am reminded to correctly use my CTA components consistently.

#Flowchart:

Table 1

details the first case when the role attribute is defined correctly but there are problems with the tabindex attribute. The attribute can be missing, undefined, has empty string as its value or has wrong value: “-1” or “1”. In these cases the error message “Missing or incorrect tabindex attribute…” should be displayed to the developer.

Table 2

details the second case when the tabindex attribute is defined correctly but there are problems with the role attribute. The attribute can be missing, undefined, has empty string as its value or has wrong value: “main” / “navigation”. In these cases the error message “Missing or incorrect role attribute…” should be displayed to the developer.

Table 3

details the third case when there are problems with both attributes, the tabindex and role attributes. Each attribute can be missing, undefined, has empty string as its value, has wrong value. The wrong values can be “-1” or “1” in case of tabindex attribute and “main” / “navigation” in case of role attribute. Table 3 is constructed by combining the cases of Table 1 and Table 2. Tabindex attribute has five different incorrect cases. Each case can be combined and listed with the five different incorrect cases of role attribute. It does not matter if the attributes are present in order of tabindex=”0” role=”button” or role=”button “ tabindex=”0”. Therefore, following the laws of combinatorics the number of invalid cases is 5 x 5, which is 25 different invalid cases. In these cases, the error message “Missing and/or incorrect attributes…” should be displayed to the developer.

[ljharb]

Looks like this PR contains three new rules - could perhaps 2 of them be split off into individual PRs, so they can be evaluated on their own merits?

[jessebeach]

Hi @Felicia5, thank you for this comprehensive change proposal. You evidently comprehend the purpose of this plugin.

From what I understand, you're proposing 2 concepts here:

1. Assert that an interactive element has text content, by which you're assert, a text node
2. Assert that an interactive element has an action word

For assertion #1, yes, it is preferable for interactive element to be constructed with text content. That will reduce the risk of the visual label diverging from the accessible label. But text content isn't strictly necessary. It's a direction I'm willing to consider, but we wouldn't make this rule required. One tenet of the philosophy of this plugin is that the experience in the assistive technology must be correct and one can achieve a correct experience without a text node in an interactive element, using instead ARIA attributes to associate a label to an element that is transmitted to the accessibility tree. Practically, there are several changes to the implementation I will request if you plan to continue with this PR.

For assert #2 (apply), the approach here probably won't work. The biggest hurdle is internationalization. We cannot hard code a vocabulary into the plugin and then only in English. Configuration just isn't a scalable solution for this rule give hundreds of languages one might want to translate this rule into. I recommend removing this rule from the PR to continue forward with it.

Thank you for your enthusiasm and initiative with this proposal! Do you plan to continue with it and complete the required content assertion?