search

w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
631 stars 119 forks source link

Expand translatable properties section #1316

Closed benoitjchevalier closed 3 months ago

benoitjchevalier commented 3 years ago

Looks like the translatable section is missing a few properties. It defines:

I think it's missing:

The braille ones are a bit more complex but my understanding is that they should also be translated since they won't be translated by assistive technologies:

I can do a PR if those additions make sense.

jnurthen commented 3 years ago

Yep - you are right. We should add the first 3. I'd like advice on the braille ones from @cookiecrook @sinabahram and @pkra My first thought is that yes they should but we should add some text that states that an automated translation of these should not be attempted - but I would defer to any of the above on this.

cookiecrook commented 3 years ago

Also, @joanmarie @michael-n-cooper should there be a new translatableString (strawman name) value type in addition to the existing string value type?

cookiecrook commented 3 years ago

If so, then the translatable section could be generated from ReSpec.

Regarding the braille attr, I think non-braille values for aria-braillelabel are probably okay to translate. I think it's unlikely that a translation of braille cell-conserving abbreviations (e.g. "btn" for "button" or "g" for "group") would be useful.

cookiecrook commented 3 years ago

As for the more rarely used Braille Pattern values for those attributes, I think it's unlikely any existing translation engine would try to translate them. For example, even if you knew the language (English) aria-braillelabel="⠏" could mean "p" in Grade 1 Uncontracted, or "people" in Grade 2 Contracted. It'd be impossible to back translate without knowing the table, so I don't think there is any risk of it in the near term.

So the choices regarding the Unicode Braille Pattern range are:

  1. Add a recommendation or note that mentions UAs should not attempt to translate substrings that include the Unicode Braille Pattern range.
  2. Don't mention it at all. We can add a note later if it becomes a problem.

I lean toward option 2. There's very little need to mention it in the spec because it's unlikely to be a problem. Explaining the problem space just adds more complexity to the spec without much gain.