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

All,

It feels like we've gone around and around on this one. To Steve's points,
while it is true that from a physical & mechanical perspective, the 'angle'
that we measure across the clickable target could be measured at O degrees,
90 degrees, 45 degrees, (or 23, 78, or 25 degrees), and it is true, the
device doesn't care. But testers do.

Unless you can explain how to physically (or mechanically) test these
variants (and Steve has argued that a square at roughly 33 CSS px [sic]
square would give you a 45* lateral measurement that would be or exceed 44
px), you are left with measuring using the mechanics available to us in the
browser - the box model. Which brings us back to needing at least one axis
at a defined and measurable unit value (be that 44 or 48 px), and the
other... well, that seems to be where we are hung up.

Asking for 44 px square, with a War and Peace list of exemptions, will
render this SC somewhat pointless (as well as add complexity to the testing
process). As others have pointed out, only asking for one dimension to be
at or greater than 44px also leaves open some legitimate concern (I was
very luke-warm on that proposal, but was in a generous "I can live with it"
mood). But it appears others are sharing the same concerns.

I'm not going to live or die on this hill, I will defer to the folks on
MATF as being the subject-matter experts in this area, but I will again
suggest that asking for 44px X default font size (a variable number) will
get us pretty darned close to meeting the need, and I am of the personal
belief that visual designers will groc the intent here (and we can help
teach them), and we'll be 'fine'.

At the end of the day, if a designer/developer really wants to play around
with this (aka "abuse" this), there is very little we can do. While our
normative requirements are often also entrenched in law, we at the W3C
cannot be responsible for enforcement... we bring forth the best we can,
and then hope that through education and precedent establish a corpus of
"successful" examples, that others can learn from.

I think it would be a shame to drop this SC at this late date, but as I
noted, I am quite happy to defer to the expertise of those members who are
part of the MATF.

Peace out.

JF




On Thu, Jan 11, 2018 at 3:24 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> > IMO we cannot mandate [44x44] 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.
>
>
>
> The current issue seems to be squaring:
>
>
>
>    - The user need for 44x44 links (at least, preferably 100x100 or more
>    from the research).
>    - Getting push back from making most text links fail, which puts focus
>    on exceptions and rational.
>
>
>
> I agree with Steve (and Pat, and Kathy) that where we’ve ended up doesn’t
> meet the user need, and also it is overly complex.
>
>
>
> The best rational for the text-link exception is basically “because that’s
> what links are on the web”. Is that ever going to be good enough? Or will
> we keep circling around it? I’ve tried to present pixel values based on
> default font-size, it doesn’t seem to get traction.
>
>
>
> I think Alex had a good point about spacing between links being an
> important factor that we haven’t accounted for. My personal site (
> alastairc.ac) at small widths makes a good case study:
>
>    - The three buttons at the top are about 110px x 44px (accidentally)
>    - The text-links in lists underneath are 21px tall, with plenty of
>    space between them.
>
>
>
> On a touch screen, *you can tap between the links and the device guesses
> which one you meant*, it is as-though they are larger links without
> needing to change their actual size.
>
>
>
> We are complexly missing this factor at the moment, putting more burden on
> authors than necessary, and at the same time not meeting the user-need!
>
>
>
> Overall, I’m inclined to leave the AA version of this for the next
> iteration, let’s work in the spacing factor for next time.
>
>
>
> -Alastair
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion