Linter Rule: `html-aria-label-is-well-formatted` false positive

[SleeplessByte]

Any single word lowercase content is flagged incorrectly:

<element aria-label="optional">...</element>

Aria labels will become part of the computed accessible name and thus can have lowercase-casing.

[marcoroth]

Thanks for bringing this up @SleeplessByte! 🙏🏼

This rule also came from the erblint-github rule, which we pretty much just ported over 1:1.

I personally don't have a strong opinion on this, but I'm interested to hear if @brunoprietog and/or @joelhawksley have an opinion on this. Looking at the erblint-github docs it seems pretty intentional that the lowercase content should be flagged.

[SleeplessByte]

I agree with the document you linked but the composed example misses. Bruno and I can probably discuss as we've done before on other projects 😬

[marcoroth]

Thanks! I'm happy to change the rule one way or another if we think it helps improve the general case 🙏🏼

[brunoprietog]

Although I can’t think of a specific case right now where it would be written in lowercase, since aria-label is mostly used in interactive controls or to name containers, I’m not sure this rule adds much, to be honest. The screen reader would read the content anyway. It seems more like a design or editorial decision than an accessibility one.

Similarly, I have some reservations about a11y-avoid-generic-link-text and a11y-no-redundant-image-alt, since they really only work in English and could certainly produce some false positives if those words appear in the text but in a different context. And even so, it wouldn't work with any content that uses I18n helpers either. The same applies to the discussion we’ve had in this PR about an edge case that you could resolve at the CSS level.

It’s possible that some rules only apply to the GitHub context but not necessarily to a general-purpose linter, as in these cases. I’m not sure if creating an exact one-to-one port of the GitHub rules should be the actual goal. For GitHub-specific rules, they can always create more custom rules on their end. Maybe we need to allow configurable parameters in the rules? And have a way to create a repository with your own custom rules? Right now, the only thing I can think of is that they could work with a Git submodule. What do you think?

It just occurred to me that there might be a scenario where you could be making a game in which the cards are written in lowercase letters and start with numbers. I remembered this after quickly building an accessible version of the Uno game with a friend, and each card actually started with the number followed by the color, which didn't necessarily have to be capitalized. Although, looking at the code, that wouldn't be flagged because the rule requires only the first letter to be capitalized. However, I can think of another scenario: what if you're building a platform for developers or an educational platform where you have attribute names in the aria-label that match the aria-label itself? That would fall under the condition that it looks like an ID and would be flagged. The word “iPhone” would also be flagged, and it would be a perfectly valid label. A labeled link embedded in the middle of a text might be another possibility, I think it's rare, but it could happen. You might also have a brand name for any product or company that must be written in lowercase according to the brand's guidelines.

I'm sorry if these are my thoughts out loud spewed out in text haha.