what support for a11y strings would be useful in Rosetta?

[pixelzoom]

Support for a11y strings in Rosetta will make it easier for translators to translate and test a11y strings.

In the string file itself:

• The string file will likely need to indicate that a string is for a11y, so that the translator knows that it may not be visible.

• Annotations for an a11y string could indicate what the string is used for, how to see it in context, etc. What is the set of useful annotations? How are they specified in the string file in a way that they can be easily extracted by Rosetta?

In Rosetta:

• Rosetta could perhaps display a special icon next to a11y string, or it make be more usable to group a11y strings together in a specially section.

• Does the "test sim" feature in Rosetta need an option to test with a11y features enabled?

... and undoubtedly other ideas that could make a11y translation more effective.

[jbphet]

Discussed in 5/19/2016 developer meeting, here are some note:

• We probably want to put this in a somewhat separate section so that it isn't intimidating to users, but we also want to not make the accessibility strings seem like "2nd class citizens"
• There will be some design work up front to figure out how to mark up the entries in the string files
• Translators won't have an easy way to test this without a screen reader
• We may want to have links to additional information about testing translated accessibility strings
• Accessibility strings may need a lot of annotation in order to give translators a clear idea of what the are for, since they are harder to test than regular strings
• @emily-phet said that she expects these features to evolve a fair amount initially
• We are making the assumption that any regular string may be used by the screen reader
• Need to add a11y to the testing process, identify supported platforms/readers, versions, etc.
• Might require moving to >1 trusted translator, who coordinate, for situations where 1 translator is not concerned with a11y and the other is
• There will be a11y strings that are in common code, so the UI will need to be designed to handle this

[emily-phet]

Translation of a11y strings not a priority for now. Will seek dedicated funding for this in the future.

[zepumph]

@pixelzoom and I discussed this a bit more today. When it comes time to work on this, it is clear that the vast majority of strings will be a11y feature related. @pixelzoom was mentioning that it feels important to be able to group strings that are used visually with this sim, along with grouping the non visual strings. I tend to agree with him. I think the major problem for translators once we add a11y feature strings will be communicating context to the translator, and the ability to see the strings that are available in that way will be a nice way to do that.

To communicate context for a11y strings, it may be quite a bit harder. It may involve writing comments or other metadata in the english json file that rosetta can parse and communicate to the translator, perhaps like:

   redSpherePattern: {
      hint: 'Heading for the sphere located in the PDOM'
      value: '{{objectLabel}}, Red Sphere'
    },
    grabbedAlertPattern: {
      hint: 'heard when grabbing the ruler'
      value: 'Grabbed. {{verticalRegion}} {{centersApart}} {{supplementalHint}}'
    },

The above snippet brings up more concerns about maintainability and verbosity, again emphasizing that when we don't need to do this (like for the visual strings), then we shouldn't.

[pixelzoom]

... @pixelzoom was mentioning that it feels important to be able to group strings that are used visually with this sim, along with grouping the non visual strings. ...

I want to clarify the suggestion to group strings, in case it's misinterpreted as an attempt to communicate any kind of relative importance of strings. All strings are equally important. But presenting all strings as a single group in Rosetta would be a disservice to translators. The practical consideration is that different groups of strings will "appear" in different places (visual, auditory,...), and will need to be tested in different ways. Grouping will provide translators with context, so they can determine where strings appear, and how they should be tested. Translators will also likely need to be educated about how to test some groups of strings (e.g. descriptions that involve a screen reader), and grouping them will make education easier.

[marlitas]

Meeting 12/4

• We will look back into this issue once we know more about Fluent.js which is being investigated here: Test Fluent.js for complex accessibility strings joist#992