Expand translatable properties section

[benoitjchevalier]

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

• aria-label
• aria-placeholder
• aria-roledescription
• aria-valuetext

I think it's missing:

• aria-colindextext
• aria-description
• aria-rowindextext

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:

• aria-braillelabel
• aria-brailleroledescription

I can do a PR if those additions make sense.

[jnurthen]

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]

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

[cookiecrook]

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]

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.