Website: Adds a11y audit in acceptance tests

[MelSumner]

📌 Summary

If merged, this PR will add acceptance tests for each page so we can use ember-a11y-testing on our website.

• adds an acceptance test for each page in the website
• adds the a11y audit
• fixes the issues in failing tests
• cleans up some typos and linting failures that I came across

Related PRs:

• Adds aria-label to breadcrumb truncation toggle #1127
• Tabs component: moves the icon and count inside of the button for WCAG conformance #1130

---

💬 Please consider using conventional comments when reviewing this PR.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
hds-components	✅ Ready (Inspect)	Visit Preview	Jan 26, 2023 at 7:27PM (UTC)
hds-flight-website	✅ Ready (Inspect)	Visit Preview	Jan 26, 2023 at 7:27PM (UTC)
hds-website	✅ Ready (Inspect)	Visit Preview	Jan 26, 2023 at 7:27PM (UTC)

[alex-ju]

This looks good overall! It's a shame we have to have separate files with a similar configuration, but once they're set up I don't see us tweaking them often, so not a burdain from a maintenance perspective.

[didoo]

@MelSumner added a comment, that I think is a blocker (we need to take a decision as a team if we want to follow this approach for the documentation).

[didoo]

Apart from passing the tests, what is the benefit of doing this? I don't think we can have an expectation that all the code snippets (rendered as components), for every possible component, now and in the future, in every possible context, will pass all the accessibility criteria.
The downside of this is that when the consumers will copy this code snippet (or other code snippets in other pages for other components) they will copy code that may not be suitable for their context, or even incorrect.
I am totally OK to make the HDS components as much accessible as we can (eg. if the aria-label is required for the Breadcrumb let's add a property for that) but I want to have a discussion, as a team, and evaluate pros and cons, of making also all the code snippets for the HDS components in the Helios documentation also pass all the accessibility tests.

[MelSumner]

I would ask you to consider this: We expect our examples to work, we expect our CSS and JavaScript to be correct, why would Accessibility be any different?

1. If I am a user with a screen reader, and I visit this page, I am presented with a list of breadcrumbs, with no way to differentiate among them. So it becomes a non-equitable discoverability issue: while a user who can see the screen can quickly differentiate among examples and copy the example that is appropriate for them, the user with AT has to go through each example and remember which examples are there, then try to find the one that they want to copy.
2. I do not think our consumers will be confused by the presence of different aria-labels. The presence of unique labels will reinforce the Success Criteria and provide supplementary learning through the examples.

I hope you will re-consider your point of view.

[heatherlarsen]

When consumers copy and paste the code snippet into their project, do we expect them to keep the aria-label, or is this something they would likely remove?

If it's something they'll remove, is there a way to attach the aria-label to the code snippet block (container) instead of directly in the component itself?

[MelSumner]

@didoo In order to unblock this PR, I can commit to a follow-up PR that explores potential alternative approaches that achieve the same outcome.

[MelSumner]

@heatherlarsen @KristinLBradley there's already an aria-label on the component itself (default is aria-label="breadcrumb") so that would take precedence (here on the docs website)

To answer the first question: any application that uses internationalized strings would change the content-

so aria-label="breadcrumb" would be edited to be aria-label={{t "breadcrumb"}}

But this goes for anything that has a string value like @text etc. Pretty much everything they copy and paste already has to be heavily edited, since they are superficial examples and not specific to a product. We put the args/props and values there to demonstrate how it is done, and they copy/paste and edit to match their own use case.

[MelSumner]

@didoo @Dhaulagiri I've created https://hashicorp.atlassian.net/browse/HDS-1454 to track the additional exploration for reducing the amount of code the developer needs to change from a code sample. I believe this should be sufficient to unblock this PR so we can get it merged before launch, and as such I've requested a re-review.

[didoo]

@MelSumner sorry closed by accident

[MelSumner]

After further discussion with @Dhaulagiri, I've removed the aria-label from the code samples and skipped the a11y tests for the breadcrumb page for the time being; we will revisit at a later date.

[didoo]

added a minor comment and a possible idea.

all good! 👍