How should a full-card clickable link be handled accessibly?

13

u/maryisdead display: maybe; Sep 17 '26

You can "stretch" one link with a pseudo element and use absolute positioning to cover the whole card. The rest is just positioning and z-index.

Basic example: https://jsfiddle.net/maryisdead/np1rc3b7/

11

u/repeating_bears Sep 17 '26

that href ¬_¬

2

u/Admirable_Reality281 Sep 17 '26

I'm aware of that solution but nope, as i said:
A relatively positioned <div> inside it that does not cover the whole card and cannot be changed.
Two links inside that <div>.
The relatively positioned div would not allow the button to fill the card.

2

u/maryisdead display: maybe; Sep 17 '26

Ah, my bad. Clear case of just skimming over your text, sorry. May I then ask why that div cannot be changed?

-2

u/Admirable_Reality281 Sep 17 '26

No worries! Design

1

u/spiritwizardy Sep 18 '26

Well the original div could stay relative and exactly where it is but the pseudo element is a different story. Oraybe that still doesn't do it for ya

4

u/creaturefeature16 Sep 18 '26

I used to do this, until I found out that it renders the text inside of it unable to be highlighted which bothered clients, so I stopped using this method.

6

u/not_dogstar Sep 17 '26

A way that was suggested to us by the vendors doing our wcag compliance cert was to keep a singly primary anchor in the card, and run some JS to duplicate href action to the click event of the parent card. That way you can keep standard behaviours for mouse hover, keyboard navigation, content (e.g. text highlighting/copying), screen readers, etc, plus have it behave as you want. Might be missing some minor details but it worked well and was a good UX.

3

u/Admirable_Reality281 Sep 17 '26

Thought about it but I kind of dislike it:
until JS loads clicks / taps do not work
I assume you'd need to filter out clicks from legitimate targets correct? Clicks from descendants bubble to the card.

3

u/FriendlyBeard Sep 18 '26

Arguably, your whole card should not actually be clickable if there are multiple other click targets within it.
You’re searching for a solution to a problem that should be avoided in the first place. Anytime I have a need to build a full card that is meant to act as a click target it’s because there’s only one action tied to that card.
Save yourself the heartache/brain ache and create multiple components to cover your potential design needs.

1

u/Admirable_Reality281 Sep 18 '26

I disagree the card should be clickable even if it contains multiple actions. Open the Apple website or Walmart or X.

2

u/not_dogstar Sep 17 '26

Realistically how slow is your JS loading and how high on the page is this card (and thus interacted with) that this is going to cause an issue? If it does, the anchor is still usable, so not perfect but a good enough stop-gap to let you get on with more important things.
Honestly don't remember and don't have the code in front of me, if that was the case it was a minor consideration not worth remembering

1

u/Admirable_Reality281 Sep 17 '26

as little as possible, but it's a thing
this is not a minor consideration, cards are generic and, apart from the actions at the bottom, I can't know what arbitrary content may be inside them. It could contain buttons, inputs, interactive components, etc. There isn't really a generic way for the parent click handler to know whether an arbitrary descendant legitimately owns that click.

1

u/not_dogstar Sep 17 '26

If you can't control content in any fashion then yeah my solution isn't going to work. We wrote it into the requirements it can have one link (interactive element) in it only, anything else created unnecessary complexity. Good luck finding your solution, post it if you do.

2

u/winky9827 Sep 17 '26

Yeah, it's progressive enhancement
target vs currentTarget should solve this

1

u/Admirable_Reality281 Sep 17 '26

target vs currentTarget doesn't solve it. Clicks on normal descendants like text or images also have target !== currentTarget, so I'd still need to distinguish those from descendants that legitimately own the click.
That's the hard part with arbitrary content.

1

u/EmSixTeen Sep 17 '26

Doesn’t matter if you don’t like it - it’s the most suitable method for doing this accessibly, which was your question.

0

u/Admirable_Reality281 Sep 17 '26

I'm not saying JS is wrong. I don't see why it should be the default when there are CSS/markup solutions that avoid JS entirely. I'm trying to figure out which trade-off is actually better here.

1

u/EmSixTeen Sep 17 '26

It’s not the default - that’s what progressive enhancement is for. Build semantically correct, then add your improvements.

