You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If [a11y] strings are ever made translatable, or could change with a query parameter.
In JohnTravoltageA11yStrings, replace arrowKeysMoveFootString's value to:
to reproduce.
We should have a better way to mark up bold/non-bold text, or we could use improved validation. @mattpen, in your investigation with the OWASP validator, is that something we could use in rosetta to prevent this type of attack vector? (I'd really like to allow the current usage, as it's quite flexible for the translator).
Also @ariel-phet, I don't recall the timeline or chance of having accessible strings be translated (this and some other issues like handling long strings would only apply if we plan on doing this in the future at some time).
Is it valuable to create review items anticipating translation, or should we plan to leave related improvements until that point (like XSS/layout).
The OWASP validator I looked at was a Java library. I'll investigate if a JavaScript library exists.
Alternatively, is this something that could be prevented with CSP, or do these types of tags need to be allowed elsewhere?
@jonathonolson - I misunderstood how these strings were being used, I don't think CSP will be viable. Anything that would block this text would also block sim code from running. I thought you were referring to alt attributes for images.
I couldn't find a widely trusted validation library for Node after a quick search. According to OWASP, Microsoft provides one for .NET framework and OWASP provides one for Java projects. We could potentially use the OWASP project but would need to build a new service to use it rather than integrating it directly in rosetta.
@jonathanolson yes it is valuable to create review items anticipating translation.
Although there is not yet a specific timeline, updating the translation utility to allow translation of a11y strings is on the horizon.
Was this boilerplate: ... added to all *A11Strings to address this issue?
Yes that's right.
I'm going to close this issue because we are very close to getting rid of A11yStrings and moving the strings to the en json files, see #193 for base issue and phetsims/chipper#795 for next steps.
From phetsims/john-travoltage#175. Copying discussion to rosetta because this isssue is not specific to john-travoltage.
@jonathanolson said:
@mattpen said:
@jonathanolson said:
@mattpen said:
@ariel-phet said:
@mattpen said:
Assigning to @jonathanolson since phetsims/john-travoltage#175 was previously assigned to him.
The text was updated successfully, but these errors were encountered: