[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

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

[kibanamachine]

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

[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/