Re: Target size alternative

Interesting idea, let's keep that in our back pockets if the current one
has issues in comments cycle.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Tue, May 23, 2017 at 12:51 PM, Repsher, Stephen J <
stephen.j.repsher@boeing.com> 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.
>
>
>
> Steve
>
>
>
> *From:* White, Jason J [mailto:jjwhite@ets.org]
> *Sent:* Tuesday, May 23, 2017 10:02 AM
> *To:* Repsher, Stephen J <stephen.j.repsher@boeing.com>; WCAG <
> w3c-wai-gl@w3.org>
> *Subject:* RE: Target size alternative
>
>
>
>
>
>
>
> *From:* Repsher, Stephen J [mailto:stephen.j.repsher@boeing.com
> <stephen.j.repsher@boeing.com>]
> *Sent:* Tuesday, May 23, 2017 9:29 AM
> *To:* WCAG <w3c-wai-gl@w3.org>
>
> 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.
> ------------------------------
>