Remove case sensitive requirement

[marcoscaceres]

Closes #280

Safari and Chrome do the right thing.

Firefox has a web compat bug filed https://bugzilla.mozilla.org/show_bug.cgi?id=1407167

---

Preview | Diff

[scottaohara]

until firefox changes this, i'd at the very least want to replace this with a note indicating the problem.

while i agree with you that yes, this is a firefox problem to solve, this isn't just a lack of implementation of one browser to get a CSS property up to snuff. This is someone doesn't type a role value in all lowercase, and now the expected a11y mappings don't work. that's a bit more serious.

[scottaohara]

^ per my previous note. I don't agree with completely removing this without replacing it with a note that will inform authors / conformance checkers of the issue.

we can then remove this once firefox fixes the long standing bug

[marcoscaceres]

until firefox changes this, i'd at the very least want to replace this with a note indicating the problem.

Why? Chrome and Safari do the right thing. Firefox could fix this tomorrow, so I don't see the point of having this in the spec?

while i agree with you that yes, this is a firefox problem to solve, this isn't just a lack of implementation of one browser to get a CSS property up to snuff. This is someone doesn't type a role value in all lowercase, and now the expected a11y mappings don't work. that's a bit more serious.

Not sure I follow (as again, it seems that it's exclusively a Firefox problem)? What might be adequate here is to say that the RECOMMENDED case form is lower case, but that's it.

By making it a MUST, the spec is implying that Safari and Chrome are doing it wrong, which clearly they are not.

[marcoscaceres]

Cc @jcsteh, who can maybe help me fix this in Firefox.

[JAWS-test]

Why? Chrome and Safari do the right thing. Firefox could fix this tomorrow

It should be checked with some more browsers

By making it a MUST, the spec is implying that Safari and Chrome are doing it wrong, which clearly they are not.

I don't think so. It's a MUST for the authors, not for the browsers. I.e. the browsers can do what they want. But since not all browsers behave like Chrome and Safari, there is the MUST for the authors

[marcoscaceres]

Ok, the updated PR now clarifies that attribute values are case insensitive, but we prefer them in lower case.

[marcoscaceres]

It should be checked with some more browsers

I don't think so. It's a MUST for the authors, not for the browsers.

Respectfully, I think this is backwards: Authors can do whatever they want (as they are humans, not software - hence realistically can't be a conformance class). We can only "recommend" people do things - but we can't say they "MUST" do something.

I.e. the browsers can do what they want.

Again, no... otherwise, browsers could randomly map any token to any thing. Why the RFC 2119 keywords apply to user agents.

But since not all browsers behave like Chrome and Safari, there is the MUST for the authors.

Again, that makes no sense: we don't "fix" authors, we fix broken browsers. Deferring the problem on authors makes no sense: there are literally millions and million of authors, but there are only a handful of browsers. And Web Standards are written for browser to conform to (not for authors). We can recommend best practice for authors, but we tell browsers how the MUST behave.

[jcsteh]

Why? Chrome and Safari do the right thing.

...

By making it a MUST, the spec is implying that Safari and Chrome are doing it wrong, which clearly they are not.

I would have thought "the right thing" is what the spec says and it has always required lower case. I don't follow how Firefox is "clearly" doing this wrong. You're retrospectively changing the requirements here. Sure, you can argue that all other HTML attribute values are case insensitive, but ARIA is inconsistent with HTML in other ways too; e.g. boolean attributes in ARIA are actually string attributes, not proper booleans.

That said, I acknowledge the web compat issue here and it obviously makes sense to be consistent across browsers. However, removing this from the spec before the Firefox fix is deployed in the wild means that non-lower case roles become "compliant" even while they don't work in Firefox. Again, you're changing something that has been in the spec for literally years.

[jcsteh]

Note that this causes problems for NVDA as well with both Firefox and Chromium. I haven't tested other AT. Consider:

<div role="MAIN">test</div>

For IA2 and ATK, there is a landmark role and the specific type has to be fetched by looking at the xml-roles a11y object attribute (which just exposes the unaltered HTML role attribute value). In this case, that means "MAIN". Neither the browser nor NVDA does anything concerning case here, so it breaks.

[marcoscaceres]

I would have thought "the right thing" is what the spec says and it has always required lower case. I don't follow how Firefox is "clearly" doing this wrong.

"Wrong", in the sense that it doesn't match the other two engines as far as web compat goes. It's the usual case of, let's align with what the other engines do scenario for the sake of web compatibility.

For IA2 and ATK, there is a landmark role and the specific type has to be fetched by looking at the xml-roles a11y object attribute (which just exposes the unaltered HTML role attribute value). In this case, that means "MAIN". Neither the browser nor NVDA does anything concerning case here, so it breaks.

So I'm wondering then if there are special cases that need to be called out? My concern is still with making sure we get interop in a word where we know content authors are going to send the browser tokens in upper and lower case form, and then neglect to check to actually check if things work across browsers.

[jcsteh]

"Wrong", in the sense that it doesn't match the other two engines as far as web compat goes. It's the usual case of, let's align with what the other engines do scenario for the sake of web compatibility.

Right, which is fair, but that's very different from "it's clearly a Firefox bug, so the spec should be changed immediately without any regard for compliance in the wild".

So I'm wondering then if there are special cases that need to be called out? My concern is still with making sure we get interop in a word where we know content authors are going to send the browser tokens in upper and lower case form,

But right now, that would be a spec violation, so any compliance tools probably check for that. I doubt there are any cases of this in the wild precisely because a) the spec doesn't allow it, b) it was never supported in Firefox and c) it would break NVDA in some cases.

To be clear, I'm not saying we shouldn't address this. I'm saying that I don't think it's as simple as "fix Firefox and change the spec immediately". At the very least, we'd need to figure out how to deal with this ATK/IA2 xml-roles problem. If the browsers should lower case, we need to file and fix bugs in both Firefox and Chromium. if the ATs should deal with that, we need to file and wait for fixes in the ATs.

[jcsteh]

At the very least, we'd need to figure out how to deal with this ATK/IA2 xml-roles problem. If the browsers should lower case, we need to file and fix bugs in both Firefox and Chromium.

It's probably easiest to deal with this in the browsers, so that would be my suggestion.

[JAWS-test]

@jcsteh Neither JAWS nor NVDA have problems with uppercase letters in ARIA roles and attributes. That's why I don't understand why something needs to be fixed in Chromium. In my opinion, the problem is limited to Firefox only

[jcsteh]

As in the example I provided, if you do role="MAIN", NVDA + Chromium will report just "landmark", not "main landmark".

[JAWS-test]

@jcsteh You are right. I had tested other ARIA roles and attributes and there were no problems with those. But role=MAIN is not recognized at all in Chrome e.g. by JAWS (and by NVDA only as region).

[stevefaulkner]

Given that removing this rule at this time would potentially impact users in a negative way I think it should stay in the spec until Firefox and other browsers implement the case insensitivity requirements fully.

[marcoscaceres]

I'm ok for this PR to sit for a bit. I'm working on the patch for Firefox. Meanwhile... a little progress 🎉:

[xfq]

It should mention if the attributes use Unicode case-insensitive or ASCII case-insensitive matching. See https://www.w3.org/TR/charmod-norm/#handlingCaseFolding for more info.

[scottaohara]

I created a test case today to quickly review how some uppercase and mixed case roles would be interpreted by screen readers (NVDA, Narrator, JAWS, VoiceOver, TalkBack) / browser combos. With Firefox, Edge, Chrome and Safari (windows, macOS, iOS, Android). Additionally, I was able to get some quick Dragon testing, as well as Voice Command/Control with macOS and PC (the latter performed fine, Dragon not so much...). I added a brief writeup of results to the codepen, but it does appear that there are likely still a number of quirks for different AT to work out which aren't surfaced if authors write roles in lower case.

This being merely a few simple tests that have resulted in issues with content being exposed/announced, I'm not in a rush to merge a change that would have validators drop a warning/error which is still helpful to dissuade authors from writing markup which can cause issues with people's AT.

[LJWatson]

AFAIK Dragon still scrapes the DOM rather than use the accessibility API. It also has limited support for ARIA, but I'd be wary of making normative changes to the specification that might break things for users....

Could we make it an informative statement to the effect that lowercase is expected, and use that to open issues against Dragon perhaps?

[scottaohara]

I think we can reach a mid point on this one. I'll try to get a draft PR together in the next few days to keep the current section, but to reduce the 'must' and provide some context as to why this is an issue that validators need to continue to report on, since browser compt is only one piece of the full puzzle here.

[marcoscaceres]

Thanks @scottaohara! Looking forward to seeing what you come up with!