Re: Target size alternative

I like Steves idea also. I prefer the notion of targets being a larger relative size, depending on the view. 
InterAccess - Accessible UX
-------- Original message --------From: Gregg C Vanderheiden <> Date: 24/05/2017  03:18  (GMT+00:00) To: David MacDonald <> Cc: "Repsher, Stephen J" <>, Jason J White <>, "w3c-waI-gl@w3. org" <> Subject: Re: Target size alternative 
this is a good idea
I don’t think it addresses any of the issues raised —but it is good advice where it can be applied

Gregg C

On May 23, 2017, at 1:12 PM, David MacDonald <> wrote:
Interesting idea, let's keep that in our back pockets if the current one has issues in comments cycle.
David MacDonald CanAdapt Solutions Inc.Tel:  613.235.4902LinkedIn    Adapting the web to all users            Including those with disabilities
If you are not the intended recipient, please review our privacy policy

On Tue, May 23, 2017 at 12:51 PM, Repsher, Stephen J <> wrote:

[Jason] This is interesting. Do you have a good estimate of what proportion of the troublesome cases (those which would be problematic for users) this covers? 
No, unfortunately I do not.  The goal was much less grandiose.  Essentially, I wanted to say that for a given visual presentation of content, make all targets as big as they could be without necessarily having
 to change anything visually.  The entire table cell, tab, accordion header, control+label, etc. should be included in a target. 

From: White, Jason J [] 

Sent: Tuesday, May 23, 2017 10:02 AM

To: Repsher, Stephen J <>; WCAG <>

Subject: RE: Target size alternative


From: Repsher, Stephen J []

Sent: Tuesday, May 23, 2017 9:29 AM

To: WCAG <>

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.[Jason] This is interesting. Do you have a good estimate of what proportion of the troublesome cases (those which would be problematic for users) this covers? Perhaps I’m naïve, but it seems to me that the very small in-line targets
 that people are trying to exclude would be the worst cases for the users with dexterity issues. I think this entire problem calls for a “user agent” solution.Returning to the original proposal, the difficulty with small targets seems to be that increasing the size without overlapping requires corresponding increases in the size of (or spacing between) the controls, introducing the problem
 of horizontal scrolling as John noted. There have been allegations about other formatting problems that would make the resultant material hard to read. So perhaps a narrow exception to cover just those cases would be in order, rather than a broad exception
 for “in-line” controls and links. 

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender;
 do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.

Received on Wednesday, 24 May 2017 07:55:55 UTC