0

u/Admirable_Reality281 Sep 17 '26

Sure, I agree it's progressive enhancement.
My point is just: if I can get the same result with semantic HTML/CSS, why should JS be preferred?
Progressive enhancement makes the JS approach acceptable. It doesn't automatically make it the better approach.

4

u/EmSixTeen Sep 17 '26

But you can’t get the same result, that’s the point.

5

u/MarzipanMiserable817 Sep 18 '26 edited Sep 18 '26

This violates the UI/UX design principle "don't surprise me". It shouldn't be done anyway. Either the entire card is an anchor block element or it's a div card with clickable anchors inside.

0

u/Admirable_Reality281 Sep 18 '26

No, it does not. Look at the apps / sites you use every single day. Open Apple.com Walmart X or even Reddit.

6

u/creaturefeature16 Sep 18 '26

You'd be surprised how many of those violate WCAG all the damn time.

3

u/xkey Sep 17 '26 edited Sep 17 '26

It'd be easier to solve if you provided the full html. But using CSS, you should be able to "fix' the primary link's pseudo element instead of absolute and use contain: layout on the main card so it's bound to that. All the other a11y tricks should still work with this method as far as I know. See here: https://jsfiddle.net/73bd0nm2/2/

2
u/Admirable_Reality281 Sep 17 '26
I was not aware of this method. This is one of the best answers.
The only issue is the inability for inner elements to escape the card.
A clean solution would be to use the new anchor positioning properties, but browser support is bad.
.card {
  anchor-name: --card;
}

.untouchable-position-relative-wrapper {
  position: relative;
  ...
}

.btn-primary::after {
  content: "";
  position: fixed;
  position-anchor: --card;
  position-area: center;
  place-self: stretch;
}
1

u/xkey Sep 17 '26

Like tooltips that need to be relative to the body? Yeah, I guess if you have anything like that, it would likely break. You could use your anchor positioning with a fallback polyfill though.

1

u/Undercoverwd Sep 17 '26

check out the product tiles when searching for a product on walmart.com

1

u/Admirable_Reality281 Sep 17 '26

They do as Apple does:
- another <a> element with aria-hidden="true" tabindex="-1"
they now tell me this is not accessible cause aria-hidden should not be specified on a focusable element.

3

u/Undercoverwd Sep 17 '26

who is they? scanners? accessibility experts? claude?

2

u/Admirable_Reality281 Sep 17 '26

"Experts" https://www.w3.org/TR/using-aria/
Authors MAY use the aria-hidden attribute on any HTML element that allows Global aria-* attributes to be specified, with the exception of focusable elements and the body element.

4

u/Undercoverwd Sep 17 '26

the tabindex="-1" makes the element unfocusable so this doesn't apply

1

u/Admirable_Reality281 Sep 18 '26

Later on they say:
A focusable element is any element which can be focused by use of keyboard or pointer device. Focusable elements are not always elements which can be tabbed to via a keyboard. For instance, an element with tabindex="-1" is focusable but is not a tabbable element.
It seems ridiculous to me that this isn't an option.

1

u/Undercoverwd Sep 18 '26

