[BUG]: AccessibilityChecker raises violations for tabbable elements with the "application" role

Mark-Falconbridge-i2 commented 1 year ago

Project

a11y checker engine, a11y checker

Browser

Chrome

Operating system

Windows

Description

I have a web app which contains a Leaflet Map within it. That map has a tabIndex of 0 applied to it because the user can make the map scroll around using the arrow keys. I have applied the role of application to that element as that seems to be the best fit.

When I run the accessibility checker it reports a violation - "The tabbable elements's role 'application' is not a widget role".

According to the w3 spec, the application role seems to be the best fit for the map - https://www.w3.org/TR/wai-aria-1.2/#application. If the application role isn't the most appropriate, can you suggest an alternative?

Here is an image of the violation. MapWithApplicationRole

Steps to reproduce

Go to the example Leaflet map page here - https://leafletjs.com/examples/quick-start/example.html.
Edit the DOM using the Chrome dev tools to add role="application" to the element with the id "map".
Run the accessibility checker.
Notice the violation (amongst others) "The tabbable element's role 'application' is not a valid widget role".

philljenkins commented 1 year ago

Here is a screenshot before adding the role=" application"

philljenkins commented 1 year ago

We're going to discuss this case. The ARIA 1.2 spec is somewhat unclear.

@Mark-Falconbridge-i2 do you have any other examples where you use role="application"

Mark-Falconbridge-i2 commented 1 year ago

Hi Phil, No, I don't have any other examples.

mbgower commented 1 year ago

So before digging into this...

If you are going to put the focus around the whole map in order to allow users to pan and reposition, I suggest you explore having icon appear on focus that indicators that, something like this or similar

ARIA doesn't seem to have a "pan" role, which is effectively what this interaction is. There are a few hits on panning but they are all about panning within a magnified viewport. Too bad this concept isn't extended a bit more.

The interaction doesn't fit the scrollbar role since there are no scrollbars visible (and potentially no top or bottom or end point horizontally) -- but scrolling inside the window is VERY similar to what's going on here.

I think putting a role of application on it seems fairly simple and effective. One could add in an aria-roledescription to help convey this "reposition map view" functionality, and possibly even aria-keyshortcuts to convey what they are.

But none of that solves the checker failure on using "application". You can take off the tabindex, at which point the error goes away -- but then NO keyboard user can operate the panning, so that's hardly a good solution.

I wonder if this error is appearing as a result of a tabindex rule?

mbgower commented 1 year ago

I tested with JAWS, and role="application" allows JAWS to pass through keys. I see no reason a role of application can't be used here. It seems like a good use.

JAWS also read out the aria-roledecription value, but not the keyshortcuts info. So I added that into the description like this: aria-roledescription="Map view. Use arrow keys to reposition"

A better approach would be to give the div a specific or generic label (e.g., aria-label="map"), and then just use the role description "Use arrow keys to reposition view"