Andy covers a technique where a semantic <button> is used within a card component, but really, the whole card is clickable. The trick is to put a pseudo-element that goes beyond the button, covering the entire card. The tradeoff is that the pseudo-element sits on top of the text, so text selection is hampered a bit. I believe this is better than making the whole dang area a <button> because that would sacrifice semantics and likely cause extreme weirdness for assistive technology.
See the Pen
Semantic, progressively enhanced “break-out” button by Andy Bell (@andybelldesign)
on CodePen.
You could do the same thing if your situation requires an <a> link instead of a <button>, but if that’s the case, you actually can wrap the whole area in the link without much grief then wrap the part that appears to be a button in a span or something to make it look like a button.
This reminds me of the nested link problem: a large linked block that contains other different linked areas in it. Definitely can’t nest anchor links. Sara Soueidan had the best answer where the “covering” link is placed within the card and absolutely positioned to cover the area while other links inside could be be layered on top with z-index.
I’ve moved her solution to a Pen for reference:
See the Pen
Nested Links Solution by Chris Coyier (@chriscoyier)
on CodePen.
Note there was a bug in Firefox where positioned children would not delegate clicks:
https://bugzilla.mozilla.org/show_bug.cgi?id=562499
This bug was only relatively recently fixed and may not be fully rolled out.
This is a neat trick, but I think it is not great accessibly for a couple of reasons: it breaks user expectation in that it appears the button is the interactive element, but surprise, click somewhere else on the div aimlessly and something happens you weren’t expecting. Secondly, in a similar pattern I tested, NVDA did not read out the link text (it was a link rather than a button), I’m not sure if this is related to the non-selectable text issue. Anyone using this technique should be careful to test it in screen readers. I’d be interested to see the results of more thorough testing, but the (to me) misleading interface puts me off using this.
This option provides simplicity and convenience to the user, which is a very good thing
But then you disallow the user from highlighting text for copying, isn’t that an issue in itself?
I can’t remember where I originally found this workaround, but nesting links inside of links can work if the nested link is wrapped in an
<object>So, without saying whether it’s a good idea or not, the following does work for links inside of links.
I hate when people do this — if I need to copy and paste something out of the tile it becomes a huge PITA.
I always considered the “fake button inside a clickable card” pattern to be a poor one because it provides an unexpected behavior. If something looks like a button, or like a not-button, it should behave as such. There are existing patterns for clickable cards that provide better usability, such as omitting the button wrapper on the CTA and adding an arrow or ellipsis to the end. We should be designing our interfaces to behave predictably, rather than enforcing obscuration via patterns like this.
I’m not sure why you would want to do this.
If the article is a label then the whole box is clickable for the button.