[Action Bar] Add aria-expanded to expand/collapse button

[geospatialem]

Summary

Add context to the action-bar's expand/collapse button when it is expanded. Surfaced as part of MapViewer's a11y audit in the Spring of 2022.

Actual Behavior

Context is provided if the action can be collapsed or expanded. However, no context is provided for AT to know an expansion or collapse has taken place.

Expected Behavior

Announce if the component is expanded or collapsed to AT by adding an aria-expanded property (true/false) boolean, which provides additional context to AT.

Reproduction Sample

https://developers.arcgis.com/calcite-design-system/components/action-bar/#sample

Reproduction Steps

1. Open a screen reader of choice (VoiceOver, NVDA, or JAWS)
2. Open the Developer site sample
3. Navigate via keyboard to the "Expand/Collapse" action
4. Observe while the context is provided if the action can be collapsed or expanded, no context is provided for AT to know an expansion or collapse has taken place

Reproduction Version

1.4.0

Working W3C Example/Tutorial

No response

Relevant Info

No response

Regression?

No response

Priority impact

p4 - not time sensitive

Esri team

Calcite (dev)

[driskull]

@geospatialem one issue I'm seeing here is that calcite-action already has a active property which translates to aria-pressed. It seems like both aria-pressed and aria-expanded are conflicting with each other.

Should we maybe refactor this so they can't both be set? Is there some workaround for when the following happens?

<button aria-expanded="true" aria-pressed="true">
  Toggle
</button>

[geospatialem]

@geospatialem one issue I'm seeing here is that calcite-action already has a active property which translates to aria-pressed. It seems like both aria-pressed and aria-expanded are conflicting with each other.

Should we maybe refactor this so they can't both be set? Is there some workaround for when the following happens?

That sounds like a good plan forward.

It looks like aria-pressed is associated with the active property, does that sound right?

calcite-design-system/packages/calcite-components/src/components/action/action.tsx

Line 318 in f199b3c

aria-pressed={toAriaBoolean(active)}

If so, @driskull - what would you think about removing aria-pressed, which shouldn't indicate a "selected" or "active" state, but rather adds "press" context for AT users. And instead consider a new translation to the button's aria-label indicating its active state, similar to what is added when indicator is true?

calcite-design-system/packages/calcite-components/src/components/action/action.tsx

Line 302 in f199b3c

const ariaLabel = `${label || text}${indicator ? ` (${messages.indicator})` : ""}`;

[driskull]

It looks like aria-pressed is associated with the active property, does that sound right?

Yes, correct.

what would you think about removing aria-pressed, which shouldn't indicate a "selected" or "active" state, but rather adds "press" context for AT users. And instead consider a new translation to the button's aria-label indicating its active state, similar to what is added when indicator is true?

Shouldn't we keep aria-pressed because some of these buttons are toggle buttons. right? active means that its "on". If we remove it, we lose that context. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-pressed

[driskull]

I think we'll need to setup some time to discuss a plan moving forward here.

We already have a property for toggling (active) but we don't have a property for expand status. We would need a new property to handle this because aria-expanded needs to be added to the internal button element.

[geospatialem]

We already have a property for toggling (active) but we don't have a property for expand status. We would need a new property to handle this because aria-expanded needs to be added to the internal button element.

Ah, gotcha, thanks for the context - was initially thinking the action component was providing a selection state, rather than leveraging aria-pressed - it's more clear now.

Concur with your original statement above- we'd want to ensure aria-pressed and aria-expanded aren't used together with the action-bar, and when the component is expanded, ensure aria-expanded takes precedence. Per your proposal above, a new property with conditions sounds like the best path forward, if you still agree?

[driskull]

Yes, I agree. We'll have to deprecate active and have a new property for handling toggled/expanded state.

[driskull]

I guess we would have to add something like:

state: "pressed" | "unpressed" | "expanded" | "collapsed";

state: "on" | "off" | "expanded" | "collapsed";

state: "active" | "inactive" | "expanded" | "collapsed";

Would we need to support the mixed state of aria-pressed?

[driskull]

When something is "expanded" would it get the same background color affordance as when "pressed/active"?

[driskull]

I guess we could just add an expanded property on action which would take precedence over active? What do you think? is that easier than a single mode?

[driskull]

I think this needs a design/api discussion before it can move forward.

[github-actions]

cc @geospatialem, @brittneytewks

[geospatialem]

The above is blocked and sending to the freezer 🥶 until accessibility API supports shadow DOM further for implementation. As this is not currently feasible within shadow DOM, since the component relies on an internal button via the shadow DOM.

Some resources for consideration and checking on the Accessibility object model (AOM), once supported:

• AOM: https://wicg.github.io/aom/explainer.html#the-accessibility-object-model
• Cross root ARIA delegation proposal: https://github.com/leobalter/cross-root-aria-delegation/blob/main/explainer.md
• Great overview post: https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibility-the-trouble-with-aria/

[driskull]

If we add a property of type to calcite-action of type: "button" | "toggle" | "expand" that would get us closer.

We could use active for toggle and expand or we could add another property just for expanded. Thoughts here? @jcfranco @geospatialem

Maybe we deprecate active and have selected and expanded added.

[driskull]

The reason we need a different type for expand is that expand uses aria-expanded instead of aria-pressed