search

dequelabs / axe-core

Accessibility engine for automated Web UI testing
https://www.deque.com/axe/
Mozilla Public License 2.0
5.75k stars 746 forks source link

Images with implicit roles behave differently across browsers #4436

Open gaiety-deque opened 2 months ago

gaiety-deque commented 2 months ago

Product

axe-core

Product Version

4.9.0

Latest Version

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.

// 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(`
      <img id="target" src="#" aria-level="2" alt="" />
      <div role="main">Content</div>
    `);

    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.

<img alt="" aria-level="2" />

Additional context

Presentational Roles Conflict Resolution 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 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.

WilcoFiers commented 2 months ago

Interesting. Even if it's in the accessibility tree, assistive technologies will probably ignore it. I think this needs further testing before we do anything with it. The other thing that could be going on here is that Chrome DevTools is misleading us. Chrome DevTools sometimes shows things in the accessibility pane that isn't in the actual accessibility tree. I think it does that to try to be helpful, or maybe its just that the CDP doesn't provide all the information and they need to fake it a bit. Not sure.

In either case, its worth testing this with actual assistive tech.