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>
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>
> 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>
>> 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>
>>> 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> 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
>>>>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>>>>
>>>>>
>>>>>
>>>>> From:        Michael Gower/CanWest/IBM
>>>>> To:        Sukriti Chadha <sukriti1408@gmail.com>
>>>>> Cc:        Alastair Campbell <acampbell@nomensa.com>, Sarah Horton <
>>>>> sarah.horton@gmail.com>, "WCAG list (w3c-wai-gl@w3.org)" <
>>>>> w3c-wai-gl@w3.org>, Wilco Fiers <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
>>>>> cellular: (250) 661-0098 *  fax: (250) 220-8034
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From:        Sukriti Chadha <sukriti1408@gmail.com>
>>>>> To:        Michael Gower <michael.gower@ca.ibm.com>
>>>>> Cc:        Alastair Campbell <acampbell@nomensa.com>, Sarah Horton <
>>>>> sarah.horton@gmail.com>, Wilco Fiers <wilco.fiers@deque.com>, "WCAG
>>>>> list (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.
>>
>