Change all ARIA labels to translatable messages

[wjhsf]

Description

Noticed when reviewing #1570 that the ARIA labels were hard-coded strings, rather than translatable messages. Did a quick search in the project to find all the other instances of that. Spotted a few small issues along the way, so I fixed those as well.

Types of Changes

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Breaking change (could cause existing functionality to not work as expected)
• Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

• Removing a public function or component or prop
• Adding a required argument to a function
• Changing the data type of a function parameter or return value
• Adding a new peer dependency to package.json

Changes

• Listed in commit history

How to Test-Drive This PR

To test that the messages are now translatable:

• Update relevant translations in translation files
• Start dev server
• Observe that your changes are reflected on the page

To test other changes

• Start dev server
• Click "My account" button as guest. Should open login modal.
• Click "My account" button as registered user. Should go to account.
• Hitting space/enter on "My account" button should have the same result as clicking.
• Hitting space/enter on account menu icon should open the menu.
• Turn on VoiceOver
• View login screen.
• Tab over the 👁️‍🗨️ icon. Should say "show password".
• Click 👁️‍🗨️ icon. Should show password and now say "hide password".
• Tab focus on "My account" button. It should now say "My account, button"
  • It should probably be a link, rather than a button, but that's harder to change without breaking customers
• Tab focus on account dropdown icon. It should now say "Open account menu"

Checklists

General

• Changes are covered by test cases
• CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance

You must check off all items in one of the follow two lists:

• There are no changes to UI

or...

• Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
• Changes comply with WCAG 2.0 guidelines levels A and AA
• Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

• Changes include a UI text update in the Retail React App (which requires translation)

[alexvuong]

This was a bug reported from UX awhile ago saying if a user is current in login page, the account click should not show the modal since user is already seeing the login form

[wjhsf]

That bug is also handled by the withRegistration component. Although I noticed that here the logic handled /login, and the withRegistration component handles /{locale}/login, but what the app actually uses is /global/{locale}/login. I've changed the withRegistration component to be more flexible.

[alexvuong]

is locale being used?

[wjhsf]

Not here, but it was in the original implementation, so I figured we'd keep it to make customizations easier.

[alexvuong]

There is only one place that defines the isLoginPage which does not take locale. I don't think we need to do it here. 🤔 .

[wjhsf]

Locale was used previously:

pwa-kit/packages/template-retail-react-app/app/components/with-registration/index.jsx

Line 22 in 9baf1c8

const isLoginPage = new RegExp(`^/${locale}/login$`).test(location.pathname)

Because our default implementation has multiple login pages (/login, /en-GB/login, /global/en-GB/login), I decided to change the isLoginPage logic. But, to make it easier for customers to implement the previous logic (or any locale-dependent custom logic), I think it's reasonable to also provide locale.