Report case sensitivity issues

[WilcoFiers]

Saw a question come up today about:

<ul role="list">
  <li role="listItem">...</li>
</ul>

The problem is that capital letter "I" in "listItem". There are two possible issues there:

1. I'm not so sure this should be case sensitive, we should test our ARIA rules to figure out where case sensitivity matters and where it doesn't. If it followed the specs, it should be case insensitive in HTML and case sensitive in XHTML.

2. In such cases, it would be good for axe-core to explicitly call out that the item was failed because of case sensitivity.

3. It would be nice to report this particular case as needs review instead of a fail, because the implicit role here is the correct role. This is a false positive.

[WilcoFiers]

May be enough to typecast the result of getRole(). We'll need to test if this works reliably.

[jnurthen]

I'm not so sure this should be case sensitive, we should test our ARIA rules to figure out where case sensitivity matters and where it doesn't. If it followed the specs, it should be case insensitive in HTML and case sensitive in XHTML.

This is defined in https://w3c.github.io/html-aria/#case-sensitivity - it MUST be lower case only

[dylanb]

@WilcoFiers close?

[WilcoFiers]

This is an ongoing discussion, see w3c/html-aria#280, w3c/html-aria#287 and w3c/aria#1264.

I ran the following through a few AT:

<button role="heading">lower-case</button>
<button role="HEADING">upper-case</button>

The latest versions of all the AT/browser combinations axe-core supports treats the role as case insensitive. That includes Safari+VO, JAWS+IE, NVDA+Firefox, NVDA+Chrome. I found it wasn't working in my older version of Firefox, but after upgrading to the latest one, there was no issue.

In conclusion, axe-core should normalise to lower case when testing anything to do with the role attribute. When this issue was opened, I still think this was an issue, but now that Firefox has changed I think we can reasonably say that using upper case in roles doesn't matter.

[dylanb]

what about Dragon?

[jnurthen]

@dylanb looking at the extension code it should be ok
I see the line role = role ? role.toLowerCase() : "";

[dylanb]

@WilcoFiers , if Dragon does in fact support all cases, then I think we should put this into the category of warning

[WilcoFiers]

We don't really have a "warning" category. If something works, I'm not sure why would need to tell someone about it. Seems like that'd only create more noise.

[straker]

Just confirmed with @mfairchild365 that dragon is case sensitive. The following does not work in Dragon

<div role="Button">Capital B</div>
<div role="BUTTON">All caps</div>

• Dragon does this via document.querySelectorAll (case sensitive attribute values by default) but apparently this would work if Nuance decided to finally update their code… document.querySelectorAll("[role=button i]")
• Dragon will discover the element if it has an onclick attribute and then parse out that it is a button no matter what case was used (this threw me through a loop at first because I tested by adding onclick to all the buttons and it somehow worked)

[jnurthen]

Just confirmed with @mfairchild365 that dragon is case sensitive. The following does not work in Dragon

<div role="Button">Capital B</div>
<div role="BUTTON">All caps</div>

• Dragon does this via document.querySelectorAll (case sensitive attribute values by default) but apparently this would work if Nuance decided to finally update their code… document.querySelectorAll("[role=button i]")
• Dragon will discover the element if it has an onclick attribute and then parse out that it is a button no matter what case was used (this threw me through a loop at first because I tested by adding onclick to all the buttons and it somehow worked)

Looking at the code this looks correct. I was only looking at the clickable code branch not the non-clickable code branch previously.

[WilcoFiers]

Alright, in that case I think a new check in the aria-roles rule would be useful here. Have the rest be case insensitive, since that's how it's supposed to work, but call out use of uppercase as not being widely supported. Thanks for checking Dragon on this Steve.

[dan-tripp]

I've been working on this and I could use some guidance.

One hurdle is to make each check's CSS selector case-insensitive. I couldn't find a case-insensitive CSS selector option. So I used parser.registerAttrEqualityMods() to make a generic regex CSS selector option, then I used the regex "i" flag to get case-insensitivity.

For example, this lets me change page-no-duplicate-banner.json from this:
"selector": "header:not([role]), [role=banner]",
to this:
"selector": "header:not([role]), [role/='/banner/i']",

It works. But is it the cleanest way?

[straker]

Sorry, forgot to respond to this. I'll try taking a look at this in the next few days and see if I can help you with guidance.

[straker]

@dan-tripp Alright. Talked with @WilcoFiers and we decided that we just want to deal with informing users of the case sensitivity problem and deal with axe-core being case insensitive in a separate issue.

So what we'll want to do is update the invalidrole check to call toLowerCase on the role before it passes it to isValidRole (that will stop aria-roles from failing on the roles). We'll then want to add a new check to the aria-roles rule that specifically looks for roles that are not all lower case and flag them as Needs Review (i.e. returns undefined) and informs the user that roles that are not all lower case are not widely supported.

[dan-tripp]

Right on. I think that I can do all this. Hard to say when, but I will try.

[dan-tripp]

Should I create a new issue for the case-insensitive part?

[straker]

Nah, we'll do it when we're ready

[dan-tripp]

Okay.

[dan-tripp]

I'd like to note something for completeness:

Unfortunately I am very unlikely to ever finish the work that I started on this issue.

Reason being: I work at Siteimprove now. If I contributed to axe-core while working at Siteimprove, it would look a little weird.

[lsprr]

@dan-tripp Alright. Talked with @WilcoFiers and we decided that we just want to deal with informing users of the case sensitivity problem and deal with axe-core being case insensitive in a separate issue.

So what we'll want to do is update the invalidrole check to call toLowerCase on the role before it passes it to isValidRole (that will stop aria-roles from failing on the roles). We'll then want to add a new check to the aria-roles rule that specifically looks for roles that are not all lower case and flag them as Needs Review (i.e. returns undefined) and informs the user that roles that are not all lower case are not widely supported.

Hello @straker, may I work on this issue? If not, please let me know. Thanks.

[straker]

@lsprr yep! Please let us know if you have any questions. For this particular ticket we just want to add the toLowerCase part to the invalidrole check.

[padmavemulapati]

Verified with the latest dev branch code base for axe-core,
When role is upper case valid role like <div role='COMMAND' id='aria-rolesfail1'>fail</div> - earlier it is failing and now it is passing
Also for uppercase nonsensical role like '

Contents

` - this is failing even now.

Screen.Recording.2024-05-03.at.4.27.46.PM.mov

Environment:

Label	Value
Product	axe-core
Version	4.9.0(Dev Branch Code base
OS-Details	_MAC- Intel Core i7 - 11.6.8 _
BrowserDetails	Chrome Version 124.0.6367.119 (Official Build) (64-bit)