Card bug fixes

[ChristopherChudzicki]

What are the relevant tickets?

• Follow up to Card Accessibility Improvements #1778
• Fixes https://github.com/mitodl/hq/issues/6001

Description (What does it do?)

See comments, but roughly:

• Alters how cards' forwardClicksToLink target is found/marked
• Fixes card links on /units page
• Makes whole card clickable on /dashboard/my-lists

How can this be tested?

1. Cards on /units page should be clickable (whole card)
   • Additionally, cards on the unit page should show the same description on desktop vs mobile (See https://github.com/mitodl/hq/issues/6001)
2. Whole card (not just title) on /dashbaord/my-lists should be clickable.
   • Check re-ordering these, too.
3. Other cards should work as before: whole card clickable. (Carousels, search results, Stories + Events)

[ChristopherChudzicki]

Previously, if forwardClicksToLink was true, clicking the whole card would click the child anchor with the card's href.

This turned out to be a bit fragile with NextJS. For example, on the /units listing page, the backend currently returns channel_url values like http://localhost:8062/c/unit/mitx/. But NextJS standardizes the href to NOT have a trailing slashing: http://localhost:8062/c/unit/mitx.

We could try to trim the trailing slash, but that seems complicated for things like /some/path/?foo=bar vs /some/path?foo=bar. So instead, let's just find the relevant anchor by explicitly marking it with data-card-link.

Consequently, the Card no longer needs the href, just the Card.Title.

[gumaerc]

Something I'm noticing is that previously, the unit cards were wrapped in an a tag when this was rendered in the browser. Now, following the link seems to be handled by Javascript. Is this a problem for screen readers? It doesn't make logical sense to me either that an href property would be set on the title, as the whole card is supposed to be clickable?

[ChristopherChudzicki]

This PR is fixing a bug where /units page links were broken. This test should have caught that, except it wasn't actually doing anything because forEach can't be awaited (it always returns undefined) So the test effectively ended on line 144.

[gumaerc]

I'm okay with approving this based on our discussion of why the link forwarding functionality needs to work the way it does. For historical context we discussed how wrapping entire cards in an a tag causes all of the text inside of that card to become the link's textContent property, which makes screen readers read everything inside the card. In order to prevent this from happening, the actual anchor tag is being placed on the title, or on a child element you manually specify using the data-card-link property and then if you set forwardClicksToLink on the parent Card element, clicks on the whole card will go to the nested a tag. We discussed how I think this could be potentially somewhat confusing for new developers, but ultimately decided it was the best solution. We did discuss doing whatever is possible to indicate to developers how this works though, including docstings for Intellisense.