[EuiAccordion] Added isDisabled to disable interaction and subdue trigger

[cchaos]

New prop

The new top level isDisabled prop will propagate this to any <button> elements as disabled, removes the onClick behavior, and applies specific styling to subdue the basic trigger.

Note
This PR piggy-backs off of the initial work from #6088

Checklist

• Checked in both light and dark modes
• Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox
• Props have proper autodocs and playground toggles
• Added documentation
• Checked Code Sandbox works for any docs examples
• Added or updated jest and cypress tests
• [ ] Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• Updated the Figma library counterpart
• A changelog entry exists and is marked appropriately

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6095/

[chandlerprall]

Everything looks good to me, but one thought as I tested with voice over. disabled elements cannot be tabbed to, so the tooltip will not be triggered or read by keyboard usage. However, focusing the text field does read the associated error message, so I don't think this is something to solve in (or is solvable by) EUI. We may want to add more emphasis around ensuring good error messages to the call out.

[1Copenut]

LGTM. I agree with @chandlerprall that the tooltip won't fire for screen reader users who are navigating by TAB key or keyboard users. This puts the onus on good error messages and possibly SR-only helper text. Between those two things, I feel like we account for the missing tooltip.

[cchaos]

@1Copenut To confirm, you are ok with the docs as they are even though the tooltip is inaccessible?

[1Copenut]

@1Copenut To confirm, you are ok with the docs as they are even though the tooltip is inaccessible?

I took a second look at the callout language, and am going to reverse my field. I'm 💯 on the code changes, but the docs should be more explicit about the ramifications of disabling the button. Here's what I'm thinking for a revised callout:

If you disable the accordion button, nested tooltips will not be keyboard accessible. You will need to provide a clear error message. Consider adding screen-reader only text to the disabled button or error message.

[cchaos]

I feel like this creates a conflict between screen reader users and sighted users; having to use a tooltip for one and screen-reader-only elements for the other. Is there something that both can benefit from?

[chandlerprall]

My 2 cents: I don't think there's a need to ask for screen reader text as the disabled accordion doesn't have an affordance. The only indication it exists is visual, and the presence of a decent error message colocated in the accordion should provide context for why it is locked open. IMO, the tooltip's only need is to address the "why can't I click on this" state, which it does.

[cchaos]

We chatted in the Emotion sync about this and decided to remove the tooltip altogether and just lean into error/help text. Pushing an update now

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6095/

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6095/

[1Copenut]

👍 LGTM. Thanks @cchaos for the docs update.