i18n: convert accessibility audits #6229
Conversation
There was a problem hiding this comment.
More i18n 🎉 Love it!
A few nits on wording.
Also I didn't leave a specific comment for the comments explaining description's but is it okay that they are all the same? The comment is a good one, but I don't know if it works in all cases? Does it need more context?
| title: '`[aria-*]` attributes match their roles', | ||
| /** Title of an accesibility audit that evaluates if the aria HTML attributes are misaligned with the aria-role HTML attribute specificed on the element, such mismatches are invalid. This imperative title is shown to users when there is a failure that needs to be addressed. */ | ||
| failureTitle: '`[aria-*]` attributes do not match their roles', | ||
| /** Description of a Lighthouse audit that tells the user *why* they should try to pass. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */ |
There was a problem hiding this comment.
Need more details calling out what the ARIA attributes are? Might be confusing.
Note: This happens a lot, and I wonder if just saying ARIA, or aria-elements is sufficient in all places with no context?
There was a problem hiding this comment.
Maybe we can add it to our separate definitions glossary? @paulirish @brendankenny that was a thing right I'm not making that up :)
| @@ -31,6 +31,38 @@ const UIStrings = { | |||
| diagnosticsGroupTitle: 'Diagnostics', | |||
| /** Description of the diagnostics section of the Performance category. Within this section are audits with non-imperative titles that provide more detail on the page's page load performance characteristics. Whereas the 'Opportunities' suggest an action along with expected time savings, diagnostics do not. Within this section, the user may read the details and deduce additional actions they could take. */ | |||
| diagnosticsGroupDescription: 'More information about the performance of your application.', | |||
| /* Title of the color contrast section within the Accessibility category. Within this section are audits with descriptive titles that highlight the color and vision aspects of the page's accessibility that are passing or failing. */ | |||
| a11yColorContrastGroupTitle: 'Color Contrast Is Satisfactory', | |||
There was a problem hiding this comment.
'Color Contrast Is is Satisfactory'?
This happens a few times, do we mean to capitalize these words every time, or do we need to look at them to make sure they are following a capitalization guideline?
There was a problem hiding this comment.
I've got no dog in this fight just moved the string up :)
I think the thinking here was that we have very few such small non-title-cased words that it just stood out too much, but 🤷♂️
|
Thanks for the thorough review @exterkamp!! |
|
Anyone else care about these? |
|
@paulirish @brendankenny Can we resolve the conflicts then merge these in? If we roll these changes + the new i18n error changes into 1 translation request it'd be less rolling. |
|
conflicts fixed! 🎉 is this happening!? :D |
| /* Title of the meta tag section within the Accessibility category. Within this section are audits with descriptive titles that highlight if meta tags on the page have been used properly and if any important ones are missing. */ | ||
| a11yMetaGroupTitle: 'Meta Tags Used Properly', | ||
| /* Description of the meta tag section within the Accessibility category. Within this section are audits with descriptive titles that highlight if meta tags on the page have been used properly and if any important ones are missing. */ | ||
| a11yMetaGroupDescription: 'These are opportunities to improve the user experience of your site.', |
There was a problem hiding this comment.
lol this is going to dwarf the rest of the config soon
Summary
converts the non-manual accessibility audits to use i18n strings