@bert-github This is not the only attribute like this. A number of attributes support natural language (aria-label for example). This would indeed be good to document but as this is not a new issue we presume it is ok to address in the next version of the spec.

Indeed we believe there may be more language issues which need to be addressed mostly in w3c/accname#56 where there is the potential for mismatched languages between a label and its corresponding form element and we need a rule to determine which language should take precedence.
Note that HTML itself has the same issue where <label lang="en" for="a">Label</label><input id="a" lang="fr"> does not define wether the resulting node in the accessibility API should be in English or French so we may need to drive a resolution there before we can address this part in ARIA.

@bert-github wrote:

Writing direction is probably less of a problem, as the content is usually spoken, not displayed.

I don't think my comment affects the issue outcome, but FYI this is not a valid assumption. Accessibility APIs are not limited to screen readers on any platform that I am aware of. Even if they were, most screen readers render braille and on-screen text in addition to speech.

For example, this string can be visibly exposed to sighted low vision users using the "Hover Text" AT feature on macOS, and also probably to Zoom Text users on Windows.

IMO, the issue resolution could be either of the following:

• Do nothing and close the issue. Language inheritance is already covered by the implementing host language, most often HTML.
• Add an explicit mention of lang inheritance… Probably in the Translatable States and Properties section, which includes aria-valuetext. To avoid redundancy and maintenance, it should defer to the host language, and link to the most common usage in the HTML spec.

WG Resolution: second option, add explicit mention of lang inheritance.

The change to the draft specification (in section 6.4 ‘Translatable Attributes’) mostly defines the language of each attribute that contains text. But a few things remain unclear:

1. The ‘lang’ attribute is not the only thing in HTML that defines the language of an element. The text should probably just say that the language of the attribute is the same as the language of the element, without talking about the ‘lang’ attribute, but referencing the HTML5 specification (in particular the definition of language in section 3.2.6.2.)

2. The new text implies that the language is just for making translations, but information about the language is also needed for proper pronunciation and layout. (I.e., for ‘rendering’, in the terms of the ARIA specification.)

3. What do you do if the attribute happens to be in a different language than the contents of the element? Or if two attributes have different languages?

   In the case of an aria-label attribute, you could replace aria-label by aria-labelledby and point to a separate element. (Maybe that should be a note or an example?)

   But what do you do for aria-valuetext?

4. For visual rendering, the direction of the text may also be needed. E.g., if the document is in Arabic and the attribute contains a phone number with dashes or spaces between the digits, it is important that the whole number is displayed
   left to right, otherwise the first group of digits will be displayed to the right of the second group. (Here is an explanation.)

Possibly the direction could be taken from the element's ‘dir’ attribute, but, like for the language, that leaves a problem when the attribute's direction is different from the direction of the element's content. E.g., you wouldn't want to set the ‘dir’ attribute on a slider, because it reverses the slider.