Patterns for to address requests for 'wider clickable area'

--000000000000730e3505a6ba9ea8
Content-Type: text/plain; charset="UTF-8"

Recently I've been seeing more requests and designs for "larger clickable
areas"  Contrived example: say there's an 'export' table of data items with
columns for each attribute and an actions column containing a single
"export" button - a per-item action - the design request would ask for the
entire row of the table to be clickable so they can presumably remove the
per-item button and save the column of real-estate.

The somewhat wreckless "designer" half of me can't deny the improvement to
the "feel" of larger hit areas once I learn about it - but the a11y-minded
developer half asks 'how can we label this appropriately or set up the
expectations for that behavior with the assistive tech user ? How can we
keep from potentially hiding any of that important data within?

Sometimes the layout of data is non-tabular (but could be) where the list
items themselves are comprised of key/value pairs and attributes of the
data item - way more text than a simple per-item 'export' button or
anything like that. Groups of information wrapped in focusable, clickable
block-level elements - it just seems cringe-worthy when I imagine
screen-reader navigation, but perhaps that's just a frivolous worry.

Are there any go-to patterns/practices/guidelines anywhere for handling
this sort of thing? Or is the answer something terribly obvious? (Caption
text or some visible instructional comes to mind) I'm aware of
markup/syntax that could possibly *make it work - but much of that hardly
seems like 'best' practice - any help/advice appreciated. Thanks in advance!

Apologies for a lengthy message.
John Coburn

--000000000000730e3505a6ba9ea8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Recently I&#39;ve been seeing more requests and designs fo=
r &quot;larger clickable areas&quot;=C2=A0 Contrived example: say there&#39=
;s an &#39;export&#39; table of data items with columns for each attribute =
and an actions column containing a single &quot;export&quot; button - a per=
-item action - the design request would ask for the entire row of the table=
 to be clickable so they can presumably remove the per-item button and save=
 the column of real-estate.<br><br>The somewhat wreckless &quot;designer&qu=
ot; half of me can&#39;t deny the improvement to the &quot;feel&quot; of la=
rger hit areas once I learn about it - but the a11y-minded developer half a=
sks &#39;how can we label this appropriately or set up the expectations for=
 that behavior with the assistive tech user ? How can we keep=C2=A0from pot=
entially hiding any of that important data within?<br><br>Sometimes the lay=
out of data is non-tabular (but could be) where the list items themselves a=
re comprised of key/value pairs and attributes of the data item - way more =
text than a simple per-item &#39;export&#39; button or anything like that. =
Groups of information wrapped in focusable, clickable block-level elements =
- it just seems cringe-worthy when I imagine screen-reader navigation, but =
perhaps that&#39;s just a frivolous worry.<div><br></div><div>Are there any=
 go-to patterns/practices/guidelines anywhere for handling this sort of thi=
ng? Or is the answer something terribly obvious? (Caption text or some visi=
ble instructional comes to mind) I&#39;m aware of markup/syntax that could =
possibly *make it work - but much of that hardly seems like &#39;best&#39; =
practice - any help/advice appreciated. Thanks in advance!<br><br>Apologies=
 for a lengthy message.<br>John Coburn</div></div>

--000000000000730e3505a6ba9ea8--