Re: Spacing Between Touch Targets

This made it worse for me.  The first definition limits the number of 
targets in the space to one.  The way I read Detlev's alternative, any 
number of targets could overlap.  I could have a similar sized square, 
circle and octagon on top of or overlapping each other (each intended to 
be a target), and that would pass.

Chuck

On 4/9/2020 7:50 AM, Jonathan Avila wrote:
>
>   * This could hold regardless of whether targets are adjacent or not.
>     There might be value in a definition of spacing that clarifies
>     that spacing is inactive, i.e. does not contain other targets,.
>
> Hi Detlev, yes, having this clarification of what spacing means here 
> is very important for understanding.  I now understand what is meant.
>
> Jonathan
>
> *From:* Detlev Fischer <detlev.fischer@testkreis.de>
> *Sent:* Thursday, April 9, 2020 5:58 AM
> *To:* w3c-wai-gl@w3.org
> *Subject:* Re: Spacing Between Touch Targets
>
> *CAUTION:*This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender 
> and know the content is safe.
>
> Wilco has suggested this rewording:
>
> "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:"
>
> 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.
>
> How about:
>
> "The dimension of the area of a target and any spacing around it is at 
> least 44px height and 44 width except when:"
>
> This could hold regardless of whether targets are adjacent or not.
> There might be value in a definition of spacing that clarifies that 
> spacing is inactive, i.e. does not contain other targets,.
>
> Best,
> Detlev
>
> Am 09.04.2020 um 11:39 schrieb Wilco Fiers:
>
>     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 <mailto: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
>
>
>
> -- 
> Detlev Fischer
> Testkreis
> Werderstr. 34, 20144 Hamburg
> Mobil +49 (0)157 57 57 57 45
> http://www.testkreis.de  <https://urldefense.com/v3/__http://www.testkreis.de__;!!GqivPVa7Brio!JVJFmKGON-J-s8NDjOrZRM1rcRiXG7cNlLY_WNaZHzfJYvSaXpJ-WTf1RItd04SHrw$>
> Beratung, Tests und Schulungen für barrierefreie Websites