w3c
Are ARIA roles case sensitive or case insensitive?
Are ARIA roles meant to be case sensitive or not? Before #1457, the ARIA spec included this statement:
- Compare the substrings to all the names of the non-abstract WAI-ARIA roles. Case-sensitivity of the comparison inherits from the case-sensitivity of the host language.
The Firefox accessibility team assumed that meant ARIA roles should be case insensitive in HTML. However, as @zcorpan pointed out here:
HTML has some attribute values case-sensitive, some ASCII case-insensitive.
I can't find any guidance in the spec either way, but all three engines are case insensitive as far as I know. Am I missing some guidance or is this currently undefined?
The reason this matters to me right now is that I'm trying to fix a crash in Gecko and was about to add a WPT test which exercises it. However, I can't reasonably add a WPT test which exercises case insensitivity if the spec doesn't say it's case insensitive.
I tried to find a thread through the specs, I'm not sure if you feel it's enough.
In Section 10.2, ARIA specifies role values to be a token list. Then in Appendix A for HTML specifically, tokens are specified as Keyword and enumerated attributes; these in turn are specified by HTML to be ASCII case-insensitive.
Tangential to that, ARIA-in-HTML Section 4.4 says authors should use ASCII lowercase, and has a note that browsers treat role as ASCII insensitive but also warns that AT may still parse them differently.
What do you think?
Ah, thank you. I think the language in ARIA-in-HTML (a spec I keep forgetting about for some reason) clears this up. That said, it does suggest that ARIA roles should be lower case to be compliant, even though browsers will handle it if they aren't. That feels like a UA repair situation?
Given this, does it seem reasonable to have WPT tests which exercise case insensitivity, even though upper case characters in ARIA roles are non-compliant strictly speaking? I'd say yes, given that the goal of WPT is to ensure interop across browsers, but I'd appreciate a spot check on my thinking.
cc @cookiecrook @spectranaut regarding the WPT. But that makes a lot of sense to me to test this, especially since ARIA-in-HTML claims this to be true.
I've raised this as a new issue (for tests to be written) in accessibility interop: https://github.com/web-platform-tests/interop-accessibility/issues/192.
@jcsteh In the meantime, you could add a test to the /accessibility/crashtests dir that ensures the engine doesn't crash (without mandating the return value), and then we can use https://github.com/web-platform-tests/interop-accessibility/issues/192 to validate the later WG decision on case-sensitivity.
Testing with https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13898 it looks like role is case-insensitive as implemented in Gecko, WebKit, Chromium.
In Section 10.2, ARIA specifies role values to be a token list.
10.2 is non-normative, but https://w3c.github.io/aria/#host_general_role says
An implementing host language will provide a role attribute with the following characteristics:
- The attribute value MUST allow a token list as the value;
Then in Appendix A for HTML specifically, tokens are specified as Keyword and enumerated attributes; these in turn are specified by HTML to be ASCII case-insensitive.
https://w3c.github.io/aria/#typemapping says
token list Space-separated tokens
which says
Note: How tokens in a set of space-separated tokens are to be compared (e.g. case-sensitively or not) is defined on a per-set basis.
So ARIA needs to define that these tokens are to be compared as ASCII case-insensitive, and that ASCII case-insensitive values are conforming for documents.
You can't apply the row for "token" because role's value is not a token.
Tangential to that, ARIA-in-HTML Section 4.4 says authors should use ASCII lowercase, and has a note that browsers treat role as ASCII insensitive but also warns that AT may still parse them differently.
https://github.com/w3c/aria-in-html/ was moved to https://w3c.github.io/using-aria/ which doesn't have a section 4.4 nor any normative statement about case-sensitivity, as far as I can tell.
@zcorpan the aria in html spec is not the using aria note. I have no insight why the old aria-in-html repo wasn’t used for the actual aria in html spec…. Here is the link to section 4.4 in the aria in html spec - https://w3c.github.io/html-aria/#case-sensitivity
@scottaohara OK, thanks. I think it doesn't make sense to require lowercase, though.
i agree. but it was added as authoring guidance since it wasn't up until the last few years where anything but lowercase was consistently supported. so, if authors were going to use ARIA, it is better to warn them if the way they're using it wouldn't actually be useful to people.
if the landscape is consistent where all browsers and popular assistive technology will respect aria roles, regardless of their casing, then i'd be happy to remove the section from the spec. but if there are still issues, then it will remain to continue to warn people to use lower case for the best support.
Minutes from last weeks discussion: https://www.w3.org/2025/06/26-aria-minutes.html#3e38
@rahimabdi wrote a bunch of case sensitivity tests in this PR:
- https://github.com/web-platform-tests/wpt/pull/53966/files
Results are here:
- https://wpt.fyi/results/wai-aria/role/fallback-roles.html
Given the above results are aligned, and there isn't an apparent case-sensitive host language (that I'm aware of), should this line be stricken from the ARIA spec?
Case-sensitivity of the comparison inherits from the case-sensitivity of the host language.