According to https://pages.github.ibm.com/ibmcloud/pal/patterns/getting-started-tab/usage it is a known design to put a button in the accordion:

However, when we try it we get a big error
Warning: validateDOMNesting(...): <button> cannot appear as a descendant of <button>.
because the accordion header itself is rendered as a
const getTitle = (name, description, buttonText, page, link) => {
return (
<React.Fragment>
<div className={`${COMPONENT_NAME}__title-text`}>
<div className={`${COMPONENT_NAME}__name`}>{name}</div>
<div className={`${COMPONENT_NAME}__description`}>
{description}
</div>
<Button
className={`${COMPONENT_NAME}__title-button`}
href={link}
target='blank'
kind='tertiary'
onClick={() => routeTo(page)}
>{buttonText}</Button>
</div>
</React.Fragment>
);
};
<AccordionItem
className={`${COMPONENT_NAME}__title`}
title={
getTitle(
t('overview.steps.addSecretName'),
<Trans i18nKey='overview.steps.addSecretDescription' components={[getLinkElement()]}/>,
t('overview.steps.addSecretButton'),
'addSecret',
null
)
}>
{
getContent(
<VideoPlayer src={getMediaUrl('GIF_1.mp4')} />,
true,
t('overview.steps.addSecretNotificationTitle'),
<Trans i18nKey='overview.steps.addSecretNotificationSubtitle' components={[getSettingsLink()]}/>,
<Trans i18nKey='overview.steps.addSecretDetails' components={[setBoldTreatment()]}/>
)
}
</AccordionItem>
There is also an accessibility issue here, because AccordionItem is a Button then all the text inside it is read at the same time when moving through it, also if I put a link, it is not read by Jaws (insert+F7) links, and cannot be used correctly (user does not know on which element he is on).
I think changing the AccordionItem to div would fixed all these issues (I checked and changed it locally in the html page to div and that fixed it). When it was button, Jaws did not recognize the Learn more link)

@carbon-design-system/design Are we allowing Button's to be placed in the Accordion Title?
@dakahn any a11y concerns with changing this from a button to a div with a role of button?
Unfortunately, if you nest buttons then it removes the semantics of the inner button 馃槥 This would apply to nesting the <button> element along with role="button" and a nested button.
For example:
<div role="button" tabindex="0">
Toggle
<button>Submit</button>
</div>
Would read as: Toggle Submit. A screen reader like VoiceOver would be unable to navigate to the inner button (Submit) 馃槥
Typically the remedy to this is to separate out the two actions instead of nesting one inside of the other.
Any update on this? or was the solution here, NOT to use button, and you guys are not moving to div?
does renderExpando help with this use case? https://github.com/carbon-design-system/carbon/blob/master/packages/react/src/components/Accordion/AccordionItem.js#L26
@alon24 unfortunately I think the problem is that you can't nest buttons, and the trigger for the accordion (which takes up the full width) is a button so anything inside of it will need to be non-interactive.
Closing! Can reopen if we need to though.
Most helpful comment
@alon24 unfortunately I think the problem is that you can't nest buttons, and the trigger for the accordion (which takes up the full width) is a button so anything inside of it will need to be non-interactive.