dequelabs / dequelabs/axe-core
Images with implicit roles behave differently across browsers
- Dominant language
- JavaScript
- Stars
- 7.5k
- Forks
- 933
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 17
Description
### Product
axe-core
### Product Version
4.9.0
### Latest Version
- [X] I have tested the issue with the latest version of the product
### Issue Description
#### Expectation
A decision should be made about how axe-core handles images with empty alt attributes (not `unset` ones) with regards to implicit VS implied roles as the spec specifies when _using non-Global aria attributes_ like `aria-level`.
```js
// test/checks/navigation/region.js
it('should return false when img content outside of the region has a non-global aria attribute with an empty alt attribute string', function () {
const checkArgs = checkSetup(`
`);
assert.isFalse(checkEvaluate.apply(checkContext, checkArgs));
});
```
#### Actual
`axe.commons.standards.getGlobalAriaAttrs` is leveraged for the region rule and possibly others, when the spec may mean we need to be more broad in cases that use `getRole` for images with empty alt attributes.
#### How to Reproduce
The following code behaves inconsistently according to the accessibility tree. In Firefox it is removed from the tree, in Chrome it is in the tree with an empty alt.
```html
```
#### Additional context
[Presentational Roles Conflict Resolution](https://www.w3.org/TR/wai-aria-1.2/#conflict_resolution_presentation_none) is very specific about the behavior between elements with inherited VS implicit roles. [An image with an empty alt attribute has an _implicit_ `img` role](https://www.w3.org/TR/html-aria/#el-img) I'd suspect the following would be the case:
> However, if an element has only **non-global**, role-specific WAI-ARIA states or properties, the element MUST NOT be exposed unless the presentational role is inherited and an explicit non-presentational role is applied.
Contributor guide
Assessment
This issue has not been assessed yet.