Consider this:

data:text/html,<p id="container" aria-owns="text" lang="fr"></p><span id="text">1</span>

Firefox exposes no language text attribute for the text. For most text attributes, I think this makes sense; I don't think we'd want to inherit font information from an ARIA owner, for example, as that would override the actual font info of the owned text. There's perhaps an argument for looking at the a11y tree for language because language is more semantic than presentational. I think this is a grey area; I don't know of any spec that covers this case.

Interestingly, Chromium does expose the language on the text in this case. I'm guessing this was a happy accident of their implementation, rather than an intentional effort to support this case. Chromium also does this for superscript, for example, which seems potentially problematic to me... although maybe this is appropriate for superscript too? Chromium does not do this for bold.

The practical use case is pdf.js, as described in this issue. Because the text and structure layers are separate in PDF, pdf.js supports tagged PDF by aria-owning the text into the structure subtree. Language is semantic, so it's part of the structure tree.

Eitan, what do you think about this?

Your example of font info is a good analogy. My initial thought is that lang is more presentational than semantic - in CSS it can be used for selecting the best font for the language, and in non-screen-reader speech synth apps it can be used to determine voice. So the author intentions can get complicated when adding aria-owns into the mix. On the other hand, that same author is the one who mixed aria-owns and lang in the first place, so they aren't free of blame. MDN does describe the main use for lang being screen readers, so maybe aria-owns is what matters.

I guess I don't have a strong opinion about this. If it fixes a pdf.js issue, and if Blink coincidentally does the same thing, I guess it is fine.