Re: New Thread: Changes to Target Size for Issue 631

Hi Steve and John,

I really appreciate both of your thoughtful contributions to this.
So if I'm reading this right - the safest way to avoid the kind of area 
based loophole that is being pointed out is to mandate 44x44px size as a 
minimum requirement. So this is double edged as we know from concerns 
raised against this that we will get pushback from many as to how we got 
this number. Having said that Steves assertions below do help make a 
solid case for why this is a good idea *but* IMO we cannot mandate them 
without solid exceptions due to issues with inline links and menu items 
etc. Unless it was possible to square the circle with exceptions for 
these types.

I'm was also wondering yesterday on the call about Johns idea of 
orientation/axis, if 44px as a diagonal would be useful. in *some* 
situations - even given Steves concerns?

Thanks all!

Josh



Repsher, Stephen J wrote:
>
> Hi John,
>
> I don’t think I’m missing anything at all.  I think I’m combining a 
> basic knowledge of how touch screens work with simple geometric 
> comparisons to say that this current draft put out for CFC makes 
> little to no sense.  And yes, that knowledge really needs to start 
> with the assertion that of course the clickable area is going to be a 
> big factor.  As the area goes up, so does a user’s probability of 
> hitting it within a given number of tries.
>
> I should stop here to say that trend is obviously not going to hole if 
> we’re considering concave shapes for targets.  I hope you weren’t 
> misconstruing that I was saying the SC should specify an area rather 
> than linear dimensions, because I agree specifying an area alone 
> leaves open that giant loophole.
>
> Furthermore, not only is the SC failing to acknowledge that basic 
> trend, but it is asserting there is a usability or accessibility 
> difference between a 44px line aligned horizontally or vertically 
> (which passes) vs. rotated somewhere in between (which fails).  And 
> that’s a ridiculous assertion. Because my finger or stylus really 
> doesn’t care how it is oriented.
>
> I’ll save you the time, resources, and mustering up the desire to do 
> the geometry and do it here.  If we restrict ourselves to convex 
> polygons, it can be proven mathematically that the area will be 
> maximized when the polygon is “regular”, i.e. all sides have equal 
> length and each vertex lies on a circle.  The diameter of that circle 
> is then the maximum chord, or diagonal, of the polygon.  So, after 
> drawing a few with more and more sides, you’ll realize that the 
> maximum area you could ever hope for is that of the circle itself, 
> i.e. a polygon with infinite number of sides.
>
> That is an important fact because it means that unless we require a 
> target size as a regular polygon or circle, such as a 44 x 44 pixel 
> square, then there will always be targets that will fail even though 
> they have more clickable area for the same maximum chord.  The more 
> difference between X and Y in an X by Y pixel criterion, the more 
> nonsensical it becomes.
>
> Steve
>
> *From:*John Foliot [mailto:john.foliot@deque.com]
> *Sent:* Wednesday, January 10, 2018 5:31 PM
> *To:* Repsher, Stephen J <stephen.j.repsher@boeing.com>; WCAG 
> <w3c-wai-gl@w3.org>
> *Subject:* New Thread: Changes to Target Size for Issue 631
>
> Hi Steve,
>
> I think you are missing an important aspect: it isn't about total 
> "square footage", but rather that the clickable target is at least 44 
> CSS px along one axis of either height or width. Given time, resources 
> and a desire to do so, I'm sure I could come up with a polygon of more 
> than 5(+/-) different faces, with an even greater total mass than your 
> strawman, and yet still design it so that it would still be difficult 
> for some users to focus and click on if the clickable regions was 
> indeed a polygon shape (but in browsers that isn't true, with the 
> exception of client-side image maps and/or SVG content).
>
> I think you are correct, we need to remain focused on "boxes" (i.e. 
> the browser box model), and the key is that one of the planes of that 
> "box" needs to meet a minimum length, whilst it's companion axis 
> should be a measurable value (my proposed 'default font height', which 
> is close enough in my humble opinion).
>
> JF
>
> On Wed, Jan 10, 2018 at 4:09 PM, Repsher, Stephen J 
> <stephen.j.repsher@boeing.com <mailto:stephen.j.repsher@boeing.com>> 
> wrote:
>
>     -1
>
>     I’m all for compromise, but this CFC has landed on math that is
>     completely illogical and I cannot live with it.
>
>     The impetus was that most targets would likely have a height of at
>     least the default text size of 16px (which I completely disagree
>     with but let’s run with it).  So we’re saying that a pass is given
>     to a target with dimensions of 44 x 16px, which has a target area
>     of 704 square pixels and a maximum length along the diagonal of
>     about 47px.
>
>     However, a target with dimensions of 34 x 34px would fail even
>     though it has 64% more area for the user to hit (1,156 square
>     pixels) and a slightly longer diagonal of over 48px.  Asking
>     anyone to swallow such an illogical criterion does not make any
>     sense and certainly shouldn’t be in a candidate W3C recommendation.
>
>     The only way this is going to work is to go back to a square
>     target area that we can defend, and come up with exceptions that
>     everyone can live with.
>
>     Steve
>
> -- 
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Deque Systems Inc.
>
> john.foliot@deque.com <mailto:john.foliot@deque.com>
>
> Advancing the mission of digital accessibility and inclusion
>

-- 
Joshue O Connor
Director | InterAccess.ie