Re: working on the definitions for support personliazion

> Token/name pairs could be used, but I’m confident we won’t be able to include equivalent names for various languages within the duration of the WCAG 2.1 development process.

I see there are 21 translations of WCAG 2.0 (ARIA 1.0 has 2), did they all need to be done in the development time of 2.0? I’m not trying to be flippant, I said previously I don’t know what the process / policy for translated versions are, and that’s important for this SC.

I’m also wondering how it is affected by “accessibility supported”. For example, presumably it took some time for the screenreaders to make ARIA available across languages? If a language doesn’t have a screenreader (or in this case a browser extension) what does that mean for authors in that country/language?

I see three principle options:


  1.  Use name/token pairs in the definition, and rely on the translation of WCAG 2.1 to cover different languages.
Even un-translated, people would still be able to see the token and work out what the translation should be (at least as much as they do for ARIA).

  2.  Convert all the conventional names into single-word, as close as possible equivalents, or drop them. E.g. drop “first name” and only use “name”, convert “my profile” to “profile”. Again, we’d have to rely on translating the core spec to translate the terms.

  3.  Modularise the coga-personalisation spec, make these attributes part-1 and get that through ASAP, marking this SC as at-risk due to the dependency.

Do you see another option? Which do you think is most likely to success for 2.1?

Cheers,

-Alastair