fix(action): Assistive technology support and announcement for "active" prop

[geospatialem]

Related Issue: #4813

Summary

Adds an aria-pressed attribute that provides context to screen reader users (tested with JAWS, NVDA, and VoiceOver) when the action component is pressed via click, or the Enter or spacebar keys.

Additionally, toggles the active prop when the button is clicked, or pressed via the Enter or spacebar keys, via calciteActionClickHandler.

[geospatialem]

@macandcheese Can you verify if this fix fits the UX/UI of the component, specifically for mouse users?

[macandcheese]

I think the application should still be managing the state of the action (active or not), since there are use cases for an action to be interacted with and not become active

I'm not sure if aria-pressed will always be applicable - since (from my understanding) - this would be used when the action is representative of a toggle.

[geospatialem]

I think the application should still be managing the state of the action (active or not), since there are use cases for an action to be interacted with and not become active

I'm not sure if aria-pressed will always be applicable - since (from my understanding) - this would be used when the action is representative of a toggle.

Appreciate the insights!

Currently screen readers are announcing to activate the component folks must press Enter or spacebar, so its a bit misleading as-is, as neither key alters the state, or provides additional feedback.

Is the intent of active to only be visual, similar to :focus? If so, we wouldn't need to announce the prop value to screen readers, as they'd hear the component text/label on focus. The current experience doesn't allow assistive technologies to switch the active prop, despite what is being read back to them.

Otherwise, since the component is housed in a native button, we might need to consider a differing role to support the component intent a bit more, perhaps a role="checkbox" where aria-checked could be true, false, or mixed. We could potentially use mix to showcase a few different states.

@macandcheese What route (or even "door number three") would you recommend based on the UX/UI?

[macandcheese]

I think the issue is that is can be used in multiple ways.

If you were to use it alongside other actions, in a group, bar, or pad - an app needs to manage which is active. This would be a menu item or potentially more of a radio group type of interaction, even if the action itself doesn't have knowledge of the other action's states.

It can also be used as a toggle, individually from other actions (dark mode on / off) - this is where the toggle / checkbox role seems like it could apply

It sounds like to me, the aria-pressed could be keyed off of the active prop - even if the action component itself doesn't manage that.

Enter / Space could still be applicable even when there isn't an "active" state associated in the UI - for instance, a "Save" action - this would be interacted by click, enter, space, but wouldn't have a visual representation once clicked.

[geospatialem]

Ah, lots of potential outcomes as a result then.

I'm going to close this PR, since we'll likely need to do work across a few different components and verify their roles. Going to add some of the great insights you listed here in the original issue for context, and add a research label to it to determine some possibilities moving forward.