axe returns fallback text of video elements as the accessible name

[scurker]

Product: axe-core
Expectation: The accessible name calculation should not return the fallback text for <video> elements.
Actual: Accessible name calculation includes fallback text
Motivation: Screen readers to not appear to have this as the accessible name, nor do the accessibility trees of different browsers that I checked.

axe-core version: 4.2.2
axe-webdriver, extension or other integration version: N/A

Browser and Assistive Technology versions
(see included test case)

I've setup a codepen with different scenarios of alternate text for <video> elements.

await import('https://unpkg.com/axe-core')
axe.utils.getFlattenedTree()
$$('video').map(axe.commons.text.accessibleText)

The above returns the following:

[
  "", 
  "this is a video", 
  "this is a label for the video", 
  "", 
  "Your browser is not supported"
]

The last video in the above test case is one with a fallback:

<video>
  <source src="..." />
  Your browser is not supported
</video>

I don't think the accessible name calculation should be included except in instances where the video element is not supported, but I have not tested that specific use case. It's possible that this happens for audio elements as well.

According to the html spec the content of the elements is intended not to address accessibility concerns.

[WilcoFiers]

I'm not surprised axe-core returns text content as accessible text. It may not be the accessible name of the element, but it is text that is accessible. This is how accessibleText is intended to work.

What is odd is that axe-core seems to return hidden text as part of accessible text. It is definitely not supposed to do that. It wouldn't return the text of a script element for instance. No idea what that'd be different for video. Worth a look.

[dylanb]

I'm not surprised axe-core returns text content as accessible text. It may not be the accessible name of the element, but it is text that is accessible. This is how accessibleText is intended to work.

@WilcoFiers that is not really the case, accessibleText implements the accName algorithm - which is the calculation for the accessible name of something. Name from content is one portion of that algorithm. Seems like we have a bug related to which nodes support name from content.

[WilcoFiers]

Axe-core's accessibleText from accName in two places. It is flagged and documented:
https://github.com/dequelabs/axe-core/blob/develop/lib/commons/aria/named-from-contents.js#L28
https://github.com/dequelabs/axe-core/blob/develop/lib/commons/text/subtree-text.js#L33

Axe-core relies on these to handle a bunch of scenarios. If you don't want this, you can use the strict flag. We can discuss whether or not the default should have been the other way around. But axe-core itself never uses strict, except in the accessibleName tests.

Either way, hidden text should get ignored by subtree-text. That definitely is a bug. I'll leave it up to the extension team to work out if you want strict or not.

[dylanb]

That strict flag is buried very deeply. It should be documented here

axe-core/lib/commons/text/accessible-text-virtual.js

Line 15 in ee17b67

* @param {Object} context