Add accName to icon buttons, implement error icon when button doesn't have an accessible name

[gcamacho079]

Description

• Waits for child components in the craft-button component to load, then calculates the accessible name. If no accessible name is found, it updates the button with an error icon.
• Updates some of the labels we've had pre-v6 for clarity — toggle versus show, since "Show" insinuates that the toggle is aria-expanded="false", even though the state may have changed to aria-expanded="true"

Related issues

Resolves PT-3005, PT-3000, PT-3004

[linear]

PT-3005 Hamburger button doesn't have an accessible name

PT-3000 Navigation submenu expand button doesn't have accessible name

PT-3004 Navigation drawer close button doesn't have accessible name

[brianjhanson]

I updated the styles a bit to hopefully make these issues stand out a bit more

Other than that, looks good! I'm curious if we'll end up seeing a performance hit from calculating the computed name whenever the button renders, but I feel like we can just keep an eye on it.

If we do, I'm curious if we could just include something like a11y.css and have a way to toggle it easily to achieve a similar goal without the same overhead.

[gcamacho079]

I updated the styles a bit to hopefully make these issues stand out a bit more

That looks great, @brianjhanson! I updated the styles to use some of the new color tokens that meet contrast. I initially had visually-hidden text inside the button that read Error, but the recent update changed it to !. I'm now considering the following update:

We mark the CSS content as decorative (content: '!'/'') so that the button still doesn't receive an accessible name; however, we can include visually-hidden error text outside the button that we can reference via aria-describedby.

<span aria-hidden="true" id="global-accName-error"></span> // Hidden visually and — due to `aria-hidden` — only encountered via SR users when it's referenced via `aria-describedby`
<button aria-describedby="global-accName-error"></button> // Button without an accName

This would have the following benefits:

• The issue could also show up via an automated a11y scan inside the control panel, so it isn't only obvious via a visual change
• The error messaging has a text alternative via the aria-describedby attribute on the button

Thoughts? 🤔

Other than that, looks good! I'm curious if we'll end up seeing a performance hit from calculating the computed name whenever the button renders, but I feel like we can just keep an eye on it.

If we do, I'm curious if we could just include something like a11y.css and have a way to toggle it easily to achieve a similar goal without the same overhead.

My understanding of a CSS solution like this is that we could technically check to see if the attributes exist, but not necessarily if there is a calculated accessible name. For example, we could only show the error styles if aria-label or aria-labelledby are not present on the button; but what if the aria-labelledby attribute is present, but it points to an empty HTML element? That would result in there not being an accessible name.

You previously mentioned that we could implement a11y checks like this only when we're in devMode. If the infrastructure is in-place for that, that might be the way to go.