fix: 🤔 clarify and/or fix interactive `sd-teaser`

[karlbaumhauer]

Current behavior

Caused by the need of several teams, we added a sample which shows the teaser where the teaser itself is a clickable element AND it contains another clickable element.

=> https://solid-design-system.fe.union-investment.de/x.x.x/storybook/?path=/story/components-sd-teaser--samples-clickable

With this sample of the teaser we currently have 2 issues:

1. It is unclear if this is actually a solid solution we should provide
2. The story currently has 2 bugs:
   1. The tab-order does not work as expected. The first CTA is not being focused at all
   2. As we have 2 different hover zones inside the teaser, the teaser itself shows a hover effect (light gradient) and as soon as the user hovers over the CTA inside the teaser, it keeps the hover effect but adds the hover effect on the CTA to it => not clear to the user which element is being hovered.

Expected behavior

1. We have clear understanding on what we want to achieve (and write it down)
2. If we keep the sample, the bugs need to be fixed

Regarding 2.2. => expected behavior needs to be defined by UX

Steps to reproduce

1. open the URL https://solid-design-system.fe.union-investment.de/x.x.x/storybook/?path=/story/components-sd-teaser--samples-clickable
2. click in the white space inside the story
3. start tabbing on the keyboard

   Technical Information

   This topic has been part of a PR and the respective ticket in January but unfortunately, we did not write down any summary from our discussions we had.

   DoR

   • [ ] Item has business value
   • [ ] Item has been estimated by the team
   • [ ] Item is clear and well-defined
   • [ ] Item dependencies have been identified

DoD

• [ ] Documentation has been created/updated (if applicable)
• [ ] Migration Guide has been created/updated (if applicable)
• [ ] Relevant E2E tests (Features, A11y, Bug fixes) are created/updated
• [ ] Relevant stories (Features, A11y) are created/updated
• [ ] Implementation works successfully on feature branch

[mariohamann]

Adding some additional context from our conversation and the initial task:

"doesn't break valid HTML (links inside links are not allowed :))".

Citing HTML specs for <a>:

[...] there must be no interactive content descendant, a element descendant, or descendant with the tabindex attribute specified.

And here the list of interactive elements:

Interactive content is content that is specifically intended for user interaction.

• a (if the href attribute is present)
• audio (if the controls attribute is present)
• button
• details
• embed
• iframe
• img (if the usemap attribute is present)
• input (if the type attribute is not in the Hidden state)
• label
• select
• textarea
• video (if the controls attribute is present)

Here are some useful resources on links on cards:

• https://www.sarasoueidan.com/blog/nested-links/
• https://inclusive-components.design/cards/ / https://inclusive-components.design/cards/#callstoaction

Currently we're clearly violating specs here, so let's see, what the solution will be. :)

[mariohamann]

I just created a proposal, how this could work out in future without violating specs and a11y: https://codepen.io/mariohamann/full/wvLjdLr

@christophsaile helped me testing it and so far it looks good!

I would propose that we let test this in the accessibility audit instead of the other template.

[christophsaile]

@mariohamann a possible improvement could be that button/link also receives focus state when the focus on the card is active. See last example here: https://codepen.io/aardrian/pen/vYOGpXb. This way it is more clear that the card and the button / link are the same interaction

[matuzo]

This solution is definitely an improvement, but it's not perfect. The good news is there is no perfect solution. That pattern is still an unsolved problem.

My two cents:

• I don't like the duplication of interactive elements the solution requires.
• While I don't have a clear picture of the final implementation, I urge caution. There could be a mismatch between the visible accessible name of the call to action component (link or button) and the hidden link or button. That could pose a problem for voice users. I know you purposely put "(hidden link)" there, but it illustrates the mismatch I'm talking about well. A voice user would say, "Click visit union investment," but potentially nothing would happen because the accessible name is "Visit Union Investment (Hidden Link)."
• Putting tabindex=-1 and aria-hidden=true on interactive elements is generally not the best idea.
• This may or may not be an issue, but text isn't selectable.

You can address my first three concerns by using a pseudo-element instead. See this CodePen for a demo.

sd-teaser{
  position: relative;
  margin: 8px;
  transform: translate(0); /* creates a new stacking context */
}

sd-button::part(base)::before {
  position: fixed;
  inset: 0;
  display: block;
  content: "";
}

If you want to make certain parts selectable or if they include other interactive elements, you can promote them to the top layer on the z-axis.

p {
  position: relative;
  z-index: 1;
}

[coraliefeil]

Why don’t we just go with solution 6 / pseudo element here?

https://codepen.io/matuzo/pen/ZEqbXOM

Seems to be the best option.

It would have to be adapted a little in the example so that both links are clickable.

The link would still need position: relative and a z-index , then it is also clickable