Repository navigation
Attribute with natural language but no language metadata #1365
Description
spinbutton role
https://raw.githack.com/w3c/aria/2020-09_CR/index.html#spinbutton
Supported States and Properties: [...] aria-valuetext
‘Aria-valuetext’ is an attribute that contains natural-language text, with no way to explicitly set the language. (Writing direction is probably less of a problem, as the content is usually spoken, not displayed.)
The language is probably expected to be inherited from the element. If so, it would be good to mention it. It may be different from the language of the document.
The attribute is not new. It existed already in ARIA 1.1. The only thing new is that in ARIA 1.2 it also applies to elements with role=spinbutton. So this issue probably applies to all occurrences of aria-valuetext and, in fact, to other aria-* attributes that contain text, too.
Activity
jnurthen commentedon Dec 3, 2020
@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.cookiecrook commentedon May 13, 2021
@bert-github wrote:
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.
cookiecrook commentedon May 13, 2021
IMO, the issue resolution could be either of the following:
langinheritance… Probably in the Translatable States and Properties section, which includesaria-valuetext.To avoid redundancy and maintenance, it should defer to the host language, and link to the most common usage in the HTML spec.cookiecrook commentedon Jun 17, 2021
WG Resolution: second option, add explicit mention of lang inheritance.
add lang clarification to translatable attributes section.
add lang clarification to translatable attributes section. (#1690)
bert-github commentedon May 16, 2022
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:
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.)
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.)
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?
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.
add lang clarification to translatable attributes section. (#1690)