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

Thanks for the stellar guidance, Steve!

On Fri, May 29, 2020 at 5:28 PM Steve Green <steve.green@testpartners.co.uk>
wrote:

> 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:
>
>    1. 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.
>
>       2. 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
>