Add check to fail fallback roles

[jwheare]

Reposting from GoogleChrome/lighthouse#4474

Given the following markup, aXe reports a few errors, I believe due to not being able to validate both roles in <span role="tab button"> at once

Codepen: https://codepen.io/anon/pen/mXRPJJ

From the HTML spec https://www.w3.org/TR/html52/dom.html#aria-role-attribute

The attribute, if specified, must have a value that is a set of space-separated tokens; each token must be a non-abstract role defined in the WAI-ARIA specification [wai-aria-1.1].

The Chrome accessibility tree also computes the role correctly as tab

<ul role="tablist">
    <li>
        <h2>
            <span role="tab button" tabindex="0" aria-selected="false">Header</span>
        </h2>
        <ul>
            <li role="presentation">
                <span role="tab button" tabindex="0" aria-selected="false">Subitem</span>
            </li>
        </ul>
    </li>
</ul>

Errors from the chrome extension:

Elements must only use allowed ARIA attributes
ARIA attribute is not allowed: aria-selected="false"
<span role="tab button" tabindex="0" aria-selected="false">Header</span>

Certain ARIA roles must contain particular children
Required ARIA child role not present: tab
<ul role="tablist">

ARIA roles used must conform to valid values
Role must be one of the valid ARIA roles
<span role="tab button" tabindex="0" aria-selected="false">Header</span>

[WilcoFiers]

aXe-core currently doesn't support multiple roles in any way. The first proposed adoption of multiple roles in in a PR I opened 2 days ago (#722). I do think we need to start supporting this, but we'd need to come up with a strategy for doing so. It isn't quite as easy as picking the first one we recognise and going with that. It may also require some structural changes to how aXe-core works today.

Some considerations (for future reference):

• Should we allow use of unknown roles, if there's a known fallback? Or do we only allow known ones? Should aXe distinguish between known unsupported roles and unknown roles?
• For multiple roles, do we allow use of all attributes available for either role? Do we require them all? Do we require just those for the first role aXe knows about?
• What do we do with AT that don't support fallback roles? Can we make this configurable so that with fallbackRoles enabled the fallbacks are checked, and with it disabled the fallbacks are ignored?

I think the first step should be to test multiple roles in assistive technologies. Specifically, we need to know if AT don't just ignore the role if they don't recognise the first role, but actually look at subsequent roles in the role attribute. I'm flagging this as help wanted, because we need to get the test work done for at least all of the AT in our accessibility support document.

[jwheare]

I think the next line of the spec answers the question of which role to accept:

The WAI-ARIA role that an HTML element has assigned to it is the first non-abstract role found in the list of values generated when the role attribute is split on spaces.

I think unknown roles should be ignored by aXe, and the first known role taken, with any further roles ignored.

I found some notes on how AT react to multiple roles from 2015 here:
https://developer.paciellogroup.com/blog/2015/10/notes-on-use-of-multiple-aria-role-attribute-values/

Not sure if @stevefaulkner or others have done any further research into this.

[dylanb]

Thanks for that link

@jwheare Please read the information pointed-to by @WilcoFiers https://github.com/dequelabs/axe-core/blob/develop/doc/accessibility-supported.md

This outlines what axe-core policy is with respect to the WCAG 2 concept of "accessibility supported", so we need definitive tests of all the platforms listed on current versions.

Minimally missing from that Paciello page are:

JAWS
Android
Dragon

[rdeltour]

I just tested Steve’s code pen on Android 6.0.1 with Talkback and all test cases are reported correctly.

[rdeltour]

Unfortunately it doesn’t seem to be supported in JAWS+IE, I filed an issue at FreedomScientific/standards-support#51

[WilcoFiers]

That's pretty unfortunate. So we could add support for it, but we can't enable it by default. Probably not for some time, given how slow most JAWS users are to update.

[jwheare]

At the least, you could parse the roles, but offer a more precise warning about the risks of incomplete AT support.

[WilcoFiers]

Agreed. That would be quite helpful.

[dylanb]

@jwheare @WilcoFiers unless we add complete support for customizing the list of ATs, we want to stick with the primary value proposition of axe-core:

If we say it doesn't work, we know what we are talking about, that means it does not work somewhere important. If we say it does work, you can trust us, it works everywhere.

[rdeltour]

So we could add support for it, but we can't enable it by default. Probably not for some time, given how slow most JAWS users are to update.

I think it would be indeed useful to add some sort of support: there could be cases where a role is supported in IE+JAWS but not somewhere else (like macOS/iOS+VO), which would effectively make the multirole approach a supported fallback mechanism.

[jwheare]

@dylanb makes sense. I'm only suggesting that it would be more useful for developers if it says specifically what doesn't work (multiple roles) rather than attributing the errors incorrectly as the original issue shows. It's not necessary to list ATs to do that. Hope that's clear :)

[jnurthen]

I think there might be confusion where the support issues for this might be.
Anything using the Accessibility APIs correctly gets support for fallback roles for free - except for IE which doesn't support them and simply chooses the first role listed.

Screen readers have nothing to do here as this is a browser requirement.

Dragon could be a problem here - but there are cases (such as role="meter progressbar" where the role is applied to a non-interactive component so Dragon support is irrelevant).

With every new role added to ARIA the best way for a developer to use them is with a fallback role to something similar which isn't supported as well. Checkers such as aXe throwing errors in this case makes it much harder to uptake new features and still support a wider array of browsers/AT.

[straker]

This was added as part of axe-core v3.5.0. The fallbackrole check (part of the aria-roles rule) will now fail if an element has a fallback role. You can disable this check using axe.configure.

axe.configure({
  checks: [
    {
      id: 'fallbackrole'
      enabled: false
    }
  ]
});