search

w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
653 stars 125 forks source link

Changes to what roles allow a name from author could break the web #1487

Closed minorninth closed 1 year ago

minorninth commented 3 years ago

I'm concerned about the new changes that disallow, e.g. aria-label on HTML elements without a supported role.

As advice to authors, it sounds great. It's probably not ever correct to put aria-label on a <div> with no tabindex or role.

But I'm concerned about browsers implementing this and enforcing it. Browsers can't just make such a large breaking change like this without carefully understanding the ramifications. We might have to add use counters to see how prevalent this error is, and put a message in the JS Console for 6 months to give developers warning.

And, we don't even know for sure if there aren't more obscure but valid use-cases that would be broken by this. While screen readers largely ignore such names, are we sure that all AT does? What about automated testing tools?

I think we have two possible courses of action:

  1. Flag this as a major change and try to get all browsers onboard with making it slowly and carefully so as not to break anything that users or developers are relying on

  2. Or, maybe we need to introduce something new like an ARIA strict mode, that would let developers opt-in to having this enforced.

jnurthen commented 3 years ago

ARIA 1.2 prohibits authors but makes no statements about what browsers should do ARIA 1.3 currently adds a statement that user agents MUST NOT expose these attributes

IMO we're going to need to revert this ARIA 1.3 change for this exact reason. We should forbid authors so validators can enforce - but still allow user agents to correct for author mistakes.

I've mentioned strict accessibility modes before and been told this is a non-starter due to the need to then maintain 2 diverging code paths in browsers which would make each of them more fragile.

asurkov commented 3 years ago

Correctness is for the sake of correctness is great, but what are practical benefits of the change? Otherwise, considering this is a not backward compatible change and known for a lot of breakage, I'd go with "advice to the authors" approach. I would say that strict rules are better to be enforced by validation tools rather than having them hard-coded into browsers: all in-browser validation goes at runtime performance cost, so I like the idea to keep ARIA implementations as simple as possible.

On Mon, May 17, 2021 at 2:18 PM Dominic Mazzoni @.***> wrote:

I'm concerned about the new changes that disallow, e.g. aria-label on HTML elements without a supported role.

As advice to authors, it sounds great. It's probably not ever correct to put aria-label on a with no tabindex or role.

But I'm concerned about browsers implementing this and enforcing it. Browsers can't just make such a large breaking change like this without carefully understanding the ramifications. We might have to add use counters to see how prevalent this error is, and put a message in the JS Console for 6 months to give developers warning.

And, we don't even know for sure if there aren't more obscure but valid use-cases that would be broken by this. While screen readers largely ignore such names, are we sure that all AT does? What about automated testing tools?

I think we have two possible courses of action:

1.

Flag this as a major change and try to get all browsers onboard with making it slowly and carefully so as not to break anything that users or developers are relying on 2.

Or, maybe we need to introduce something new like an ARIA strict mode, that would let developers opt-in to having this enforced.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/aria/issues/1487, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALWPKOUF6MF3GPNOXMM6ULTOFMYPANCNFSM45A6ZGLA .

jnurthen commented 3 years ago

see https://github.com/w3c/aria/issues/1476

joanmarie commented 3 years ago

@minorninth What about a third course of action, namely a message in the JS Console permanently? In other words, could we turn "user agents MUST NOT expose" into "user agents MUST (or SHOULD) log an error (or warning) message"?

I cannot help but wonder how many authors out there are actually using validators. Probably not enough. My guess, though, is most of them are looking at the JS Console for warnings. If the WG goal is to stop this authoring, ensuring authors can't miss their error seems like the way to go.

joanmarie commented 3 years ago

Playing around with logging a console warning in Chromium just to see how feasible it might be. I think it's pretty feasible. What I've done is:

  1. Leave the existing Blink name calculation code as-is
  2. At the end of that calculation: a. if we've calculated a non-empty result, AND b. the source of that name is one we explicitly want to flag (e.g. aria-label or aria-labelledby), THEN c. print a warning to the console

Some observations on the above approach:

  1. The work will only be done IF we're calculating a name, which means the browser's accessibility mode has to be on, either because it's explicitly been enabled (e.g. --force-renderer-accessibility in Chromium) OR because something (e.g. a screen reader) is querying the user agent via accessibility API.

    In other words, we're not going to be spewing errors at the average web developer who isn't testing accessibility; but we are going to be alerting authors who, say, verify accessibility not by validator but by launching a screen reader and seeing what gets spoken.

  2. The heavy lifting when it comes to AccName is calculating the name itself. Once we've done that work, it's pretty simple to check the role and where the name came from (at least in the case of Blink). So I don't think this is going to have much of a performance cost for end users.

Thoughts?

minorninth commented 3 years ago

Just changing the spec from "must not" to "should not" doesn't seem reasonable to me because it makes the browsers seem non-compliant, when browsers are actually trying to maintain the status quo.

More clearly marking it as a deprecation or a shift would make me happier.

The more I'm thinking about this, the more I'm convinced that this will break a lot of people if we make this change - quite likely things like automated tests.

joanmarie commented 3 years ago

@minorninth Thanks for the input!

Having tried to implement name-prohibited in Chromium and seeing everything that was impacted there, I'm afraid I have to agree with your assessment that this change will break a lot, especially for automated tests.

In terms of the spec itself, we currently have a "User Agents MUST NOT expose" in 1.3. And we need to decide what to do with it. Do you think we should:

  1. Just delete it entirely and leave it up to user agents to do what they see fit, including leave things as-is?
  2. Modify it so that user agents SHOULD do something TBD (e.g. log a warning to console), but remove the statement regarding exposure to ATs?
  3. Something else?
WilcoFiers commented 3 years ago

Might be sufficient to let validators handle this one.

jnurthen commented 2 years ago

We discussed this at TPAC - https://www.w3.org/2022/09/15-aria-minutes.html#t07

scottaohara commented 2 years ago

For 1.3 this needs to be an authors must not only, matching aria 1.2.

We need to remove the UAs MUST NOT, and instead add an editor's note about the current reality of how naming prohibited elements is problematic, and that further discussion and changes may occur regarding prohibited naming.

jnurthen commented 1 year ago

This was fixed by https://github.com/w3c/aria/pull/1778