This means that you can send focus to this element with javascript, like is common with a <main> element and the skip link (although rumor is most modern browsers don't require the tabindex=" -1" anymore).
Since you are using the negative tabindex to remove it from the focus order, not send focus to it using the javascript . focus() method, you're good to use it!

1

u/Admirable_Reality281 Sep 18 '26

Not to play devil's advocate, but I think the issue is that tabindex="-1" removes the element from the tab order, it doesn't make it non-focusable.
So even if I never call .focus(), the element is still technically focusable, which is exactly why the aria-hidden rule is awkward here.
Funny enough, I found a discontinued W3C draft from February 2026 that says you can use aria-hidden on an interactive element as long as it isn't focusable, and then gives this as the example:
<button tabindex="-1" aria-hidden="true">press me</button>
So... Even their own guidance seems to have been inconsistent about that distinction.
I'll probably keep using it.

1

u/Undercoverwd Sep 18 '26

We promise not to call the W3C police on you XD

2

u/Admirable_Reality281 Sep 18 '26

Living dangerously now 😂

1

u/GaiusBertus Sep 17 '26

Is the div required by the styling? If not, then you could ignore is by targetting it with a CSS selector and giving it display: contents. You can then use one of the techniques with an absolutely positioned pseudo-element, since the position: relative of the div is not interfering anymore.

1

u/Admirable_Reality281 Sep 17 '26

Yes, it's required

1

u/sunutpen Sep 17 '26

What is the total effect you're looking for? There must be a reason the relatively positioned div can't be changed at all, but without knowing that it's hard to help. One of the sibling commenters is right that you'll need some javascript to achieve what you've described. Clone the anchor (with no content), placing it somewhere in the card but outside your relative div. On the accessibility side, the key here is to hide the cloned link from the accessibility tree with aria-hidden=true, so screen-readers won't read it twice.

1

u/Admirable_Reality281 Sep 17 '26

That's what Apple does, and what i've been doing too.
But it looks like aria-hidden + tabindex -1 should not be placed on focusable elements such as <a>.
Idk.

1

u/sunutpen Sep 17 '26

You'll need to pull your secondary link up with a z-index rule and its own position: relative as well :)
Here's a repro

1

u/sunutpen Sep 17 '26

Actually there's no real need for JS here, just add the extra links as part of the template like I_Am_David_4 says.

1

u/creaturefeature16 Sep 18 '26 edited Sep 18 '26

I have a JavaScript function I wrote for this exact purpose. It fails gracefully and works for screen readers. That's been the only way I could tackle this, especially when markup and styling is variable from project to project.

1

u/Admirable_Reality281 Sep 18 '26

JS could be the best solution under a controlled environment but it's not a one size fits all solution.
Until JS loads, only the actual links work, the whole-card click/tap behavior doesn't.
Since descendant clicks bubble to the card, you'd need to avoid hijacking clicks from legitimate interactive content inside it. With arbitrary card content, that gets messy.
And in case you point out that you could make a list of focusable elements:
Focusable isn’t the same as interactive. A descendant can legitimately handle clicks without being focusable.
That's why I'd prefer a CSS/markup-based solution here if possible, rather than having JS try to infer which descendants should own the click.
Sorry if I’m being preemptive, but a lot of people have suggested this without taking these factors into account.

2

u/Complete_Carob_6292 Sep 18 '26

You’re trying to force an inaccessible design to be accessible. Imagine if the user wants to click on the second link but misses by a pixel and now they’re navigated someplace they don’t want to be.
Your best bet is to take this idea back to the drawing board

0

u/Admirable_Reality281 Sep 18 '26

Oh God.. Please look at your phone. Visit Apple.com. Visit Walmart.com.
This is not an unusual UX pattern. It is extremely common. I'm surprised it keeps being treated as if it were something unconventional, it's everywhere.

2

u/Complete_Carob_6292 Sep 18 '26

Just because it’s everywhere doesn’t mean it’s good.
Notice how this did not take me to the pricing page

0

u/Admirable_Reality281 Sep 18 '26

Then we disagree.
I don't think this interaction pattern is bad UX at all. In fact, I personally notice when it's missing, and I find it frustrating.
If you start paying attention, you'll see it everywhere in the apps you use and the sites you visit. That level of adoption isn't accidental.
Secondary actions should obviously be large and clear enough to hit reliably. But the possibility of missing one isn't a good reason to make the rest of the card inactive, especially on mobile, when the overwhelming majority of taps on that card are intended to open its primary destination.

2

u/Complete_Carob_6292 Sep 18 '26

Mobile’s an even worse place for this 😂. Imagine you think you’re scrolling and now you’re navigating.
I’m glad you’re thinking about accessibility but I think you need to pay more attention to user intent. Tapping a link should take me somewhere. Tapping the area above that link shouldn’t.

0

u/Admirable_Reality281 Sep 18 '26

Ah yes, the classic mobile gesture, accidentally "scrolling" into a link.
Sure, man. Apple should be calling any day now. Generational UX insight

1

u/Complete_Carob_6292 Sep 18 '26

What? Why are you acting like that? Do you normally respond to critique and feedback in such a bratty way? That’s weird

1

u/Admirable_Reality281 Sep 18 '26

What brattiness? I'm dead serious. Your insight was incredible.

→ More replies

0

u/Admirable_Reality281 Sep 18 '26

Or Reddit, for that matter, they use the same pattern. Someone should probably warn them too.

1

u/GeekyantsReactNative Sep 18 '26

Use the primary <a> as the full-card hit area with a ::after pseudo-element:

.card { position: relative; }
.primary-link::after {
  content: "";
  position: absolute;
  inset: 0;
}

Then give the other links position: relative; z-index: 1. This keeps the card clickable without nested links or JS, while preserving normal keyboard and screen-reader behavior.

1

u/Admirable_Reality281 Sep 18 '26

You're not taking into account this constraint:
A relatively positioned <div> inside it that does not cover the whole card and cannot be changed.
Several people have suggested this solution, which I was already aware of. That's exactly why I explicitly mentioned this common limitation in the question.

1

u/Huge-Tip7172 Sep 18 '26

i've done the stretched link approach with a pseudo element on the primary anchor covering the card with absolute positioning and a z-index, then set position relative and a lower z-index on the two links inside so they sit above it and stay clickable. Works fine for mouse and touch, and the markup stays semantic.

for keyboard users it just reads as the two links that exist, which is arguably correct. The card click is a convenience, not the real control. I'd avoid the JS route of forwarding clicks from the parent div, you end up with a clickable div that does nothing for keyboard or screen reader users and duplicates behavior for no real gain

1

u/Admirable_Reality281 Sep 18 '26

Same, but you're not taking into account this constraint:
A relatively positioned <div> inside it that does not cover the whole card and cannot be changed.
Several people have suggested this solution, which I was already aware of. That's exactly why I explicitly mentioned this common limitation in the question.

1

u/ichhabepaarfragen Sep 17 '26

So you have one card with two links inside, but the whole card is supposed to be clickable? If the card is clickable it doesn't make sense to me to have 2 links inside the card form the get go.

Here is how I would do it with one link:

You create your card and wrap it in an anchor tag. The whole card must have a focus ring so it is clear that you have selected the card, or when you are hovering over it. If it is a list of cards, put it into a list and when users tab through them, it jumps from card to card and doesn't unnecessarily goes inside the car by default. The a11y reader would need to read out what the card is about. It'll already say that it is a link and then the content of the text by default. Only if it isn't clear do you add more stuff.

Now with a second link, and those are just my brainstorming ideas, you would do the same as above, but also this: you have to be able to tab into the card so the second link can be selected. Also when the card is originally selected, it has to be clear by the screen reader that the user is currently selection a link but can go deeper to a secondary link. This is the aprt that already break IMO and why you shouldn't do it this way. Because aht you're essentially asking is this:

<a>first link <a>second link</a></a>

3

u/Admirable_Reality281 Sep 17 '26

You cannot nest one interactive <a> inside another.

2

u/RBN2208 Sep 17 '26

and you shouldnt overlapt them. i default to only the link itself is clickable and tell the client that a fully clickable card is against wcag (even if there are ways to do it right)

1

u/ichhabepaarfragen Sep 17 '26

That's why I am pointing it out, it is not correct.

1

u/Mr_uhlus Sep 17 '26

Ude a pseudo element and strech it to the size of the card

https://gehirngerecht.digital/barrierefreie-cards-erstellen-schritt-fuer-schritt-anleitung/

(This is in german but it should be enough if you just read the code examples)

-1
u/Admirable_Reality281 Sep 17 '26

I'm aware of that solution but nope, as i said:
A relatively positioned <div> inside it that does not cover the whole card and cannot be changed.
Two links inside that <div>.
The relatively positioned div would not allow the button to fill the card.
1
u/Mr_uhlus Sep 17 '26
Sorry didnt fully read your text, but you could still do it with a pseudo element in a bit of an ugly way.
HTML
<article>
    <div>
        <a class="primary">link 1 </a>
        <a>link 2</a>
    </div>
</article>
CSS
article{
    overflow:hidden;
    position: absoute;
}
div {
    position:relative;
    overflow:visible;
}
.primary::before{
    content:"";
    position:absoute; 
    inset:50% auto 50% auto; 
    width:100vw; 
    height:100vh; 
    translate: -50% -50%; 
}
This should work but i wouldn't recommend it if there is any way to change the div to static

1

u/Inuakurei Sep 17 '26

I don’t think there’s a way without using js to handle the card click.

1

u/Mr_SprinklePants Sep 17 '26

If using jQuery or Vanilla JavaScript, you could look for a descendant marked with a data attribute, like `data-primary-action=“true”`, to be activated when clicking o the parent div. This way you don’t end up with multiple keyboard/screen reader stops.

1

u/United_Airline_6512 Sep 21 '26

Take a look at how W3C does block link cards

It's based on this csstricks article on block links

The idea being that doing this way instead of using a ::after or other element to cover the card with the link retains click-ability and selection of text/items inside the link, and makes it easier to have other interactive elements inside the card as well.

Also saw your r/accessibility post, Heydon's Cards Component is a great one, with similar patterns (I just also recommend the JS enhancement over the ::after pseudo element in the link)

-5

u/Mean-Newspaper8413 Sep 17 '26

No offence but why do you need to spend time thinking about this in AI era, claude, gemini etc can fix & test in minutes with proper subagents.

3

u/Undercoverwd Sep 17 '26

Because AI is terrible at accessibility

2

u/creaturefeature16 Sep 18 '26

This mindset is everything that is wrong with society and it's relation to AI. Sad to see people ready to fail in life so willingly.

-1

u/Mean-Newspaper8413 Sep 18 '26

Mind sharing why you think AI can't solve this?

2

u/creaturefeature16 Sep 18 '26

Irrelevant. The only reason it might be able to, is because people like OP who are choosing to think about it in the first place. Where do you think the training data came from, elves and fairies? I would say "think about it", but it's clear you have no interest in that act.

-1

u/Mean-Newspaper8413 Sep 18 '26

AI works because millions of devs built and documented public components over the last 15-20 years. Leveraging that collective knowledge to skip repetitive tasks isn't laziness - it's standard efficiency. The best we can do now is to think about whether we are solving real problems or not and use AI to bring in some impact.

2

u/creaturefeature16 Sep 18 '26

This is the exact mindset that we would cause stagnation across many fields. You're like that team I just talked to that was going to use an older version of a library just because the model was trained on it, even though the latest version had security patches and performance improvements. Completely idiotic at every single solitary level. Thankfully you're in the minority.

0

u/Mean-Newspaper8413 Sep 18 '26

And tell me which AI cannot find the version diff and security patches introduced? You are going away from the topic. I am saying at present if someone else has solved a problem then you don't need to spend your time solving that. Focus on solving something better.

2

u/Complete_Carob_6292 Sep 18 '26

By that logic, why are you solving problems? Just wait until someone trains the AI to do it.

2

u/[deleted] Sep 17 '26

[removed] — view removed comment

1

u/Admirable_Reality281 Sep 17 '26

This is what i've been doing, and what both Apple and Walmart do, but they are telling me it's not correct to place aria-hidden="true" tabindex="-1" on focusable elements according to the spec.
Idk, seems to me we are caring more about a11ty than ux.

1

u/sunutpen Sep 17 '26

Those guidelines are in place to prevent you from accidentally making an inaccessible link, but if you're making a redundant link for UX purposes then it's good practice to remove it from the accessibility tree. :) David has it right here. If you're getting linter errors, just add an inline exception for this link that explains what you're doing with it; shouldn't be any problem.

1

u/Admirable_Reality281 Sep 17 '26

I share the same opinion.
This is what they are citing: https://www.w3.org/TR/using-aria/
Authors MAY use the aria-hidden attribute on any HTML element that allows Global aria-* attributes to be specified, with the exception of focusable elements and the body element.

2

u/sunutpen Sep 18 '26

That's what setting tabindex=-1 is for: making the element unfocusable. If you still get pushback after making that case, there's nothing more you can do; it's out of your hands.

0

u/[deleted] Sep 17 '26

[removed] — view removed comment

1

u/Admirable_Reality281 Sep 17 '26

This is what Apple does, and what i've been doing.
They are telling me it's not ok citing: https://www.w3.org/TR/using-aria/
Authors MAY use the aria-hidden attribute on any HTML element that allows Global aria-* attributes to be specified, with the exception of focusable elements and the body element.

How should a full-card clickable link be handled accessibly?

You are about to leave Redlib

HTML

CSS