axe-core
axe-core copied to clipboard
Report case sensitivity issues
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:
-
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.
-
In such cases, it would be good for axe-core to explicitly call out that the item was failed because of case sensitivity.
-
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.
May be enough to typecast the result of getRole(). We'll need to test if this works reliably.
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
@WilcoFiers close?
This is an ongoing discussion, see https://github.com/w3c/html-aria/issues/280, https://github.com/w3c/html-aria/pull/287 and https://github.com/w3c/aria/issues/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.
what about Dragon?
@dylanb looking at the extension code it should be ok
I see the line role = role ? role.toLowerCase() : "";
@WilcoFiers , if Dragon does in fact support all cases, then I think we should put this into the category of warning
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.
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)
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.
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.
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?
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.
@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.
Right on. I think that I can do all this. Hard to say when, but I will try.
Should I create a new issue for the case-insensitive part?
Nah, we'll do it when we're ready
Okay.
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.
@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 calltoLowerCase
on the role before it passes it toisValidRole
(that will stoparia-roles
from failing on the roles). We'll then want to add a new check to thearia-roles
rule that specifically looks for roles that are not all lower case and flag them as Needs Review (i.e. returnsundefined
) 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.
@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.