W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Target size alternative

From: Repsher, Stephen J <stephen.j.repsher@boeing.com>
Date: Tue, 23 May 2017 13:29:02 +0000
To: WCAG <w3c-wai-gl@w3.org>
Message-ID: <862248eeecc74e469b76ef28fcd9cb35@XCH15-08-08.nw.nos.boeing.com>
I mentioned a possible alternative to addressing target size at the very end of last week's call, and posted a it to GitHub.  Since there wasn't much chatter there, I figured I'd send here before the conversation continues today...

See https://github.com/w3c/wcag21/issues/60#issuecomment-302892134

Giving my proposal a bit more thought, maybe a criterion like this would work (using the WCAG 2.0 definition of "label"):

Each target includes any associated heading or label which does not serve more than one target, and the full extent of any container(s) for which it is the only element.

And then maybe redefine target in the glossary simply to (utilizing the existing definition for user interface component):

target: the physical area of a user interface component that accepts a click or touch for activation

I think this would certainly make a lot of unnecessarily small targets across the web much bigger, yet it inherently excludes any links within blocks of text and other points of contention. The exception for "more than one target" is meant to handle situations such as tables where multiple controls may reference a single label using  aria-labeledby  or similar technique.

Patrick rightfully points out that actual physical size requirements may not be met, but since that's what is holding this back and watering it down with so many exceptions, this might be a way to avoid it.  He also pointed out that UAs create the clickable label when associated programmatically with <label>, so it would need to be cleared up in Understanding that behavior can be relied upon to meet this.

Steve
Received on Tuesday, 23 May 2017 13:29:45 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:13 UTC