Re: Spacing Between Touch Targets

Hey Alastair,

> Still, if it helps avoid confusion, we very much want to keep backwards
compatibility (with the intent). We could create an errata, my proposal for
that would be:

> “region of the display that will accept a pointer action* to trigger a
function,*”.


I think that would be much better, yes.


> *Alternative 1:*

> Targets with an adjacent target have a minimum height of at least 44 CSS
pixels including spacing, and a minimum width of 44 CSS pixels including
spacing, except when:
>

> To me that says the same thing, but perhaps that’s makes a difference in
reading?


That reads the same to me as the current one. The issue is that if two
elements are on the same x-axis, there is no space between them on the
y-axis. To me, that means the vertical space is 0, and if the elements have
a height of 33px, they both fail, regardless of how much horizontal space
is between them. Again, I get that that's not the intent, but that's what I
read here.

I think the way this should be phrased is like this:

For each target, there is an area of the display of 44 by 44 CSS pixels
that includes it, and no other targets, except when:


W



On Tue, Apr 7, 2020 at 5:42 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Wilco,
>
>
>
> Sorry for the delay, even on lockdown having a holiday it is quite tricky
> to get on email thanks to the kids!
>
>
>
> > “region of the display that will accept a pointer action," -- This is
> the definition
> … The way I read this, an interactive area is an example of a target; but
> this doesn't say that all targets are interactive areas. The part that I
> see as defining "target" does not say anything needs to happen in response
> to a pointer action.
>
>
>
> To me, “accept a pointer action” means it does something with it.
>
>
>
> Of course anywhere on the screen can be clicked/tapped, but if nothing is
> done with it (the “accept”), then it is not relevant.
>
>
>
> Still, if it helps avoid confusion, we very much want to keep backwards
> compatibility (with the intent). We could create an errata, my proposal for
> that would be:
>
> “region of the display that will accept a pointer action* to trigger a
> function,*”.
>
>
>
>
>
> > What I'm suggesting is that the way the SC is intended to read isn't the
> only way this can be read; I tried, and I don't see how the intended
> reading can be understood from the language of the proposed SC.
>
> If it is any consolation I’ve tried reading it another way, and I’ve not
> managed to yet.
>
>
>
>
>
> > there just needs to be some space of 44x44 around the target that
> doesn't include any other targets. Is that right?
>
>
>
> It is the combined size + space that needs to be 44px. How about I try a
> variation to see if that makes a difference?
>
>
>
> *Current:*
>
> Adjacent targets, combined with spacing between targets, have a minimum
> height and minimum width of at least 44 CSS pixels each except when:
>
>
>
> *Alternative 1:*
>
> Targets with an adjacent target have a minimum height of at least 44 CSS
> pixels including spacing, and a minimum width of 44 CSS pixels including
> spacing, except when:
>
>
>
> To me that says the same thing, but perhaps that’s makes a difference in
> reading?
>
>
>
>
>
> > I'd still much prefer this be written in terms of a circle with a 44px
> diameter, and not as a square. Fingertips aren't square after all
>
>
>
> We have discussed that, but it leads to odd results when you have large &
> small targets next to each other.
>
> Also, if the circles are 44px wide the measure of (effectively) bounding
> boxes around a circle should still work. I’m not sure it works effectively
> the other way around (always using a circle to test what is mostly
> rectangles).
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>


-- 
*Wilco Fiers*
Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R