Re: Target spacing refinement

I'm not sure "displacement" is the right word for this SC.

The definitions for "displacement" that I find generally involve movement:
e.g., movement of something from point A to point B or the displacing of an
object by another (as in displacing fluid by a floating body).
https://www.merriam-webster.com/dictionary/displacement

While "distance" can also apply to the movement of an object, it is also
commonly used when measuring the distance between two objects, and is, I
think, more appropriate for this SC.
https://www.merriam-webster.com/dictionary/distance

*Melanie Philipp, CPACC, WAS | *Senior Digital Accessibility Consultant
| 540-848-5220
Deque Systems - Accessibility for Good
www.deque.com

Join me at axe-con <http://deque.com/axe-con> 2021: a free digital
accessibility conference.


On Mon, Nov 23, 2020 at 5:40 AM Wilco Fiers <wilco.fiers@deque.com> wrote:

> Hey folks,
>
> > Nested or Overlapping : If a target overlaps, or is enclosed within
> another target, each target has an area of 24X24 CSS pixels with no other
> targets
>
> This creates various other issues. In my examples (
> https://codepen.io/wilcofiers/pen/abZxPow?), that would cause I2, J2, K1
> and K2 to fail. How about an exception like this:
>
> *- Large: Any target larger than 24 by 24 CSS pixels must instead have an
> area of 24 by 24 CSS pixels within it that has no other targets.*
>
> > So I think we're right back at the core question: idiot-proof outliers,
> or help improve common design conventions?
>
> Well, another way to put that is "do we want false positives and false
> negatives in the success criteria"? I don't think that's something we can
> avoid, we're going to miss things. But I don't think we should publish an
> SC that we know has them.
>
> Wilco
>
> On Mon, Nov 23, 2020 at 6:40 AM Michael Gower <michael.gower@ca.ibm.com>
> wrote:
>
>> Yeah, I realized that gap earlier, but I also have to ask: Is our job to
>> prevent someone from making a truly horrible user experience for everyone,
>> or ensuring that more common designs are more accessible?
>> I was assuming that the nested guideline was there in a situation where a
>> large target had a smaller target inside -- with the intent to make sure
>> the smaller target was operable. I believe you can pass this SC by putting
>> a 24x24 inside a 25x25 target. But who would ever buy-in for designing what
>> amounts to a 1-px stroke target?
>>
>> So I think we're right back at the core question: idiot-proof outliers,
>> or help improve common design conventions?
>>
>> Michael Gower
>> Senior Consultant in Accessibility
>> IBM Design
>>
>>
>> 1803 Douglas Street, Victoria, BC  V8T 5C3
>> gowerm@ca.ibm.com
>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>
>>
>>
>> From:        Wilco Fiers <wilco.fiers@deque.com>
>> To:        Michael Gower <michael.gower@ca.ibm.com>
>> Cc:        Alastair Campbell <acampbell@nomensa.com>, Sukriti Chadha <
>> sukriti1408@gmail.com>, "WCAG list (w3c-wai-gl@w3.org)" <
>> w3c-wai-gl@w3.org>
>> Date:        2020/11/22 11:33 AM
>> Subject:        [EXTERNAL] Re: Target spacing refinement
>> ------------------------------
>>
>>
>>
>> Hey folks, No preference on "displacement". I was looking to...
>>
>>
>>
>> *This Message Is From an External Sender*
>> This message came from outside your organization.
>>
>>
>> Hey folks,
>> No preference on "displacement". I was looking to implement this as an
>> experimental rule in axe-core when I realised this has a gap in it still. I
>> updated my examples: *https://codepen.io/wilcofiers/pen/abZxPow*
>> <https://codepen.io/wilcofiers/pen/abZxPow>
>>
>> The particular example is H4, two elements 24x24 pixels, on top of a
>> 36x60 element. The outer element has a distance of 30px from its farthest
>> point to the closet point of either element, despite the element having
>> very little space available. Any thoughts on how to address this?
>> [image: Screenshot 2020-11-22 at 20.32.11.png]
>>
>> Wilco
>>
>> On Fri, Nov 20, 2020 at 6:28 PM Michael Gower <*michael.gower@ca.ibm.com*
>> <michael.gower@ca.ibm.com>> wrote:
>> I'm actually quite happy with 'displacement'! I could also go with
>> substituting "offset" or another 'synonym'. Does that work better for you,
>> Alastair?. I'm not rejecting "distance", but I think 'displacement' does a
>> better job of conveying that we are talking about how to improve
>> operability, we need to assess the positioning of two objects relative to
>> each other. Here it is in full, to take in how it all shakes out. I changed
>> the title (again). Still not entirely satisfied with that, but the SC text
>> is more important IMO. i also did minor tweaking to Nested.
>>
>> *Distinct Pointer Targets*
>>
>> *The displacement between targets is at least 24 CSS pixels, where the
>> displacement is measured from the farthest point of one target to the
>> nearest point of an adjacent target, except if:*
>>
>>
>>    - *Inline*: The target is in a sentence or block of text;
>>    - *User Agent Contro*l: The size or spacing of targets is determined
>>    by the user agent and is not modified by the author;
>>    - *Nested:* A smaller target is enclosed within another target and
>>    the smaller has a minimum height and width of 24 CSS pixels.
>>    - *Essential*: A particular presentation of the target is essential
>>    to the information being conveyed.
>>
>>
>> I haven't included Wilco's Diameter exception, because I couldn't figure
>> out what it was covering that isn't covered now.
>> Michael Gower
>> Senior Consultant in Accessibility
>> IBM Design
>>
>>
>> 1803 Douglas Street, Victoria, BC  V8T 5C3
>> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com>
>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>
>>
>>
>> From:        Alastair Campbell <*acampbell@nomensa.com*
>> <acampbell@nomensa.com>>
>> To:        Michael Gower <*michael.gower@ca.ibm.com*
>> <michael.gower@ca.ibm.com>>
>> Cc:        Sukriti Chadha <*sukriti1408@gmail.com*
>> <sukriti1408@gmail.com>>, "WCAG list (*w3c-wai-gl@w3.org*
>> <w3c-wai-gl@w3.org>)" <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>, Wilco
>> Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>
>> Date:        2020/11/20 08:46 AM
>> Subject:        [EXTERNAL] RE: Target spacing refinement
>> ------------------------------
>>
>>
>>
>> Displacement doesn’t seem right, but I can’t think of a more
>> appropriate...
>>
>>
>> *This Message Is From an External Sender*
>> This message came from outside your organization.
>>
>> Displacement doesn’t seem right, but I can’t think of a more appropriate
>> term.
>>
>>
>>
>> I’m in two minds about whether it’s an improvement, I tried re-writing it
>> and almost ended up back where it was:
>>
>>
>>
>> *The size and spacing of a target is at least 24 CSS pixels, measured
>> from the nearest point of each adjacent target to the farthest point of the
>> current target, except if:*
>>
>>
>>
>> ?
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> *From:*Michael Gower <*michael.gower@ca.ibm.com*
>> <michael.gower@ca.ibm.com>>
>> *Sent:* 20 November 2020 16:14
>> *To:* Alastair Campbell <*acampbell@nomensa.com* <acampbell@nomensa.com>>
>> *Cc:* Sukriti Chadha <*sukriti1408@gmail.com* <sukriti1408@gmail.com>>;
>> WCAG list (*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>) <*w3c-wai-gl@w3.org*
>> <w3c-wai-gl@w3.org>>; Wilco Fiers <*wilco.fiers@deque.com*
>> <wilco.fiers@deque.com>>
>> *Subject:* RE: Target spacing refinement
>>
>>
>>
>> I hear you, Alastair. How about we consider something like "displacement".
>>
>> 'The displacement between targets is at least 24 CSS pixels, where the
>> displacement is measured between..."
>>
>> In regards to Wilco's 'either direction' I think that is very simply
>> clarified in the Understanding doc.
>>
>> Michael Gower
>> Senior Consultant in Accessibility
>> IBM Design
>>
>>
>> 1803 Douglas Street, Victoria, BC  V8T 5C3
>> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com>
>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>
>>
>>
>> From:        Alastair Campbell <*acampbell@nomensa.com*
>> <acampbell@nomensa.com>>
>> To:        Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>,
>> Michael Gower <*michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>>
>> Cc:        Sukriti Chadha <*sukriti1408@gmail.com*
>> <sukriti1408@gmail.com>>, "WCAG list (*w3c-wai-gl@w3.org*
>> <w3c-wai-gl@w3.org>)" <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>
>> Date:        2020/11/20 02:43 AM
>> Subject:        [EXTERNAL] RE: Target spacing refinement
>> ------------------------------
>>
>>
>>
>>
>> Hi everyone, I find the concept of measuring ‘between targets’...
>>
>>
>>
>>
>> *This Message Is From an External Sender*
>> This message came from outside your organization.
>>
>> Hi everyone,
>>
>>
>>
>> I find the concept of measuring ‘between targets’ and then measuring
>> *through*a target odd, but I might be in a wood-for-the-trees situation.
>> If others find it at least as understandable as the other options, then it
>> works for me.
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> *From:*Wilco Fiers
>>
>>
>>
>> Hey folks,
>>
>> Rereading Mike's suggestion freshly caffeinated. I think this works. The
>> "from either direction" thing I raised is probably sufficiently addressed
>> just because it says "at least 24px", so if it passes measured one way, but
>> not measured the other way there's nothing in the SC text that might lead
>> someone to conclude that is okay.
>>
>>
>>
>> Glad to see we may have a solution!
>>
>>
>>
>> Wilco
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Nov 19, 2020 at 7:47 PM Michael Gower <*michael.gower@ca.ibm.com*
>> <michael.gower@ca.ibm.com>> wrote:
>>
>> Okay, I'm going to remove both of those preambles, rename the SC, and
>> make it a bit wordier. Is this easier to parse?
>>
>> *Adjacent Pointer Targets*
>> *The distance between targets is at least 24 CSS pixels, where the
>> distanced is measured between the farthest point of one target and the
>> nearest point of an adjacent target, except if:*
>>
>>
>> Michael Gower
>> Senior Consultant in Accessibility
>> IBM Design
>>
>>
>> 1803 Douglas Street, Victoria, BC  V8T 5C3
>> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com>
>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>
>>
>>
>> From:        Alastair Campbell <*acampbell@nomensa.com*
>> <acampbell@nomensa.com>>
>> To:        Sukriti Chadha <*sukriti1408@gmail.com*
>> <sukriti1408@gmail.com>>, Wilco Fiers <*wilco.fiers@deque.com*
>> <wilco.fiers@deque.com>>
>> Cc:        Michael Gower <*michael.gower@ca.ibm.com*
>> <michael.gower@ca.ibm.com>>, "WCAG list (*w3c-wai-gl@w3.org*
>> <w3c-wai-gl@w3.org>)" <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>
>> Date:        2020/11/19 09:59 AM
>> Subject:        [EXTERNAL] RE: Target spacing refinement
>> ------------------------------
>>
>>
>>
>>
>> I think it helps to establish the focus at the start with “For each...
>>
>>
>>
>>
>>
>>
>> *This Message Is From an External Sender*
>> This message came from outside your organization.
>>
>> I think it helps to establish the focus at the start with “For each
>> target”.
>>
>>
>>
>> The problem is that we can be dealing multiple adjacent targets, so the
>> “furthest point” changes depending on the adjacent targets. I.e. it will be
>> a different point for each adjacent target.
>>
>>
>>
>> Starting with the “furthest point” makes it seems like there is only one.
>>
>>
>>
>> Does swapping it around help?
>>
>> *For each target, the distance from the closest point of each adjacent
>> target to the farthest point of the current target is at least 24 CSS
>> pixels, except when:*
>>
>>
>>
>> When it is that way around it implies: “…to the farthest point of the
>> current target *[from the adjacent target]* is at least 24 CSS pixels”.
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> *From:*Sukriti Chadha <*sukriti1408@gmail.com* <sukriti1408@gmail.com>>
>> *Sent:* 19 November 2020 17:11
>> *To:* Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>
>> *Cc:* Michael Gower <*michael.gower@ca.ibm.com*
>> <michael.gower@ca.ibm.com>>; Alastair Campbell <*acampbell@nomensa.com*
>> <acampbell@nomensa.com>>; Sarah Horton <*sarah.horton@gmail.com*
>> <sarah.horton@gmail.com>>; WCAG list (*w3c-wai-gl@w3.org*
>> <w3c-wai-gl@w3.org>) <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>
>> *Subject:* Re: Target spacing refinement
>>
>>
>>
>> This might be better
>>
>>
>>
>> *For a target, the farthest point on the target is at least 24 CSS pixels
>> away from any point on each of its adjacent target, except if : *
>>
>>
>>
>> On Thu, Nov 19, 2020 at 12:09 PM Sukriti Chadha <*sukriti1408@gmail.com*
>> <sukriti1408@gmail.com>> wrote:
>>
>> *For all adjacent targets, the farthest point of one target is at least
>> 24 CSS pixels away from the other target, except if:*
>>
>>
>>
>> I see what you're saying. Definitely agree that the understanding
>> document will help clarify. The current wording (above) still remains
>> ambiguous with level 1 confusion of what is 'one' and what is 'other' and
>> level 2 runs into the same problem as the second wording of not specifying
>> where on the 'other target' and might be interpreted as picking one point.
>>
>>
>>
>> How's this?
>>
>>
>>
>> *For each target, the farthest point on the target is at least 24 CSS
>> pixels away from any point on each adjacent target, except if : *
>>
>>
>>
>>
>>
>> On Thu, Nov 19, 2020 at 11:38 AM Wilco Fiers <*wilco.fiers@deque.com*
>> <wilco.fiers@deque.com>> wrote:
>>
>> Sorry, accidental send....
>>
>>
>>
>> *The distance between the farthest point from a given target to any point
>> on all adjacent targets is at least 24 CSS pixels, except if:*
>>
>>
>>
>> The problem here is that it now suggests to pick one point in the target
>> that is furthest away from every adjacent target, instead of picking a
>> different point for each adjacent target. I understand the lack of
>> specificity in what I'm suggesting, but this language is accurate. I think
>> the way to create more clarity on how to test this is better done in the
>> understanding document.
>>
>>
>>
>> Wilco
>>
>>
>>
>>
>>
>> On Thu, Nov 19, 2020 at 5:24 PM Wilco Fiers <*wilco.fiers@deque.com*
>> <wilco.fiers@deque.com>> wrote:
>>
>> Hey Sukriti,
>>
>> I looked at phrasing the SC the way you suggest before:
>>
>> *The distance between the farthest point from a given target to any point
>> on all adjacent targets is at least 24 CSS pixels, except if:*
>>
>> The problem
>>
>>
>>
>>
>>
>> On Thu, Nov 19, 2020 at 4:36 PM Sukriti Chadha <*sukriti1408@gmail.com*
>> <sukriti1408@gmail.com>> wrote:
>>
>> *For all adjacent targets, the farthest point of one target is at least
>> 24 CSS pixels away from the other target, except if:*
>>
>>
>>
>> The language here is pretty confusing - we need to be more clear about
>> what is 'one target' and what is 'other target'. Here's a crack at one
>>
>>
>>
>> *The distance between the farthest point from a given target to any point
>> on all adjacent targets is at least 24 CSS pixels, except if:*
>>
>>
>>
>> On Thu, Nov 19, 2020 at 10:30 AM Michael Gower <
>> *michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>> wrote:
>>
>> Actually, we could even consider making diameter a defined term, thus
>> making those measurements normalized.
>> Michael Gower
>> Senior Consultant in Accessibility
>> IBM Design
>>
>>
>> 1803 Douglas Street, Victoria, BC  V8T 5C3
>> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com>
>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>
>>
>>
>> From:        Michael Gower/CanWest/IBM
>> To:        Sukriti Chadha <*sukriti1408@gmail.com*
>> <sukriti1408@gmail.com>>
>> Cc:        Alastair Campbell <*acampbell@nomensa.com*
>> <acampbell@nomensa.com>>, Sarah Horton <*sarah.horton@gmail.com*
>> <sarah.horton@gmail.com>>, "WCAG list (*w3c-wai-gl@w3.org*
>> <w3c-wai-gl@w3.org>)" <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>, Wilco
>> Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>
>> Date:        2020/11/19 07:27 AM
>> Subject:        Re: [EXTERNAL] Re: Target spacing refinement
>> ------------------------------
>>
>>
>>
>> Suktriti, I think the various methods of calculating the diameter of
>> shapes (rectangle, triangle) can be provided in the Understanding document,
>> including for irregular shapes.
>>
>> Note that the language Wilco put forward (and for which I have suggested
>> minor edits) would replace the language you have listed. The preamble would
>> become the following (with the addition of a new diameter bullet)
>>
>> *For all adjacent targets, the farthest point of one target is at least
>> 24 CSS pixels away from the other target, except if:*
>>
>>
>> Michael Gower
>> Senior Consultant in Accessibility
>> IBM Design
>>
>>
>> 1803 Douglas Street, Victoria, BC  V8T 5C3
>> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com>
>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>
>>
>>
>>
>> From:        Sukriti Chadha <*sukriti1408@gmail.com*
>> <sukriti1408@gmail.com>>
>> To:        Michael Gower <*michael.gower@ca.ibm.com*
>> <michael.gower@ca.ibm.com>>
>> Cc:        Alastair Campbell <*acampbell@nomensa.com*
>> <acampbell@nomensa.com>>, Sarah Horton <*sarah.horton@gmail.com*
>> <sarah.horton@gmail.com>>, Wilco Fiers <*wilco.fiers@deque.com*
>> <wilco.fiers@deque.com>>, "WCAG list (*w3c-wai-gl@w3.org*
>> <w3c-wai-gl@w3.org>)" <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>
>> Date:        2020/11/19 07:14 AM
>> Subject:        [EXTERNAL] Re: Target spacing refinement
>> ------------------------------
>>
>>
>>
>>
>> Thank you Alaistar, Wilco, Detlev and Michael for all the examples,...
>>
>>
>>
>>
>>
>>
>>
>>
>> *This Message Is From an External Sender*
>> This message came from outside your organization.
>>
>>
>> Thank you Alaistar, Wilco, Detlev and Michael for all the examples, those
>> are incredibly helpful! While I like the approach of diameters from a
>> mathematical standpoint, it might be confusing when implementing as a
>> developer, given most targets are confined in rectangular spaces, even if
>> the visible targets might be irregularly shaped. This was brought up before
>> and the group decided not to pursue that route for similar reasons. I have
>> one small edit to #5 to clarify where on the adjacent target. The SC reads,
>> where "from the closest edge" is the new text :
>>
>> *For each target, the distance from the closest edge of each adjacent
>> target to the farthest edge of the current target is at least 24 CSS pixels
>> except when*”
>>
>>
>> On Thu, Nov 19, 2020 at 10:05 AM Michael Gower <
>> *michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>> wrote:
>> Wilco and Detlev, thanks for working up another treatment. I agree with
>> Wilco that the parenthetical wording isn't required (it can be clarified in
>> the Understanding), so we end up with
>> *For all adjacent targets, the distance from the farthest point of one
>> target is at least 24 CSS pixels away from the other target, except if:*
>>
>>    - *Diameter**: The smallest diameter is at least 24 CSS pixels;*
>>
>>
>> I believe this rewording could even be further reduced by having
>> "distance from the" removed, to become
>> *For all adjacent targets, the farthest point of one target is at least
>> 24 CSS pixels away from the other target, except if:*
>>
>> Wilco, thanks for all those examples. My only request going forward if
>> you ever go to this trouble again, that you label or otherwise provide a
>> key for your expected outcome. (made up example: 'All example Ds should
>> fail'). That would help each of us scan to see if we're in agreement on
>> that outcome, and then scan to see what the real outcome was. IMO, a matrix
>> of examples like this would be beneficial in the Understanding document.
>>
>> Sarah, I echo Alastair's comments on size. For example, those little Xs
>> in the corners of dialogs are universal (and have another mechanism for
>> dismissal on the desktop, via the keyboard) and if we come up with wording
>> that fails them, we would have a hard time getting traction.
>>
>> Michael Gower
>> Senior Consultant in Accessibility
>> IBM Design
>>
>>
>> 1803 Douglas Street, Victoria, BC  V8T 5C3
>> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com>
>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>
>>
>>
>> From:        Alastair Campbell <*acampbell@nomensa.com*
>> <acampbell@nomensa.com>>
>> To:        Sarah Horton <*sarah.horton@gmail.com*
>> <sarah.horton@gmail.com>>
>> Cc:        Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>,
>> "WCAG list (*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>)" <
>> *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>
>> Date:        2020/11/19 04:58 AM
>> Subject:        [EXTERNAL] RE: Target spacing refinement
>> ------------------------------
>>
>>
>>
>>
>> Hi Sarah, We do have an SC that addresses target size, but it is...
>>
>>
>>
>>
>>
>>
>>
>>
>> *This Message Is From an External Sender*
>> This message came from outside your organization.
>>
>> Hi Sarah,
>>
>>
>>
>> We do have an SC that addresses target size, but it is at AAA. This is
>> the “other” SC that allows more flexibility so is aiming at AA.
>>
>>
>>
>> If we try and incorporate a minimum size as well as size+ spacing into
>> one SC, I think that would make it more convoluted.
>>
>>
>>
>> Also, if the user-need is met by targets+spacing (as described in the
>> previous email), we would get significant push-back on asking authors to
>> spend lots of time doing things that don’t actually help users.
>>
>>
>>
>> I appreciate the need, but we also have to note that it conflicts with
>> other needs, such as some people with low-vision (
>> *https://github.com/w3c/wcag/issues/1381*
>> <https://github.com/w3c/wcag/issues/1381>) and the ability to create
>> information-dense interfaces. We’ve reduced the size requirement to
>> compromise, it’s then a balance between competing requirements.
>>
>>
>>
>> With user-group conflicts the better approach is often personalisation
>> options rather than author requirements.
>>
>>
>>
>> So the question becomes: Is this SC a baseline worth having?
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> *From:*Sarah Horton <*sarah.horton@gmail.com* <sarah.horton@gmail.com>>
>> *Sent:* 19 November 2020 11:22
>> *To:* Alastair Campbell <*acampbell@nomensa.com* <acampbell@nomensa.com>>
>> *Cc:* Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>;
>> WCAG list (*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>) <*w3c-wai-gl@w3.org*
>> <w3c-wai-gl@w3.org>>
>> *Subject:* Re: Target spacing refinement
>>
>>
>>
>> Without an SC that addresses minimum target size I think this target
>> spacing SC is going to end up confusing and convoluted, and will not
>> address the real and significant user need for a minimum target size.
>>
>>
>>
>> What about trying for two new SCs, one for target size and one for target
>> spacing, either as part of the WCAG 2.2 effort or in whatever comes next
>> (2.3 or 3.0)?
>>
>>
>>
>> Best,
>>
>> Sarah
>>
>> On Nov 19, 2020, at 11:06 AM, Alastair Campbell <*acampbell@nomensa.com*
>> <acampbell@nomensa.com>> wrote:
>>
>>
>>
>> > The only two that I question are A4 and D1. Those are just so small...
>> If we added an absolute minimum diameter of 12px for every target those two
>> would fail without changing any of the other ones.
>>
>>
>>
>> Part of the reasoning for this SC was that, in touch-scenarios, the
>> devices use heuristics to guess which thing you meant to tap. I.e. if you
>> tap reasonably close to a link it generally works because the device finds
>> the nearest link.  However, if you have small links close to each other
>> that heuristic can make the wrong choice because you accidentally tapped
>> closer to an adjacent target.
>>
>>
>>
>> That’s why it is size+spacing rather than just size, and why we weren’t
>> trying to set a minimum size as such. (Although it Patrick were reading
>> this, he’d pipe in with “what about mouse users?”, which is fair, but it’s
>> hard to accomplish everything in one SC.)
>>
>>
>>
>> Also, I’m worried about adding complexity to (necessarily) convoluted SC
>> text…
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:*Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>
>> *Sent:* 19 November 2020 10:36
>> *To:* Alastair Campbell <*acampbell@nomensa.com* <acampbell@nomensa.com>>
>> *Cc:* WCAG list (*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>) <
>> *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>
>> *Subject:* Re: Target spacing refinement
>>
>>
>>
>> Hey Alastair,
>>
>> You are correct, I made a mistake on H3. There is just enough space for
>> the outer box to pass. I've fixed that, and added an example that's similar
>> but where the box is rounded (N1 - N4)
>>
>>
>>
>> As for E3 and E4, I think it is okay for those to fail. They are more
>> difficult to hit than some of the other fails like G4 and H4. I think this
>> actually strikes a good balance. The only two that I question are A4 and
>> D1. Those are just so small... even if someone isn't likely to hit the
>> wrong thing, it'll be hard to hit. If we added an absolute minimum diameter
>> of 12px for every target those two would fail without changing any of the
>> other ones.
>>
>>
>>
>>
>>
>> On Thu, Nov 19, 2020 at 2:04 AM Alastair Campbell <
>> *acampbell@nomensa.com* <acampbell@nomensa.com>> wrote:
>>
>> HI Wilco,
>>
>>
>>
>> That’s great! Thanks for putting that together.
>>
>>
>>
>> > Unfortunately, none of the proposals actually gets all of them right.
>>
>>
>>
>> I think we might need to discuss ‘right’ in this context.
>>
>>
>>
>> The previous wording from the FPWD did allow examples like E3/E4 assuming
>> there were no other targets to consider:
>>
>> <image007.png>
>>
>>
>>
>> But is that a good thing? The newer wording means that the proximity of
>> the small targets to another target causes a fail. I think that aligns with
>> the intent.
>>
>>
>>
>> When we get down to the overlapping examples I’m not sure that
>> interpretation is correct?
>>
>>
>>
>> Taking H3 as an example:
>>
>> <image008.png>
>>
>> The red square is 60 wide, the green is 24 + 12 left-padding, so there is
>> 24px of the parent on the right-hand side.
>>
>>
>>
>> With a wording of “*For each target, the distance from each adjacent
>> target to the farthest edge of the current target is at least 24 CSS pixels
>> except when*”
>>
>>
>>
>> The green target fits the exception bullet, but for the red one:
>>
>>    - We can consider the green target as “adjacent”;
>>    - The farthest edge of the red target from the green target is 24px –
>>    pass.
>>
>> I agree that H4 would fail, and I think most of the others. I’m not clear
>> about L2, I can’t see how much space is between those circles? For a circle
>> I think we have to treat the furthest point as the ‘edge’.
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> *From:*Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>
>> *Sent:* 18 November 2020 16:16
>> *To:* Alastair Campbell <*acampbell@nomensa.com* <acampbell@nomensa.com>>
>> *Cc:* Michael Gower <*michael.gower@ca.ibm.com*
>> <michael.gower@ca.ibm.com>>; WCAG list (*w3c-wai-gl@w3.org*
>> <w3c-wai-gl@w3.org>) <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>
>> *Subject:* Re: Target spacing refinement
>>
>>
>>
>> Hey folks,
>>
>> I did what I always do when rules get too complex. I write test cases.
>> Here's what I wrote. I used color gradients to indicate passes and fails.
>> Light green to dark green is passed, dark red to pink is fail.
>>
>> *https://codepen.io/wilcofiers/pen/abZxPow*
>> <https://codepen.io/wilcofiers/pen/abZxPow>
>>
>>
>>
>> Unfortunately, none of the proposals actually gets all of them right. So
>> this is going to need more work. I'll see if I can come up with a proposal
>> that gets all cases right. Probably worth for folks to have a look, see if
>> we're all in agreement on these. Maybe most noteworthy are E3 and E4. Those
>> corner blocks pass with the currently published SC text, but they fail in
>> all of the new .
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 18, 2020 at 4:41 PM Alastair Campbell <
>> *acampbell@nomensa.com* <acampbell@nomensa.com>> wrote:
>>
>> Hi Michael,
>>
>>
>>
>> Tackling the second one:
>>
>> > *The distance from each target's mid-point to the mid-point of
>> adjacent targets is at least 24 CSS pixels, expect when...*
>>
>>
>>
>> Measuring from mid-points allows for tiny targets next to larger ones,
>> e.g:
>>
>> <image009.png>
>>
>>
>>
>> Although easier to understand (slightly), I don’t think it aligns to the
>> goal quite as well.
>>
>>
>>
>> For the re-write of option 5, I think it would need to start with the
>> thing you are evaluating, e.g:
>>
>> *For each target, the distance from each adjacent target to the farthest
>> edge of the current target is at least 24 CSS pixels except when:*
>>
>>
>>
>> If others think that scans ok, I’m happy with that.
>>
>>
>>
>> Regarding the ‘objectives’, I think we can easily include that on the new
>> understanding docs at the top of the intent, and work back through the
>> 2.1/2.0 docs later.
>>
>> The upcoming re-design looks like this for the understanding doc:
>>
>>
>> *https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype-understanding.html*
>> <https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype-understanding.html>
>>
>>
>>
>> We can add a CSS class to the objective paragraph and work out the
>> styling in parallel.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> *From:*Michael Gower
>>
>>
>>
>> I agree option 5 *seems *to scan best, but I also think there is a
>> missing preposition. There are 2 ideas here:
>> 1) we are talking about the edge *farthest from* an adjacent target
>> 2) we are talking about the distance* from *that edge *to* the adjacent
>> target (or *between *them)
>>
>> So I think we need 2 prepositions, one to describe which edge and one to
>> describe the distance *between* two points. i think a rejig of the
>> sentence still allows that to scan okay:
>> *The distance from each adjacent target to the farthest edge of the
>> current target is at least 24 CSS pixels.*
>>
>> I think we need to bear in mind that this is a design-centric
>> consideration. As such, it is even more important to get the
>> language/concept simple. As such, I want to advocate for a variation I
>> pasted into the channel yesterday:
>>
>> *The distance from each target's mid-point to the mid-point of adjacent
>> targets is at least 24 CSS pixels, expect when...*
>>
>> AWK said that this wouldn't work for some edge cases, but I'd like to see
>> some examples to understand what gets through the net.
>>
>> Regardless of wording, this is another SC where a quick blurb summarizing
>> the objective would help with rapid comprehension. For instance:
>> *Objective: Ensure separation of targets for ease of operation.*
>> I wrote such blurbs for all the 2.1 additions, which were supposed to be
>> included in the Understanding documents, but were never incorporated.
>>
>> Michael Gower
>> Senior Consultant in Accessibility
>> IBM Design
>>
>>
>> 1803 Douglas Street, Victoria, BC  V8T 5C3
>> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com>
>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>
>>
>>
>> From:        Alastair Campbell <*acampbell@nomensa.com*
>> <acampbell@nomensa.com>>
>> To:        "WCAG list (*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>)" <
>> *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>
>> Date:        2020/11/17 04:34 PM
>> Subject:        [EXTERNAL] Target spacing refinement
>> ------------------------------
>>
>>
>>
>>
>> Hi everyone, After the long discussion on target spacing today,...
>>
>>
>>
>>
>>
>>
>>
>>
>> *This Message Is From an External Sender*
>> This message came from outside your organization.
>>
>> Hi everyone,
>>
>>
>>
>> After the long discussion on target spacing today, I tried to collate the
>> options into one place and add a couple of diagrams:
>>
>>
>> *https://docs.google.com/document/d/1Q9zWT1OjdCrts2xuadVEaJ2wpyLzxnysFQCSTs72L2o/edit?usp=sharing*
>> <https://docs.google.com/document/d/1Q9zWT1OjdCrts2xuadVEaJ2wpyLzxnysFQCSTs72L2o/edit?usp=sharing>
>>
>>
>>
>> Personally, I’m leaning towards option 5 as the simplest which measures
>> the size+spacing of the target, which would be:
>>
>>
>>
>> For each target, the distance of the target’s edge farthest from each
>> adjacent target is at least 24 CSS pixels, except when:
>>
>>    - [3 bullets unchanged]
>>    - *Nested:* The target is enclosed within another target and has a
>>    minimum height and width of 24 CSS pixels.
>>
>>
>>
>> If you’d like to add something (options, positives/negatives, diagrams
>> etc) please let me know and I’ll add you as an editor of the doc. It is
>> open for comments.
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> -Alastair
>>
>>
>>
>> --
>>
>>
>>
>> @alastc / *www.nomensa.com* <http://www.nomensa.com/>
>>
>>
>>
>>
>>
>> --
>>
>> *Wilco Fiers*
>>
>> Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>>
>>
>>
>> Join me at *axe-con* <http://deque.com/axe-con>2021: a free digital
>> accessibility conference.
>>
>>
>>
>> --
>>
>> *Wilco Fiers*
>>
>> Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>>
>>
>>
>> Join me at *axe-con* <http://deque.com/axe-con>2021: a free digital
>> accessibility conference.
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> *Wilco Fiers*
>>
>> Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>>
>>
>>
>> Join me at *axe-con* <http://deque.com/axe-con>2021: a free digital
>> accessibility conference.
>>
>>
>>
>> --
>>
>> *Wilco Fiers*
>>
>> Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>>
>>
>>
>> Join me at *axe-con* <http://deque.com/axe-con>2021: a free digital
>> accessibility conference.
>>
>>
>>
>>
>>
>> --
>>
>> *Wilco Fiers*
>>
>> Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>>
>>
>>
>> Join me at *axe-con* <http://deque.com/axe-con>2021: a free digital
>> accessibility conference.
>>
>>
>>
>>
>>
>>
>> --
>> *Wilco Fiers*
>> Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>>
>>
>> Join me at *axe-con* <http://deque.com/axe-con>2021: a free digital
>> accessibility conference.[attachment "deque_logo_180p.gif" deleted by
>> Michael Gower/CanWest/IBM]
>>
>>
>>
>
> --
> *Wilco Fiers*
> Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>
>
> Join me at axe-con <http://deque.com/axe-con> 2021: a free digital
> accessibility conference.
>