fix: define role="application" as an interactive ARIA role

[oscarhermoso]

Interactive elements that are not described by existing ARIA widget roles should have role="application", and should resolve warning no-interactive-element-to-noninteractive-role

For example, the Cropper component from Svelte Easy Crop does match any of the other ARIA widget role descriptions.

See spec: https://www.w3.org/TR/wai-aria-1.1/#application

Fixes #8943

[dummdidumm]

@geoffrich can you have a look? I've read the spec and it sounds like role="application" should be considered interactive. I'm wondering though why eslint-a11y-jsx also expects this to fail? Should the spec instead be read as "the contents can be interactive but the element on which the role is placed is not"?

[geoffrich]

Hm, reading the spec I'm not sure that application itself is interactive?

containing one or more focusable elements requiring user input, such as keyboard or gesture events, that do not follow a standard interaction pattern supported by a widget role.

It contains interactive elements but I'm not sure it's able to be interacted with directly. But I have to admit this is a role I haven't used before

One worry I have with merging this PR is that it would encourage people to start throwing the application role on everything to get around the lint warnings, and using this role should be used rarely and carefully.

But I think the fact that these warnings are telling people to throw ARIA roles on everything without fully understanding the implications points at a larger issue that may require some thought on how to provide better guidance and reduce false positives (see also #8964, #8273, #8001). I'm unfortunately pretty busy prepping for a conference talk at the end of the month, but that's something I want to take a closer look at when I have more time.

[oscarhermoso]

Thanks guys, appreciate the caution on the review, and no rush - it's just a build warning 🙂

When I read the spec, "An application is listed as a structure containing one more more focusable elements." - My interpretation was that a single, focusable element satisfied the requirements, but I could be misinterpreting.

...I also wouldn't be the only misinterpreting: dequelabs/axe-core#890

@geoffrich - The blogpost that you linked was written in 2012 with reference to concerns with the ARIA 1.0 spec. Previously the application role was derived from the landmark abstract role, but was changed to be derived from the structure abstract role in 2015 with ARIA 1.1.

The structure abstract role is "not usually interactive", but here are some interactive(ish) subclasses of structure:

• separator is a subclass of structure that may be interactive... but it changes (?) to a subclass of widget when it is focusable
• tab is interactive and extends abstract role sectionhead, which extends structure... but tab also extends widget so we can assume it's interactivity is derived from there
• menu extends select and is described as a "type of widget", and is expected to be interactive by eslint-plugin-jsx-a11y... but isn't actually a subclass of widget in the spec? ...And surely it would make more sense for the menuitem elements within would be interactive, whilst the menu itself is not?
• An of course application is listed as a structure containing one more more focusable elements.

@dummdidumm - I'm not sure eslint-plugin-jsx-a11y should be the ultimate source of truth, because, their tests expect separator to be non-interactive, despite being explicitly allowed in the spec, and menu is expected to be interactive, even though it doesn't actually derive from the widget abstract role (but the spec is very unclear).

If we are worried about people "throwing the application role on everything to get around the lint warnings", then enforcing that the element is accessibly described (as per the spec) might be enough disincentive to use role="application" as a work-around.

[oscarhermoso]

I raised the query in w3c/aria#1985