Patterns for to address requests for 'wider clickable area'

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

Received on Friday, 29 May 2020 17:46:06 UTC