Re: Target size

Hey folks,
I automated this SC for axe-core a couple months back and have been testing
it out in different environments. By far the most common issue I see come
up is from link stacks. Table of content, sidebar navigation, links lists
in the footer, that kind of stuff.

Most sites I looked at meet the 24px target. I don't think WCAG 2.2 is
pushing the boundary beyond what is already standard practice. But then
there are a good number of sites that have issues, including the footer on
the W3C website that don't meet this minimum. I think it's really a good
thing that we draw a line in the sand here that says "to there and no
further". Honestly, 24 pixels seems pretty good to me. Obviously larger
tends to be better. The same is true for many things in accessibility. But
we need to set a minimum IMO.

We have some loose ends to tie, but these don't look like deal-breakers to
me.

On Wed, Dec 7, 2022 at 6:42 PM Gregg Vanderheiden <gregg@vanderheiden.us>
wrote:

> Boy Alastair  — that is a good question.
>
> As others point out - there are places where this is a real problem.
>  But it is not clear that we have found a solution to it - that doesnt
> cause other problems - or is not applicable in other situations.   So we
> are stuck between a rock and a hard place  (not unusual for WCAG WG).
>
> Sometime we have been able to negotiate this with a conditional (only
> applied here)  or with exceptions (doesnt apply here -only )
>
>    - Using conditionals risks missing things if it is a list — but works
>    if it the conditions focus on the problem itself
>    - using exceptions is dangerous because you never think of all the
>    places this should not apply
>
>
> For this one — my mind keep reeling.   It combines important with
> collisions where it should not or can not be applied.
>
> No doubt there is a problem
> But I don’t think we have the wording yet to make a solution fly
>
> Maybe - we find out the most egregious places and make a conditional that
> focuses on them?  (Though I can’t think of how to do this either)
>
> Hmmmmm    continuing to ponder
>
>
> gregg
>
> ------------------------------
> Gregg Vanderheiden
> gregg@vanderheiden.us
>
>
>
> On Dec 7, 2022, at 2:48 AM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> Hi folks,
>
> I may be having a moment of (self) doubt on target size, trying to work
> through the various issues and possibilities on the spacing and inline
> exceptions.
>
> As mentioned in the survey, some people in the group (including people
> from the mobile TF) are concerned about the effectiveness of the SC. I want
> to check if the effort to resolve the remaining issues is worthwhile, or
> I’m falling into the sunk-cost fallacy
> <https://www.behavioraleconomics.com/resources/mini-encyclopedia-of-be/sunk-cost-fallacy/>
> .
>
> On the positive side:
>
>    - Everyone knows small targets are problematic, and much more so for
>    people with mobility impairments.
>    - We have done considerable honing of the SC.
>
>
> On the negative side:
>
>    - When you look around at most sites, particularly those which have
>    put effort into the display on mobile devices, they tend to easily pass the
>    SC.
>    - Most things which are under 24px seem to fall into one of the
>    exceptions anyway, either with spacing or being in text.
>    - The most common fails I can find are on adverts (e.g. close
>    buttons), and those ads also fail several other SCs already for other
>    reasons. (I.e. they are unlikely to meet this SC either.)
>    - Depending on the definition of “inline” we use, it will either
>    provide quite a sweeping exception, or a relatively narrow one and capture
>    a lot of (arguable) ok targets. It will also have a lot of potential for
>    arguments.
>    - Whichever definition of spacing we use will have some odd effects,
>    either how to test it, or what passes.
>    - Other SCs like text-spacing and reflow provide methods for
>    increasing the size of targets in some circumstances.
>
>
> A lot of the problems this SC faces are inherent in the web, where the
> same site is provided to small touch screens and larger screens with a
> mouse/trackpad. Someone with low-vision and zoomed-in may not want larger
> targets in the toolbar for an editor. But it’s the same interface as
> someone with good vision and tremors.
>
> If we could have a guideline that said “targets should be >44px unless
> there’s a good reason not to”, it would be fine. But in a binary pass/fail
> scenario that could become a legal requirement…
>
> Am I off base? Can anyone talk me down?
>
> Kind regards,
>
> -Alastair
>
> --
>
>
> @alastc / www.nomensa.com
>
>
>

-- 
*Wilco Fiers*
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator
ACT Task Force