For a card whose whole surface opens a details page but which also holds a Save button, how should the click target and nested action work?
answer
- one real link, not a wrapper
- name from content gets too long
- controls inside controls
- enlarge the title's hit area
- secondary actions sit above it
basics
~20 sMake the title the card's one real link and extend its clickable area over the card, with the Save button layered above as a separate control. Never wrap the whole card, including the button, in one link or button.
solid answer
~50 sUsers expect to click anywhere on a card, but wrapping the whole card in a single link or button breaks things. A link or button gets its accessible name from its content, so the whole card's text becomes one very long name, and a control nested inside another control is either invalid in web markup or, inside a button, treated as plain content by WAI-ARIA — so the Save button effectively disappears for assistive technology. The robust pattern is: the **title is the one real link**, named by the title alone; its **clickable area is visually extended** to cover the card for pointer users; the **Save** button sits **above** that area as its own control with its own name, like 'Save CS 201'. Keyboard users get two stops — title, then Save — and the card shows a focus indicator when its link is focused.
go deeper
Recall the rule: one real link per card, usually the title, and nested actions as separate buttons rather than inside the link.
Explain why wrapping fails — names computed from all content, nested controls not exposed, double actions — and how an extended title hit area solves it.
Diagnose a card grid screen-reader users call noisy or broken, fix names and nesting, and settle the text-selection and mis-tap trade-offs in the spec.
Make the clickable-card pattern a single system component, so no team rebuilds the whole-card wrapper and reintroduces the same accessibility defects.
## The expectation and the trap On a card that represents one item, pointer and touch users expect the whole surface to be clickable: tapping anywhere on a course card in a registration portal should open the course. Designers therefore ask for the whole card to be the target. The obvious implementation — make the entire card one link or one button — creates three problems as soon as the card also carries its own action, such as **Save** or **Add to plan**. ## Why wrapping the whole card fails 1. **The accessible name becomes the whole card.** Links and buttons get their accessible name from their content: the WAI-ARIA Authoring Practices explain that for such elements the name is calculated by walking all descendants and concatenating their text, and that this name is the *only* content the user perceives for the element. A screen-reader user tabbing through a grid hears 'CS 201 Data Structures 4 credits Monday Wednesday 10:00 Dr. Okafor 3 seats left Save Add to plan' for every card — and the guide's naming rules ask for brief, useful names. 2. **Nested controls break.** Web markup rules do not allow interactive content inside a link. In WAI-ARIA 1.2 the **button** role has *children presentational*, meaning anything inside a button is treated as plain content — a Save button inside a card-sized button is not exposed as a control at all. 3. **Clicking Save also opens the card.** Even when it appears to work, a click on the nested button often triggers both actions, so students who meant to save a course are navigated away. A third anti-pattern is making a plain container respond to clicks with script. It then has no role, no focus, and no keyboard access at all. ## The robust pattern | Element | Role in the pattern | |---|---| | **Title** | The card's one real link, named by the title text only | | **Extended hit area** | The title link's clickable area is stretched visually to cover the card, so a click anywhere opens the item | | **Nested actions** | Separate buttons layered *above* the extended area, each with its own name ('Save CS 201') | | **Focus** | Two keyboard stops: title link, then Save; the whole card shows a focus indicator when the link has focus | | **Description** | Metadata stays ordinary text, read in order when the user reads the card | The extended area is a presentation technique: each platform has its own way to enlarge a control's hit region without changing what the control contains. The model is the same everywhere — the name stays short, the actions stay separate. ## Trade-offs to decide in the spec - **Text selection.** A card-wide hit area makes copying the course code awkward. Some systems accept that; others limit the target to title and media so the metadata stays selectable. - **Mis-taps near nested actions.** Nested buttons need enough size and spacing that a tap meant for the card does not land on Save, or the reverse. WCAG 2.2 SC 2.5.8 Target Size (Minimum) is the floor for the buttons themselves. - **Visible affordance.** A hover or pressed state on the whole card tells pointer users the surface is clickable. ## Native platforms On native mobile, a collection cell is typically one tappable element with a primary action, and extra actions are exposed to screen-reader users as a list of named custom actions on the cell, or through swipe actions with an accessible alternative. The same contract holds: one primary action with a short name, secondary actions reachable and separately named. ## Checklist for review - Is there exactly **one** link to the item, named by the title? - Are nested actions **separate controls** with item-specific names? - Does clicking Save **only** save? - Can a keyboard user reach both, in a sensible order, with a visible focus indicator?
- Why give the Save button a name like 'Save CS 201' rather than just 'Save'?In a grid of forty cards, a screen-reader user listing buttons hears forty identical 'Save' entries with no way to tell them apart. Adding the item — visibly or as part of the accessible name — makes each action distinct out of context. The Authoring Practices' naming guidance favours brief names that stay distinct, often by putting the verb first.
- What should happen when a card has no detail page to open?Then it has no primary target and the surface should not be clickable at all. Making a non-navigating card look or act clickable invites clicks that do nothing. Its actions stay as ordinary buttons, and the card is simply a grouped piece of content.
saying these in an interview costs you the question
- Wrap the whole card in one link so the entire surface is clickable
- A button nested inside a card-sized button still works for screen readers
- A long accessible name is fine because it tells users everything
- Making the card container respond to clicks with script is enough
- Every Save button in a grid can simply be named 'Save'