Re: Spacing Between Touch Targets

Hey folks,

> Comment from Alastair
> With two horizontally adjacent targets the vertical spacing is
irrelevant. The vertical spacing is not zero, it is infinate. (Obviously
there could be other targets in the vertical direction, so that is why it
needs both.)

The way I'd do this is to find the two closest horizontal edges, compute
the distance between them and add them to the height. If there is overlap
between the edges, subtract the amount of overlap from the height. That's
how I come to 0 height for elements that are horizontally aligned.

If I understand what you're saying correctly, what it sounds like you do is
you draw a horizontal line from one target, and because it never touches
the second conclude its vertical space is infinite, correct?

I don't see how the current wording allows for that reading, so regardless
it would have to be updated. The issue with that is it means targets that
are positioned diagonally would always pass, since there is no horizontal
or vertical line you can draw that go through both targets.

> Detlev suggested:
> "The dimension of the area of a target and any spacing around it is at
least 44px height and 44 width except when:"

This still gets tricky with nested targets. A 64x64 target with at the
center a 44x44 target would still satisfy this. The height and width of the
64x64 would be enough, even if the actual space to touch the thing is never
more than 10px. (assuming there is no space around the outer target).

> This is technically precise but is missing the critical term spacing from
the SC (draft) name. I also think this wording is quite hard to parse.

If that word is critical, I think this can be worked into my suggestion, or
added in as a note. Same for Alastair's comment on 44 by 44, that can be
rephrased. Here's another attempt:

```
For each target, there is an area with a width and height of at least 44
CSS pixels that includes it, and no other targets, except when:

**note**: The area may include both the target, and the space between
targets.
```


Wilco

On Fri, Apr 10, 2020 at 12:49 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Based on the start of the SC text:
> “Adjacent targets, combined with spacing between targets, have a minimum
> height and minimum width of at least 44 CSS pixels each except when:”
>
> Wilco wrote:
>
> >  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.
>
> With two horizontally adjacent targets the vertical spacing is irrelevant.
> The vertical spacing is not zero, it is infinate. (Obviously there could be
> other targets in the vertical direction, so that is why it needs both.)
>
> I wonder if the reference to “adjacent” triggered that interpretation?
>
> Wilco suggested using an approach of exclusion to other targets:
>
> > “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:”
>
> I don’t think we need “of the display”, and saying 44 x 44px means you can
> interpret it as 1,936px, which could mean 5px by 385, which is not the
> intent.
>
> Detlev suggested incorporating dimension/area:
>
> > “The dimension of the area of a target and any spacing around it is at
> least 44px height and 44 width except when:”
>
> I think we should rely on the concept of ‘target’, i.e. the
> clickable/tapable area. With that in place, if a target has
> height/width+spacing, that is the same as area/dimension.
>
>
>
> Trying to synthesise, I tried:
>
> “Target size, including spacing between adjacent targets, is at least 44
> CSS pixels horizontally and 44 CSS pixels vertically except when:”
>
>
>
> Does that help?
>
>
>
> -Alastair
>
>
>
> BTW, PR created for the potential target definition errata.
>


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

Received on Tuesday, 14 April 2020 10:52:58 UTC