RE: Patterns for to address requests for 'wider clickable area'

We come across this quite often and it can work well if it is implemented carefully. I recommend the following:


  1.  There must still be some sort of link or button to indicate that the area is clickable. In UX terminology, there’s got to be an “affordance”. Leaving aside WCAG conformance, there are at least two practical reasons:

     *   Screen magnifier users may easily fail to notice any instructions you provide that say the whole row is clickable. Even if the area’s style changes on hover and focus, they won’t necessarily know this means the area is clickable.

     *   Voice recognition software users need to know what keyword to use to operate the links. In fact, they won’t even know the areas are clickable because they do not see the hover or focus states. User testing shows that only a proportion of people read the instructions.

  2.  The clickable area must have a visible boundary. It’s really confusing if the cursor changes from a pointer to a hand or no apparent reason in an empty area of the page.

  3.  The styling of the clickable area must change on hover and focus. For WCAG conformance, it would be sufficient to just change the outline style. However, screen magnifier users may not see such a change depending on the size and shape of the area, so I advocate changing the background colour too.

You mention “Groups of information wrapped in focusable, clickable block-level elements”. You wouldn’t usually design it that way. The group of information would contain a link or button, typically at the end. There would be hover, click and touch event handlers on the container that have the same behaviour as the link or button, but it would not be in the focus order and would not be exposed to assistive technologies. We have implemented this many times and it works really well with assistive technologies.

Steve Green
Managing Director
Test Partners Ltd


From: John Coburn <fatal.agent@gmail.com>
Sent: 28 May 2020 20:49
To: w3c-wai-ig@w3.org
Subject: 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